Descrizione del servizio
Il servizio è composto da un insieme di moduli, ciascuno dei quali può essere utilizzato all'interno di un progetto per gestire i seguenti aspetti dell'Identity and Access Management (IAM):
- autenticazione
- autorizzazione
- gestione delle identità digitali
- repository centralizzato delle identità digitali (CUR)
Caratteristiche funzionali
Autenticazione
Il modulo per l’autenticazione è stato realizzato utilizzando come tecnologia di base la versione 3.3.2 dell’Identity Provider (IdP) Shibboleth che rende disponibile anche la funzionalità di Single Sign-On (SSO, basato sul protocollo SAML 2.0), ovvero la possibilità per l’utente di accedere a tutti i servizi web (Service Provider, di seguito SP) a cui è abilitato inserendo una sola volta le sue credenziali.
L’IdP è stato esteso per consentire:
- l’autenticazione con credenziali rilasciate dal Sistema pubblico di identità digitale (SPID) e la riconciliazione di tali identità con le identità locali all’organizzazione di appartenenza dell’utente
- l’autenticazione multifattore (MFA)
- il collegamento in SSO di applicazioni che utilizzano il protocollo OAuth (es.: app mobile)
- la compatibilità con le regole definite dall’organizzazione a cui appartiene l’utente per il ciclo di vita delle password (es.: modifica forzata della password perché scaduta, blocco dell’utente in caso di tentativo fraudolento di utilizzo delle credenziali, gestione history delle password utilizzate)
L’estensione per SPID consente di:
- far convivere l’autenticazione dell’organizzazione con quella SPID
- realizzare politiche di riconciliazione più o meno complesse, in base alle esigenze dell’organizzazione
- concentrare in un unico punto gli obblighi normativi previsti per chi utilizza gli SPID in termini di monitoraggio, compliance e governance
- accreditare un solo servizio dell’organizzazione su SPID (il gateway) e guadagnare autonomia nell’aggiunta di nuovi servizi locali con autenticazione su SPID
- aggregare in un solo punto gli attributi rilasciati dalle Attribute Authority SPID, dagli IdP SPID e dalle fonti interne all’organizzazione per distribuirli agli SP
Autorizzazione
Il modulo per l’autorizzazione consente di utilizzare delle regole (policy) definite all'interno dell’organizzazione per verificare se un utente ha diritto o meno di accedere ad una determinata risorsa (servizio).
È basato su un software open source che svolge i ruoli di repository dei servizi e di motore e repository delle regole (“Policy Store”) per gestire gli aspetti connessi alla memorizzazione e alla valutazione centralizzata delle policy di autorizzazione.
Per la definizione delle regole si è deciso di utilizzare lo standard eXtensible Access Control Markup Language (XACML), ampiamente diffuso, che consente di definire policy di autorizzazione facilmente trasferibili tra piattaforme di venditori differenti ed evitarein tal modo di generare pericolosi “Vendor lock-in”.
L’architettura di riferimento XACML prevede che siano presenti i seguenti moduli:
- Policy Enforcement Point (PEP): è il modulo che protegge un servizio e, se necessario, avvia il processo di valutazione delle policy XACML di autorizzazione
- Policy Decision Point (PDP): è il modulo in cui vengono valutate le policy che devono essere applicate nel caso specifico, estraendole dal “Policy Store” e utilizzando i valori restituiti dal “Policy Information Point”
- Policy Information Point (PIP): è il modulo che estrae dagli “Attribute Stores” e rielabora i valori degli attributi necessari per la valutazione delle policy da parte del PDP
- Policy Administration Point (PAP): è il modulo che consente di gestire le policy contenute nel “Policy store”
- Policy Store: è il repository delle regole di autorizzazione XACML
- Attribute Stores: sono i repository dei valori associati agli attributi necessari per la valutazione delle policy XACML
Il software open source rende disponibili PDP e Policy Store. Il PIP deve invece essere sviluppato in base alle esigenze specifiche dell’organizzazione, così come i PEP che sono specifici delle singole applicazioni che devono delegare l’autorizzazione al modulo. Il PDP rende ovviamente disponibili i connettori necessari per interfacciarsi con PEP e PIP.
Il PAP è stato invece realizzato da CINECA con l'obiettivo di rendere disponibile all'organizzazione un'interfaccia semplificata per la gestione delle policy di autorizzazione.
Per colmare alcune lacune dello standard XACML è stato inoltre sviluppato un WS che prevede dei metodi pensati per semplificare l’utilizzo del modulo di autorizzazione come PEP da parte delle applicazioni.
In dettaglio, considerando l’insieme dei servizi presenti nel repository dei servizi:
- authorize: dato uno username e un profilo (es.: docente, tecnico, studente) restituisce l’elenco dei servizi abilitati per l’utente limitatamente a quel profilo; può fornire in ingresso anche un sottoinsieme dei servizi su cui effettuare la verifica
- autorize_exception: dato uno username e un profilo restituisce l’elenco dei servizi abilitati per l’utente escludendo quelli abilitati per il profilo (i servizi possono essere infatti associati direttamente all’utente come eccezioni)
- search: dato un profilo restituisce i servizi associati a quel profilo
Gestione utenti e credenziali di accesso
Rientrano in questo ambito la gestione degli utenti e i servizi self service a disposizione degli utenti per la gestione autonoma delle credenziali di accesso.
La gestione degli utenti rende disponibile all’organizzazione quanto necessario per gestire l’intero ciclo di vita delle identità digitali, dal provisioning iniziale al de-provisioning finale. Può essere centralizzata, ovvero a disposizione di poche persone che si occupano della gestione delle identità all'interno dell’organizzazione, oppure distribuita tramite delega a unità organizzative più piccole. Quest’ultima modalità di gestione consente di ottenere maggiore accuratezza, perché gli amministratori locali conoscono meglio di quelli centrali le singole unità organizzative, soprattutto in organizzazioni di grandi dimensioni.
È basata su un prodotto open source di tipo “Extract, Transform, Load” (ETL) e può essere personalizzata in base a esigenze specifiche della singola organizzazione. Gli amministratori del sistema dispongono di interfacce web di monitoraggio per controllare in modo puntuale l’intero funzionamento del sistema.
I servizi self service sono stati realizzati per consentire agli utenti finali del sistema la gestione autonoma delle credenziali di accesso e le informazioni personali associate all'identità dell’utente e prevedono:
- la possibilità di risalire allo username attribuito
- il reset della password
- la modifica della password
Repository centralizzato delle identità digitali (CUR)
Il CUR è utilizzato per memorizzare e fornire alle applicazioni le informazioni relative all’identità digitale degli utenti rendendo disponibile una visualizzazione aggregata delle identità all'interno dell’organizzazione. È inoltre utilizzato per la verifica delle credenziali ai fini dell’autenticazione.
È realizzato come directory service basati sullo standard LDAPv3. L’estrema variabilità delle esigenze manifestate dalle organizzazioni ha indirizzato la scelta verso i directory service standard, soluzione che consente di soddisfare la quasi totalità dei requisiti evidenziati. Come prodotto di base si è scelto di utilizzare OpenLDAP, con l’aggiunta dell’estensione necessaria per il supporto delle password policy.
È stato inoltre definito un modello di alberatura e di object class, pensato specificatamente per le esigenze degli atenei, che può essere utilizzato al momento dell’attivazione di ogni nuova istanza OpenLDAP.
Benefici
La suddivisione in moduli consente di utilizzare il prodotto migliore per ciascuno degli aspetti da gestire in un progetto IAM, piuttosto che un unico prodotto.
La scelta effettuata consente inoltre di gestire in modo più efficiente i progetti relativi solo ad un insieme ristretto di aspetti dell’IAM per cui l’installazione di un prodotto unico potrebbe non essere giustificata.