Con le Linee Guida per “OpenID Connect in SPID” l’Agenzia per l’Italia Digitale ha applicato al “Sistema Pubblico per l’identità Digitale” (SPID) italiano i più recenti sviluppi dell’Identity and Access Management (IAM) su Internet.
Identità digitali: la ricerca e la PA insieme verso nuovi standard
Cos’è OpenID Connect
OpenID Connect è uno standard che ha l’ambizione di creare un meccanismo interoperabile tra molte entità, sia pubbliche che private, per la verifica dell’identità, fornendo un meccanismo affidabile, semplice ed efficace che consente alle applicazioni ed ai servizi presenti sul Web di identificare i propri utenti, mediante una o più delle loro identità digitali, memorizzate presso un trusted Identity Provider.
Nel web il concetto di identità è strettamente connesso a quello di autenticazione, cioè al processo informatico di verifica dell’identità di un utente, per accertare che l’utente sia chi afferma di essere, che avviene comunemente utilizzando username e password che l’utente deve inserire tante volte quanti sono i servizi a cui intende accedere.
I concetti di “identità federata” e autorizzazione delegata
Con l’“identità federata” o “autenticazione federata” gli utenti possono accedere a molteplici sistemi effettuando un’unica fase di autenticazione presso l’Identity Provider, attuando il c.d. Single Sign-On (SSO)
L’identità federata è un concetto molto importante nella gestione delle identità e riguarda, appunto, la possibilità di utilizzare la propria identità digitale con diversi Service provider, con grandi vantaggi in termini di usabilità e sicurezza, consentendo di limitare le continue procedure di registrazione e di autenticazione e di evitare la memorizzazione di una miriade di password.
Accanto al concetto di autenticazione federata si pone quello di “autorizzazione delegata”.
L’autorizzazione è il processo per verificare se un utente abbia il diritto di eseguire determinate operazioni su determinati dati (come la lettura o scrittura di un documento), processo che, come quello dell’autenticazione, è strettamente connesso all’identità del soggetto e al suo ruolo rispetto al servizio.
A sua volta l’“autorizzazione delegata” consente ad un utente di delegare ad altri utenti o applicazioni la possibilità di effettuare operazioni sui propri dati.
L’identità delegata
Dai concetti di “autenticazione federata” e “autorizzazione delegata” nasce quello di “identità delegata”, cioè la possibilità per l’Utente di concedere, ad un’applicazione o ad un servizio, il permesso di accesso alle proprie informazioni personali, detenute da un Identity Provider, al fine di effettuare un processo di autenticazione.
L’identità delegata raggiunge il suo compimento con OpenID Connect che consente il trasferimento del processo di autenticazione a una terza parte “fidata” tramite protocolli che cercano di fornire riservatezza, autenticità e integrità delle informazioni scambiate.
Come nasce e come si sviluppa OpenID Connect
OpenID Connect, sviluppato da OpenID Foundation, è un protocollo SSO basato sul framework di autorizzazione OAuth 2.0, la stessa OpenID Foundation lo definisce “un semplice livello di identità sul protocollo OAuth 2.0”.
Dalla sua inaugurazione nel 2014, OpenID Connect ha avuto un’ampia diffusione: la maggiore interoperabilità, rispetto ad altri sistemi di SSO, e la facilità di implementazione ne hanno fatto uno dei protocolli più utilizzati dalle grandi multinazionali del settore tecnologico, come Google, Facebook e Microsoft.
La struttura aperta e decentralizzata di OpenID Connect offre flessibilità, interoperabilità e semplicità di implementazione, risolvendo in gran parte i problemi legati a IAM su reti eterogenee come Internet, e, combinando il Single Sign-On (SSO) e l’autorizzazione delegata, fornisce, altresì, un servizio completo in termini di requisiti di sicurezza: riducendo il frequente utilizzo del binomio sempre più insicuro del nome utente e password e liberando le applicazioni e i servizi dall’onere della gestione delle identità, che viene delegata ad Identity Provider “affidabili”, sfruttando la loro sicurezza, scalabilità e infrastruttura.
I dati dell’Utente non vengono mai esposti direttamente al suo browser o all’App, dato che la loro comunicazione avviene tra Identity provider e Service provider; ciò consente di evitare potenziali attacchi attuati mediante l’intercettazione delle comunicazioni, soprattutto nel caso di applicazioni per dispositivi mobile.
Inoltre, l’utente può avere il pieno controllo su ogni singolo accesso effettuato su un servizio, avendo la possibilità di revocare ogni autenticazione direttamente presso l’Identity provider.
Le applicazioni e i servizi divengono, così, dei semplici “Client” del sistema di autenticazione fornito dagli OpenID Connect Provider.
Spid Saml
Con le regole tecniche SAML, le entità coinvolte in SPID sono:
- l’Utente, che può disporre di uno o più identità digitali, composte da alcune informazioni identificative obbligatorie, come il codice fiscale, il nome, il cognome, il luogo di nascita, la data di nascita e il sesso;
- gli Identity providers (IdPs) che gestiscono gli utenti e la procedura di autenticazione;
- i Service providers (SPs) che erogano un servizio on line sulla base degli attributi restituiti dall’IdP a seguito dell’autenticazione dell’Utente.
L’Utente utilizzando il proprio User Agent (es. il browser) richiede l’accesso ad una risorsa o ad un servizio.
Il SP invia allo User Agent (UA) una richiesta di autenticazione da reindirizzare all’IdP.
L’IdP esamina la richiesta ricevuta e, se necessario, esegue una challenge di autenticazione con l’utente, ad esempio, nel caso più semplice, inserendo username e password.
Successivamente, portata a buon fine l’autenticazione, effettuando lo user login, l’IdP restituisce allo UA una Response SAML, destinata al SP, contenente un’asserzione con lo “statement di autenticazione” attestante l’avvenuta autenticazione, ed un’eventuale “statement di attributo”, con le informazioni sull’Utente autenticato.
L’adesione al patto di fiducia tra IdP e SP si concretizza non solo con la sottoscrizione di una convenzione con AgID, ma anche con la presenza di tali entità nel Registro SPID gestito dall’Agenzia.
Il Registro SPID è il repository di tutte le informazioni relative alle entità aderenti a SPID (entità SPID) e costituisce l’evidenza del cosiddetto circle of trust in esso stabilito.
Da Oauth a OpenID Connect
OAuth è stato il primo passo verso la standardizzazione dell’identità delegata.
Con OAuth un utente concede l’accesso ai propri dati ad un’applicazione per eseguire determinate azioni espressamente autorizzate dallo stesso utente.
La caratteristica principale di questo standard sta nella capacità di offrire alle applicazioni la possibilità di accedere ai dati di un utente in modo sicuro, senza necessariamente dover richiedere nuovamente le credenziali di autenticazione all’utente.
In OAuth l’utente (delegante) è noto come proprietario della risorsa, il consumatore (delegato) è noto come Client e il provider di servizi è noto come Server:
- il Server delle risorse (Resource server) è un tipico “provider API” che ospita le risorse di proprietà dell’utente protette da OAuth (foto, video, calendari o contatti);
- il Proprietario delle risorse (Resource owner) è l’utente del provider API, che, in qualità di “proprietario” delle risorse, può consentire ad un’applicazione di terzi l’accesso ai propri dati, ospitati sul server delle risorse;
- il Client è un’applicazione che effettua richieste API verso il Server di autorizzazione, per eseguire azioni su risorse protette dal Server delle risorse, in nome e per conto del proprietario delle risorse, previa sua espressa autorizzazione;
- il Server di autorizzazione (Authorization server) è il server che, una volta ottenuto il consenso dal proprietario della risorsa, invia l’access token al Client, per consentirgli l’accesso alle risorse protette dal Server delle risorse.
Partendo proprio dal processo di autorizzazione di OAuth 2.0, OpenID Connect implementa i servizi di autenticazione in base a due concetti fondamentali:
- concedere il permesso di accedere alle informazioni di autenticazione (l’identità dell’utente) ad un sito è molto simile all’accesso delegato, pertanto, è possibile gestire l’autenticazione e l’autorizzazione con gli stessi protocolli;
- le specifiche devono essere modulari, consentendo il loro rispetto senza la necessità di ulteriori complesse implementazioni.
OpenID Connect, quindi, è una specifica modulare di OAuth 2.0, pensata per implementare un sistema di Sigle Sign On basato sull’autenticazione federata, grazie al quale gli utenti possono autenticarsi su siti web appartenenti a più domini mediante le medesime credenziali e, al contempo, i gestori delle applicazioni Web possono evitare di creare i propri sistemi di autenticazione.
OpenID Connect può essere facilmente utilizzato non solo per le applicazioni web ma anche e soprattutto per le applicazioni mobile, favorendo l’interoperabilità con i vari sistemi e rendendo, così, più facile il lavoro per gli sviluppatori.
Spid OpenID Connect
I diversi punti di forza di OpenID Connect, in particolare: la facilità di integrazione in sistemi eterogenei, soprattutto in sistemi mobile, e l’interoperabilità con componenti di terze parti in modalità sicura e scalabile, hanno condotto l’Agenzia per l’Italia Digitale (AGID) ad avviare un gruppo di lavoro per disciplinare l’uso di OpenID Connect nel Sistema Pubblico di Identità Digitale italiano (SPID) con apposite linee guida.
Le linee guida
Le Linee Guida prevedono l’utilizzo del profilo “iGov” di OpenID Connect, un particolare profilo che definisce un set di base obbligatorio di controlli di sicurezza adatto a una vasta gamma di casi d’uso governativi, pur mantenendo una ragionevole facilità di implementazione e funzionalità.
Con le regole tecniche OpenID Connect, le entità coinvolte in SPID sono:
- l’Utente finale, rappresentato dal suo User Agent, che desidera accedere ai servizi forniti da un Client e, per questo, ha bisogno di dimostrare la propria identità;
- il Client, cioè l’applicazione che si affida ad un OpenID Connect Provider, al fine di autenticare un Utente finale;
- l’OpenID Connect Provider, che rilascia un ID token, contenente l’attestazione sull’identità dell’Utente finale e un eventuale token di accesso OAuth 2.0.
Il Client prepara una richiesta di autenticazione, Authentication Request, contenente i parametri desiderati e invia la richiesta al “Server di autorizzazione” Authorization Server.
Il “Server di autorizzazione” autentica l’Utente finale, mediante le proprie credenziali (es. username, password, OTP), e chiede l’autorizzazione ad inviare i dati al Client. Se l’Utente lo autorizza, il “Server di autorizzazione” reindirizza l’Utente finale verso il Client con un “codice di autorizzazione”.
Il Client, utilizzando il codice di autorizzazione, richiede al Token Endpoint un ID token per identificare l’Utente, e un Access token.
Mediante l’Access token, il Client può richiede allo User Info Endpoint dell’OpenID Connect Provider i dati identificativi dell’Utente necessari per la fruizione del servizio, come: nome, cognome, codice fiscale, domicilio, ecc.
OpenID Connect nelle applicazioni mobili
OpenID Connect mostra tutta la sua forza e versatilità nelle applicazioni mobili, in tale contesto il c.d. Client è rappresentato proprio dall’applicazione installata sul dispositivo mobile e del suo eventuale backend.
Le richieste al Token Endpoint e allo UserInfo Endpoint possono, pertanto, essere inviate sia dall’applicazione sia dal suo backend, ferma restando la necessità di prevedere meccanismi di trasmissione e archiviazione sicuri che impediscano a terze parti di venire in possesso dell’Access Token.
Per inviare l’Authentication Request all’OpenID Connect Provider è possibile usare il browser o una webview, purché protetta con i meccanismi più sicuri messi a disposizione dai sistemi operativi al fine di ottenere il massimo isolamento dall’applicazione chiamante.
Per quanto riguarda l’attestazione dell’identità dell’Utente e dei suoi attributi identificativi (claims) da parte dell’OpenID Connect Provider, sebbene lo standard OpenID Connect preveda la possibilità di rilasciare claims all’interno dello stesso ID Token, in SPID OpenID Connectquesto non è permesso, pertanto l’ID Token ha la sola funzione di attestare l’identità dell’utente e il livello SPID relativo alle credenziali utilizzate, mentre gli attributi dell’utente sono rilasciati unicamente dallo UserInfo Endpoint, a seguito di richiesta con apposito “Access Token”.
Ulteriore peculiarità in SPID OpenID Connect è l’utilizzo del Proof Key for Code Exchange (PKCE).
PKCE è un’estensione del protocollo OAuth 2.0 che ha lo scopo di evitare un potenziale attacco attuato mediante l’intercettazione dell’Authorization code.
Il meccanismo di sicurezza consiste nella generazione di un codice (code verifier) e del suo hash (code challenge): il code challenge viene inviato all’OpenID Connect Provider nella richiesta di autenticazione e, successivamente, quando il Client contatta il Token Endpoint, al termine del flusso di autenticazione, invia il code verifier, per consentire all’OpenID Connect Provider di controllare che l’hash del code verifier corrisponda al code challlenge dell’Authentication request.
Al fine di evitare continui inserimenti di password per l’accesso ai vari servizi, consentendo, comunque, agli Utenti di mantenere il pieno controllo su ogni accesso effettuato, SPID OpenID Connect consente l’utilizzo delle “sessioni lunghe revocabili”.
Ogni volta che l’utente avvia l’applicazione, il client può chiamare l’introspection endpoint per verificare se l’access token in suo possesso sia ancora valido: in caso di risposta affermativa può utilizzare questo token per mantenere in vita la sessione di autenticazione; in caso di risposta negativa, il client può chiamare il token endpoint con il refresh token, ricevuto durante la precedente autenticazione, per ottenere un nuovo access token.
Il Refresh token consente unicamente di ripristinare una sessione di autenticazione di livello 1 di SPID (ovvero quando l’autenticazione viene effettuata mediante il solo inserimento di username e password), livello considerato applicabile nei casi in cui il danno causato, da un utilizzo indebito dell’identità digitale, ha un basso impatto per le attività degli Utenti.
Il livello 1, infatti, è caratterizzato da una limitata affidabilità del procedimento di autenticazione che si basa sull’impiego di un singolo fattore (una password) e che, pertanto, consente una protezione solo contro un rischio moderato.
Conclusioni
In conclusione, OpenID Connect rappresenta una rivoluzione che ha l’ambizione di traghettare SPID verso il futuro, un futuro nel quale l’utilizzo delle identità digitali da parte dei cittadini sarà sempre più frequente e nel quale i Service provider dovranno offrire servizi alla portata di chiunque, mediante un semplice “click”.
