Introduzione alla gestione dell`identità federata Con il termine

Introduzione alla gestione dell’identità federata
Con il termine identità elettronica di un soggetto (utente, computer, software)
s’intende l’insieme di dati digitali che identificano il soggetto in maniera univoca
all’interno di un dominio informatico. I dati digitali che compongono l’identità
elettronica sono di solito composti da un insieme di valori del tipo “attributo =
valore”. Il processo completo della gestione dell’identità, dalla fase di creazione
fino alla sua eliminazione, viene chiamato la gestione dell’identita elettronica.
L'autenticazione è il processo che permette ad un soggetto (utente, computer,
software) di verificare la corretta identità di un altro soggetto con cui intende
comunicare. L'autorizzazione, invece, è il processo mediante il quale ad un
soggetto già autenticato si garantisce o si nega l'accesso ad un servizio in base
all’identità ed ai ruoli che lo identificano. Spesso, per autorizzare l'accesso ad un
servizio, più che l’identità del soggetto serve conoscere il ruolo della persona
autenticata. Ad esempio, un medico di un ospedale, indipendentemente da chi
sia, ha diritto di accedere ad un servizio “X” gestito dallo stesso ospedale. La
verifica di accesso in base ai ruoli ricoperti permette inoltre di poter garantire
l'anonimato del soggetto che accede ad un determinato servizio.
I meccanismi di autenticazione ed autorizzazione sono processi ortogonali tra di
loro e possono essere quindi gestiti da due entità indipendenti; in questo modo,
un certo soggetto può autenticarsi presso un’entità “K” e accedere ad un servizio
gestito da un’entità “L” differente. Per la gestione dell’identità elettronica in
ambienti distribuiti occorre utilizzare un’infrastruttura tecnologica di AAI
(Authentication and Authorization Infrastructure) che permette di creare un
sistema per la gestione e lo scambio degli attributi tra i diversi gestori d’identità e
fornitori di servizi.
Nella gestione dell’identità di un soggetto è molto importante il ruolo del
protocollo standard che permette ad un soggetto di autenticarsi una prima volta e
di accedere a tutti i servizi distribuiti forniti da un dominio informatico senza la
necessità di autenticarsi per ognuno di essi. Questo meccanismo è noto come
Single Sign On (SSO). Un ente che intende partecipare ad una federazione di
SSO deve come prima cosa realizzare un infrastruttura di SSO al proprio interno.
Gestione dell’identità elettronica in un ambiente multi dominio federato con
SSO
La gestione dell’identità federata consiste nell’estensione della verifica
dell’identità e della gestione degli attributi a livello inter-dominio. Occorre quindi
realizzare un’infrastruttura che permetta ad un utente appartenente ad un
dominio “A”, autenticato presso la propria organizzazione, di accedere ai servizi
offerti da altri domini “X” e “Y” federati. L'utente A non ha necessità di avere
alcun tipo di interazione diretta con i gestori di servizi di questi domini. Un
approccio di questo tipo permette di creare una divisione dei compiti, facendo sì
che i fornitori dei servizi (Service Providers) non debbano più gestire le
procedure onerose di accreditamento e di amministrazione degli account degli
utenti, e possano quindi occuparsi solo delle funzionalità del servizio da fornire e
della verifica dell'autorizzazione all'utilizzo del medesimo.
Una federazione è definita come un insieme di domini amministrativi che attuano
politiche comuni per quanto riguarda l'uso e l’applicabilità di tratti identificativi
degli utenti per attuare le decisioni di autenticazione e autorizzazione usando
un’infrastruttura comune.
Figura 1. Insieme di domini amministrativi federati
L'infrastruttura tecnologica di gestione dell’identità federata deve basarsi su
protocolli standard, in questo caso SAML. Per interpretare gli attributi scambiati
tra i vari componenti della federazione in modo corretto inoltre, occorre utilizzare
un linguaggio comune sia a livello sintattico sia semantico, in modo da attribuire
un significato preciso agli attributi e ai loro possibili valori. La difficoltà principale
nella gestione dell’identità federata consiste nel trovare un approccio comune,
condiviso da tutti i partecipanti alla federazione, in grado di risolvere i problemi di
oggi e i bisogni di domani. Per una buona gestione dell’identità elettronica
federata occorre attuare i seguenti aspetti:
•
•
•
•
Utilizzo di un’infrastruttura tecnologica AAI sicura e scalabile
Creazione di una relazione di fiducia tra i partecipanti alla federazione
Presenza di un ente super partes che abbia il compito di:
o Gestire l’infrastruttura tecnologica comune della federazione
o Far rispettare le regole stabilite dai partecipanti della federazione
o Sottoscrivere i contratti d’adesione alla federazione da parte dei
partecipanti
o Gestione della mappa della federazione (metadati)
o Fornire assistenza ai partecipanti alla federazione
Utilizzo di una Certification Authority X.509 per garantire la sicurezza dei
•
•
dati scambiati
Utilizzo di un linguaggio comune per gli attributi da scambiare
Realizzazione dei servizi ed applicazioni in conformità alle specifiche
tecniche della federazione.
I requisiti della gestione dell'identità federata nell'ambito del progetto
OpenInFSE
Requisito del progetto OpenInFSE è preservare e riutilizzare eventuali
infrastrutture già implementate dalle Regioni rendendole interoperabili con quella
di OpenInFSE che è basato sul protocollo standard SAML2. I requisiti di tale
sistema sono:
1. L'identità di un individuo è gestita dalla Regione italiana dove risiede
2. Gli individui sono identificati da un Identity Provider (IDP) utilizzando un
meccanismo di autenticazione che viene deciso dalla Regione di
appartenenza
3. Un utente autenticato viene identificato da vari attributi, del tipo: nome,
cognome, data di nascita, cittadinanza, sesso, comune di residenza,
statura, colore degli occhi, ecc.
4. Deve essere utilizzato un sistema di autorizzazione basato sui ruoli; un
ruolo per un utente autenticato viene assegnato/verificato dalle Attribute
Authorities (AA) utilizzando attributi quali: medico generico, medico di
pronto soccorso, paziente, infermiere, persona iscritta ad organizzazione
professionale, impiegato amministrativo di un ospedale, farmacista, ecc;
5. L'identità elettronica di un individuo è composta da un insieme di valori
aggregati relativi all'identità ed ai ruoli del soggetto. Tale aggregazione è
gestita da un'autorità aggiuntiva denominata Profile Authority (PA).
L'architettura di gestione dell'identità federata proposta per il progetto
OpenInFSE è compatibile con l'implementazione del progetto ICAR
(Interoperabilità e Cooperazione Applicativa fra le Regioni, task INF-3: gestione
dell'identità). Al momento, l'implementazione ICAR supporta solo il profilo SAML
Web Single Sign On (Web - SSO), mentre il progetto OpenInFSE fornisce le
specifiche di utilizzo anche del profilo SAML per Web Services Security.
Interazione dei componenti OpenInFSE - Profilo Web SSO profile
Nel seguito si descrive l'interazione dei componenti infrastrutturali nel caso di
accesso ad una risorsa protetta dalla federazione senza una sessione SSO
valida (il caso con sessione SSO valida risulta un sottoinsieme di questo).
L'interazione globale è presentata in Figura 2.
Fig. 2. Interazione dei componenti OpenInFSE per il profilo Web SSO
L’utente della regione B vuole accedere ad una risorsa gestita da un SP della
regione A protetta dalla federazione. Il Service Provider nella Regione A inoltra
ogni richiesta di autenticazione e di attributi al Local Proxy nella sua regione. Il
Local Proxy è un proxy SAML che ha un rapporto di fiducia con tutto il resto
dell'infrastruttura della federazione. Il browser viene reindirizzato quindi al Local
Proxy con la richiesta di attributi/autenticazione generata dal Service Provider
locale. Se la richiesta è valida, l'utente tramite il suo browser interagisce con il LP
per identificare il suo Profile Authority.
Il Local Proxy quindi reindirizza il browser al Profile Authority selezionato
generando una nuova richiesta SAML di autenticazione/attributo. Il Profile
Authority verifica la richiesta di autenticazione SAML ricevuta: se è valida,
interagisce con l'utente tramite il browser per individuare l'Identity Provider
dell'utente. Dopo che l'utente ha selezionato l'Identity Provider corretto, il Profile
Authority reindirizza il browser dell'utente, generando una nuova richiesta di
autenticazione all'Identity Provider selezionato.
L' Identity Provider verifica la validità della richiesta di autenticazione: se è valida,
l'utente può autenticarsi direttamente presso la sua Regione. Se l'autenticazione
è valida, il browser dell'utente, che contiene la risposta all'autenticazione SAML,
verrà reindirizzato al Profile Authority. Esso verifica la validità della risposta
SAML e nel caso sia valida, offrirà all'utente la scelta della selezione del profilo
(in base ai suoi possibili ruoli); nel caso l'utente possegga un solo profilo, la
selezione sarà fatta automaticamente. Dopo la selezione del profilo, il Profile
Authority reindirizza il browser dell'utente alle Attribute Authorities appropriate
per recuperare gli attributi che confermino o meno il ruolo selezionato dell'utente.
Il Profile Authority aggrega le risposte SAML ottenute da Identity Provider ed
Attribute Authorities, e reindirizza il browser dell'utente al Local Proxy che a sua
volta lo reindirizza al Service Provider che aveva originato la richiesta iniziale. Se
il processo di autorizzazione approva il profilo dell'utente egli può accedere al
servizio richiesto. In caso contrario, l'accesso verrà negato.
Interazione dei componenti OpenInFSE - profilo Web Services Security
L'infrastruttura OpenInFSE utilizza il Web Services Security (WS-Security) con
l'obiettivo di garantire autenticità, integrità e riservatezza dei messaggi SOAP.
WS-Security definisce un elemento <Security> che può essere incluso
nell'intestazione (header) di un messaggio SOAP e specifica come il messaggio
è protetto. WS-Security fa uso di meccanismi definiti nelle specifiche standard
W3C XML Signature e XML Encryption che si utilizzano per firmare e
crittografare i dati del messaggio SOAP. Le informazioni contenute nell'elemento
<security> specificano quali operazioni sono state eseguite e in quale ordine,
quali chiavi sono state utilizzate per queste operazioni, e quali
attributi/informazioni di identità sono associate a tali informazioni. WS-Security
fornisce anche altre caratteristiche, come ad esempio la possibilità di marcare le
informazioni di sicurezza mediante dei timestamp .
L'architettura di gestione delle identità federate per il profilo Web Services
security è mostrata in Fig. 3.
Fig. 3. Uso tipico di WS-Security con SAML Token 1
Secondo lo standard WS-Security, la sicurezza dei dati viene gestita mediante
token di protezione che possono essere di tipo binario oppure dei token XML. I
token binari, come i certificati X.509 e i ticket Kerberos, sono trasportati in un
involucro XML, mentre i token XML, come le asserzioni SAML, sono inseriti
direttamente come sotto-elementi dell'elemento <Security>. L'utilizzo di
asserzioni SAML con WS-Security è descritto nel profilo Web Services Security
SAML Token Profile. Le caratteristiche dell'utilizzo di asserzioni SAML, secondo
1
R. Sandhu et al, Role-Based Access Control Models, IEEE Computer, 29(2):38-47, Feb. 1996
quanto definito in WS-Security, sono le seguenti:
• Le asserzioni SAML vengono trasportate in un elemento <Security>
all'interno dell'intestazione della busta SOAP, vedere Fig. 4
• Le asserzioni SAML svolgono un ruolo nella protezione dei messaggi in
cui sono trasportate; contengono una chiave utilizzata per la firma digitale
dei dati all'interno del corpo del messaggio SOAP
• Le asserzioni SAML saranno state ottenute in precedenza e verranno
utilizzate per garantire il messaggio SOAP.
Fig. 4. WS-Security con un Token SAML
Formatted: English (United
States)
Il profilo Web Services Security SAML Token Profile non usa i protocolli SAML
basati su Request/Response ma descrive l'utilizzo di tre metodi di subject
confermation: 'portatore', 'holder-of-key' e 'sender-vouches'. Il metodo ‘portatore’
non viene utilizzato dall’infrastruttura OpenInFSE poiché non fa uso di chiave
pubblica o certificato digitale per garantire la sicurezza dei messaggi SOAP.
Gli altri due metodi: 'holder-of-key' e 'sender-vouches', utilizzati da OpenInFSE,
invece fanno uso di chiavi pubbliche X.509 per proteggere i messaggi SOAP.
Poiché vi è una chiave associata ad un token 'holder-of-key', tale token può
essere utilizzato per fornire protezione a livello di messaggio. Il processo è il
seguente:
A = Utente finale
B = web service client
C = Security Token Services (STS)
D = web service
Formatted: English (United
States)
A = B (Caso 'holder-of-key')
B contatta C per ottenere un'asserzione SAML relativamente a se stesso
in modo da poter accedere D. B quindi fornisce il proprio certificato a C e
C autentica il certificato di B, creando un'asserzione SAML con l'identità di
B e mettendo il certificato di B nell'asserzione firmata da C. B invia
l'asserzione a D, firmando il messaggio con la chiave privata associata
nell'asserzione.
Il metodo di conferma del soggetto 'sender-vouches' viene utilizzato quando un
server ha bisogno di diffondere l'identità del soggetto autenticato con i messaggi
SOAP per conto del soggetto. L’identità del soggetto deve essere ottenuta
utilizzando altri metodi come il Web SSO oppure un’autenticazione locale.
Questo metodo è simile alle auto-asserzioni di identità e l'ente attestante deve
proteggere le auto-asserzioni SAML mediante una firma digitale così che il
destinatario possa verificare che nessun altro lo abbia alterato. Questo metodo
consente la scalabilità e l'interoperabilità tra le regioni italiane e permette di
nascondere i metodi di autenticazione utilizzati da ciascuna regione partecipante.
Occorre stabilire un rapporto di fiducia tra il mittente e il destinatario mediante lo
scambio dei metadati della federazione. Questo metodo consente la cifratura dei
messaggi scambiati garantendone la riservatezza end-to-end.
A = end user
B = web service client
C = STS
D = web service
A! = B (Caso: sender-vouches)
B contatta C per ottenere un'asserzione SAML a nome di A per accedere
D. Il metodo utilizzato per recuperare l'asserzione SAML può essere simile
a quello descritto nella sezione Web SSO che coinvolge l'utente finale D.
C crea un'asserzione SAML con l'identità di A e la firma. B invia
l'asserzione a D e usa il certificato di B per garantire l’autenticità del
messaggio.
Formatted: English (United
States)