Per SSO si intende la possibilità per il cittadino di fare login sull'area personale o su un servizio digitale e non dovrelo ripetere se si sposta su un altro servizio digitale dello stesso Ente.
Loading...
Loading...
Opencity Italia integra l'autenticazione Spid/CIE mediante il componente dedicato OpenLogin, dialogando con esso con protocollo oAuth2. Lo stesso componente può essere usato da altri applicativi.
Una autenticazione con SSO tra Opencity Italia e un applicativo in uso allo stesso Ente può essere agevolmente realizzata se può essere garantito il supporto per il protocollo oAuth2.
Vediamo uno schema generale degli attori in gioco:
Vediamo un flusso di autenticazione di un cittadino che fa login prima sull'area personale e successivamente sull'applicativo di terze parti:
L'applicativo di terze parti dovrà essere dotato di un opportuno client oAuth2. Ipotiziamo che le url coinvolte siano le seguenti e mostriamo una tipica configurazione del client.
URL dell'area personale: https://servizi.comune.bugliano.pi.it
URL della pagina di login (OpenLogin): http://login.comune.bugliano.pi.it
URL dell'applicativo di terze parti: http://myapp.company.com
Per attivare un nuovo client è necessario fornire:
La URL da autorizzare come redirct uri del client
La URL di logout
L'attivazione comprende i seguenti dati
La piattaforma Opencity Italia supporta questa possibilità mediante una tecnica che permette di convertire una sessione basata su cookie in un token JWT.
Questo consente di usare l'autenticazione senza necessariamente usare lo stesso cookie:
integrarsi con altri applicativi di terze parti che possono usare un client JWT;
fare chiamate cross-origin (CORS) autenticate dove non è semplice o possibile sfruttare lo stesso cookie di autenticazione;
Attenzione: il requisito perché questa tecnica funzioni è che i servizi si trovino tutti sotto lo stesso dominio di secondo livello. Ad esempio: - servizi.comune.bugliano.pi.it - www.comune.bugliano.pi.it - altro.bugliano.pi.it
Come molti applicativi web anche Opencity Italia usa i cookie per implementare la sessione utente, il cookie si ottiene semplicemente l'indirizzo di accesso degli utenti: ad esempio per il nostro Ente di demo è
A questo punto nel proprio brower è possibile rintracciare facilmente il cookie della piattaforma.
Il cookie di sessione viene inviato in modo trasparente all'utente dal browser al sito che lo ha generato, e questo garantisce che l'utente abbia sempre una sessione valida quando naviga nella sua area personale.
Per fare chiamate alle API però è necessario convertire il Cookie in Token JWT, per farlo esiste una apposita API, nel nostro esempio:
Per simulare la chiamata con Postman ad esempio:
Il token JWT può essere usato adesso per fare chiamate alle API che richiedono una autenticazione, ad esempio posso usare l'interfaccia Swagger delle API come segue.
Faccio click in alto a destra sul comando Authorize
A questo punto posso chiamare le API che richiedono autenticazione come la /applications
All'interno del token sono presenti le seguenti informazioni:
In base alla , si viene rediretti su un provider di autenticazione (tipicamente un sistema che permette il login con Spid/CIE), si eseguono tutti gli step necessari e infine si torna sull'area personale con una sessione valida.
