🛠️
Opencity Italia
Sviluppatori e partner tecnologici
Sviluppatori e partner tecnologici
  • Introduzione
  • Architettura
    • Pattern: microservizi
    • Pattern: event sourcing
    • Vista generale
  • Standard e convenzioni
    • Standard della piattaforma
    • Microservizi
  • Roadmap
  • Integrazioni
    • Integrazione Widget servizio (FormIO)
    • Integrazioni con il flusso delle pratiche
      • API ReST
      • Webhooks
    • Modello di integrazione con l'area personale
    • Integrazione con Intermediari di pagamento PagoPA
      • Requisiti per l'integrazione
      • Il Pagamento
        • Versione 1.0
        • Versione 2.0
      • Schema di Funzionamento
      • Configurazione dei pagamenti
        • API v1
        • API v2
      • Un pagamento in dettaglio
      • Gli stati di un pagamento
      • Processo di sviluppo
      • Implementazione di un proxy
    • Integrazione con Protocollo Informatico
      • Requisiti per l'integrazione
      • Documento digitale
        • Esempio documento con allegati non protocollato
        • Esempio documento con allegati protocollato
        • Esempio documento con campo retry_meta prodotto dal protocol proxy
        • Esempio documento con campo retry_meta modificato dal sistema di retry
        • Usecase: Il Documento originato dalle pratiche dai servizi digitali
        • Stati del documento
      • Architettura del sistema di protocollazione
      • WorkFlow sistema di protocollazione
        • Configurazione tenant e servizi
      • Protocol Proxy: Specifiche Implementative
      • Processo di sviluppo
    • Integrazioni con il Sito Istituzionale
    • Single Sign-On
      • SSO mediante oAuth2
      • SSO mediante JWT
    • Processi asincroni (job)
      • Importazione dovuti
    • Integrazione di un servizio di terze parti protetto da autenticazione
      • Esempio con GovWay
  • 👩‍💻Sviluppo
    • Multilingua
    • Temi grafici
Powered by GitBook
LogoLogo

Opencity Labs

  • Sito web
  • Product page

Developers Italia

  • Sito web
  • Area personale e Servizi Digitali

Documentazione Opencity Italia

On this page

Was this helpful?

Export as PDF
  1. Integrazioni
  2. Integrazione di un servizio di terze parti protetto da autenticazione

Esempio con GovWay

Esempio dettagliato di una integrazione di un modulo di Opencity Italia che attinge a una API protetta mediante l'API gateway opensource GovWay di Link.it

PreviousIntegrazione di un servizio di terze parti protetto da autenticazioneNextMultilingua

Last updated 4 months ago

Was this helpful?

API privata, che si intende esporre mediante GovWay:

https://192.168.1.111:8000/conti-correnti

L'API risponde un dato privato se viene correttamente inserito un parametro in get tax_code che identifica il codice fiscale del cittadino che esegue la richiesta:

https://192.168.1.111:8000/items/conti-correnti?tax_code=AAABBBXX...

L'API non ha un controllo interno che permette di rispondere ad ogni cittadino solo con i suoi dati, l'API è aperta e risponde a qualunque chiamata.

In questo esempio si desidera esporre l'API privata su un indirizzo pubblico e filtrare le chiamate in modo che ogni cittadino possa consultare l'API solo per i propri dati.

L'API esposta è la seguente:

https://govway-qa-out.boat.opencontent.io/govway/Ente/directus/v1

Quando viene chiamata quest'ultima url si desidera imporre un controllo sulla la presenza del token JWT e sul parametro della chiamta. La chiamata deve raggiungere l'API privata SOLO se:

  1. il token è presente

  2. il token è validato mediante la chiave pubblica esposta in

  3. viene passato il parametro tax_code in GET

  4. il parametro tax_code corrisponde al valore username del token

Quest'ultimo punto è il più importante perché ci da la certezza che il cittadino che sta facendo la richiesta è lo stesso che si è autenticato.

Configurazione

E' necessario creare una token policy, che poi verrà assegnata all'erogazione delle API

Fare attenzione inoltre che il kid della chiave pubblica è specifico per ogni tenant e deve essere quello corretto.

Predisposta la policy deve essere applicata all'Erogazione API

Il controllo del contenuto viene fatto imponendo che l'informazione riportata nel token (${tokenInfo:username}) e quella inserita come parametro GET della chiamata (${query:filter[tax_code]}) abbiano lo stesso valore. Resta inteso che il valore nel token è vincolato dalla piattaforma, mentre il parametro tax_code è scelto da chi ha progettato l'API che viene protetta.

A questo punto la configurazione è completa.

Il file jwks è stato scaricato da e inserito in un path raggiungibile da GovWay: nel nostro caso essendo GovWay installato con Docker abbiamo fatto uso della direttiva volumes per condividere il file con il container di GovWay.

https://servizi.comune-qa.bugliano.pi.it/.well-known/jwks.json
JWKS
Selezionare il profilo API Gateway
Aggiungere la definizione dell'API: per farlo sarà necessario caricare il file Open API 3 della definizione dell'API stessa.
Configurazione del connettore
Creare una API in Erogazione che esponga l'API che si desidera proteggere: si usa la definizione dell'API configurata allo step precedente e si impostano la URL di invocazione e la url del servizio interno che espone l'API (connettore)
Creazione token policy: fare attenzione a tutti i campi evidenziati. Lo username verrà usato per fare il controllo di accesso.
Configurazione dell'Erogazione creata in precedenza
Si accede alle configurazioni necessarie dalla sezione "Controllo Accessi" dell'Erogazione API
Il controllo prevede la Policy predisposta agli step precedenti, la validazione del token e la presenza del claim username. Infine viene inserito il controllo sul contenuto come indicato nell'immagine.