Single sign-on & SPID nella pubblica amministrazione: il caso CNR
Come il Consiglio Nazionale delle Ricerche ha integrato l’autenticazione con SPID nei propri sistemi
Il Single Sign-On (SSO) è un metodo di autenticazione che consente ad un utente di accedere a più sistemi software tramite l’utilizzo di un unico ID. Permette inoltre di autenticarsi una sola volta e di accedere a diversi servizi senza dover reinserire le credenziali di accesso. L’autenticazione SSO, quindi, consente l’utilizzo delle risorse di rete in maniera seamless, migliorando notevolmente la User Experience.
Storicamente, i sistemi informatici messi a disposizione da PA e aziende private hanno sempre avuto la loro base di utenti, spesso condivisa all’interno della stessa Amministrazione. In questo modo gli utenti sono costretti ad effettuare la login in ogni sistema che vogliono utilizzare, sebbene la base di utenti sia sempre la stessa per ogni applicazione.
Adottando il SSO, invece, gli utenti si autenticano con l’identity provider anziché con le singole applicazioni. In questo modo le applicazioni non devono più gestire moduli di accesso, autenticazione e memorizzazione degli utenti.
Inoltre, i recenti aggiornamenti normativi ( Legge 11 settembre 2020, n.120 — Gazzetta ufficiale, le norme in tema di digitalizzazione e innovazione sono inserite negli articoli dal 23bis al 37bis) hanno evidenziato la necessità di integrare l’autenticazione di tipo SPID con le applicazioni messe a disposizione dalle PA.
Ed è in questo contesto che è sorto il gruppo di lavoro che ha intrapreso la sfida dell’integrazione di SPID con le applicazioni interne al Consiglio Nazionale delle Ricerche (CNR).
SPID — Sistema Pubblico di identità Digitale
A tal proposito si è pensato ad un’integrazione che consentisse non solo l’accesso tramite SPID, ma anche la possibilità di gestire le autenticazioni in modo centralizzato attraverso il SSO.
La scelta dell’applicativo è ricaduta sul software open source Keycloak il quale è risultato essere adeguato in termini di flessibilità, utilizzo e customizzazione. Keycloak è un prodotto software open source che abilita il Single Sign-On (IdP) con Identity Management e Access Management per applicazioni e servizi moderni. Questo software, scritto in Java, supporta i protocolli di federazione delle identità per impostazione predefinita SAML v2 e OpenID Connect (OIDC) / OAuth2.
L’utilizzo di Keycloak offre i seguenti vantaggi:
- estendibilità e personalizzazione
- Single Sign-On (SSO)
- centralizzazione dei metodi di autenticazione (possibilità di inserirne di nuovi senza modificare le applicazioni)
- uso nativo del protocollo LDAP
All’interno di Keycloak è presente il concetto di realm. Un realm è un livello di isolamento che gestisce un insieme di utenti, credenziali, ruoli e gruppi. Un utente appartiene e accede a un realm. I realm sono isolati l’uno dall’altro e possono gestire e autenticare solo gli utenti che controllano. All’interno del realm vengono definiti i client, che rappresentano le applicazioni sulle quali gli utenti saranno autenticati, eventuali IdP esterni ed eventuali alberature LDAP dalle quali recuperare le utenze.
Per l’effettivo utilizzo all’interno dell’ecosistema CNR si sono rese necessarie delle integrazioni con sistemi pregressi e con sistemi richiesti da adempimenti legislativi:
- Anagrafica Centralizzata CNR (ACE)
- SPID
Il modulo software ACE gestisce le anagrafiche del CNR relativamente alle strutture, dati anagrafici del personale CNR (strutturato e non) e ruoli assegnati ad essi.
Per l’integrazione con Keycloak prendiamo ad esempio il seguente caso d’uso: l’utente X ricopre il ruolo di “Admin” per l’applicazione APP01 mentre è “Guest” per l’applicazione APP02. Per poter permettere un SSO in grado di tener conto anche dei diversi ruoli che un qualsiasi utente ricopre all’interno delle applicazioni è indispensabile che i ruoli siano resi disponibili dal sistema; in questo modo, ogni volta che l’utente cambia applicazione rimane sia autenticato che autorizzato.
Per consentire questa funzionalità è necessario integrare le informazioni utente fornite da Keycloak con quelle provenienti da ACE, attraverso la creazione di specifici mapper in modo da consentire l’inserimento di tali informazioni all’interno di:
Grazie ai progetti open source condivisi mediante la community Developers Italia è stato possibile inoltre, integrare in Keycloak il plugin SPID messo a disposizione da Luca Leonardo Scorcia estendendo il SSO agli utenti autenticati mediante SPID.
L’integrazione di SPID in un sistema con una propria base di utenti preesistente da luogo a una pluralità di casi di accesso:
- Accesso al sistema di un utente esterno tramite SPID
- Accesso al sistema di un utente CNR tramite le credenziali interne
- Accesso al sistema di un utente CNR tramite SPID (problema delle doppie utenze)
Nel primo caso, un utente SPID accede al sistema tramite SPID e viene riconosciuto come un utente esterno.
Nel secondo caso gli utenti CNR accedendo al sistema vengono riconosciuti come tali.
Ma cosa accade quando un utente con credenziali CNR accede tramite SPID?
Necessariamente l’identity provider deve essere in grado di riconoscere i propri utenti anche quando questi accedono attraverso SPID, se il caso descritto non venisse gestito, l’utenza CNR e l’utenza SPID rimarrebbero disgiunte.
Attraverso l’integrazione di SPID con keycloak e con ACE è possibile riconoscere un Utente Cnr anche se accede attraverso SPID. Tale funzionalità è realizzata mediante un opportuno mapper che, attraverso gli attributi forniti dall’autenticazione su SPID (i.e. — codice fiscale), recupera da ACE l’eventuale utenza CNR.
All’interno di Keycloak sono possibili varie tipologie di flussi di autenticazione come:
Authorization Code Flow per applicazioni basate sul browser come SPA (Single Page Applications) o applicazioni server side
Implicit Flow per applicazioni basate sul browser, meno sicuro del precedente in via di dismissione
Client Credentials Grant per client REST come i servizi web, comporta la condivisione sul client di una chiave/password, di conseguenza il client deve essere sicuro (usato per chiamate REST server to server)
Resource Owner Password Credentials Grant per client REST per sistemi legacy, comporta la condivisione delle credenziali con gli altri sistemi
Authorization Code Flow
Il Flusso di autenticazione di un utente con credenziali Spid all’interno di un’app CNR in SSO può essere riassunto nei seguenti passi:
- L’utente richiede l’accesso ad un applicazione CNR
- L’applicazione ridireziona l’utente su Keycloak per l’autenticazione
- L’utente riceve il form di autenticazione per il Single Sign On
- L’utente seleziona il provider SPID
- Keycloak ridireziona l’utente verso il provider SPID scelto
- L’utente si autentica con le proprie credenziali SPID
- 7b. Keycloak attraverso il componente User Mapper interroga l’anagrafe centralizzata per verificare se l’utente è un utente CNR o meno, nel caso lo sia ne recupera l’username; nel caso l’utente risulti essere di tipo CNR, recupera inoltre attraverso il componente “ACE Mapper” eventuali ruoli relativi all’utente presenti nell’Anagrafe Centralizzata
- Keycloak, invia le informazioni recuperate all’applicazione richiedente
- L’utente risulta autenticato e presenta i ruoli forniti dai servizi web ACE
Gestendo il mapping degli utenti esterni (provenienti da SPID) con quelli interni (CNR) all’interno dell’identity provider svincoliamo le applicazioni da tale responsabilità.
Il lavoro svolto sta consentendo l’uniformazione dei meccanismi di autenticazione all’interno della comunità CNR; tale integrazione rappresenta un punto di inizio che consentirà di mitigare il digital divide e contestualmente migliorare la User Experience nei servizi messi a disposizione dall’ente.
Originally published at https://medium.com on February 14, 2022.
