Il modello ICAR per la gestione dell Identit

Transcript

1 Il modello ICAR per la gestione dell Identit Identità Digitale Federata Architettura, opportunità e prospettive di convergenza Forum PA 2008, Roma 15 maggio 2008 Massimiliano Pianciamore massimiliano.pianciamore@cefriel.it FOR DISCUSSION PURPOSES ONLY: ANY OTHER Identità USE OF Federata THIS PRESENTATION in ICAR CEFRIEL INCLUDING REPRODUCTION FOR PURPOSES OTHER THAN NOTED ABOVE, MODIFICATION OR DISTRIBUTION - WITHOUT THE PRIOR WRITTEN PERMISSION OF CEFRIEL IS PROHIBITED

2 Accesso ai Servizi e-gov: e Una visione User-centrica Service 1 Req. Attrs: First Name Last Nname Address? 4: Retrieve Address Certification from AA1 ADDRESS AA1 AA2 1:Service Request PROFESSION Service 2 3: Retrieve Identity Certification from IdP Identity, Name, Last Name Identity Providers

3 Accesso ai Servizi e-gov: e Una visione User-centrica Service 1 ADDRESS AA1 Retrieve Profession Certification from AA2 PROFESSION AA2 Service 2 1:Service Request Req. Attrs: First Name Last name Profession? 3: Retrieve Identity Certification from IdP Identity, First Name, Last name Identity Providers

4 : Identity Provider Un Identity Provider è un entità della federazione ICAR in grado di fornire asserzioni sull identità digitale sugli utenti/subject conosciuti riceve richieste di autenticazione con l indicazione dell insieme dei metodi di autenticazione ritenuti accettabili dal richiedente produce token di autenticazione che certificano l avvenuto riconoscimento di un subject secondo una specifica modalità (Es. username/pwd, HardwareToken, etc.) Il token di autenticazione prodotto può eventualmente includere anche un insieme di attestazioni del valore degli attributi che caratterizzano il profilo dell utente mantenuto dal quell Identity Provider Normalmente un IdP non è in grado di comportarsi da Attribute Authority Può produrre attestazioni di attributo soltanto a seguito dell avvenuta autenticazione di un utente e congiuntamente al token di autenticazione La produzione del token di autenticazione tipicamente prevede l interazione con il browser utente Authentication Request/Response (Http) Identity, First Name, Last name Identity Providers

5 Una Attribute Authority è in grado di fornire certificazioni di attributo relative ai subject conosciuti Esempi: tutti gli attributi conosciuti di un determinato subject certificazione del valore (o dei valori) di uno o più attributi relativi ad uno specifico subject In generale, le Attribute Authorities (AA) non si comportano come Identity Provider e non sono in grado di certificare l identità di un utente/subject Una AA non è in grado di fornire token di autenticazione agli altri componenti della federazione Il recupero delle certificazioni di attributo dalle Attribute Authorities tipicamente non prevede l interazione diretta con l utente Interazioni M2M Es. SOAP requests/responses : Attribute Authorities

6 Non esiste una authority globale : Considerazioni Le singole (attribute) authorities possono certificare sottoinsiemi (in generale distinti) di attributi associati a uno specifico subject Uno stesso attributo per un determinato subject può essere certificato da più authorities (anche con valori diversi tra loro) Esempio: Attributi ruolo o professione Servizi distinti possono richiedere sottoinsiemi diversi di attributi di un subject per consentire l accesso a risorse protette Esempio: dati personali, qualifiche professionali, certificazioni di ruolo

7 Aggregazione degli attributi: Profili utente L accesso ad un servizio implica l interazione con un Identity Provider della federazione al fine di ottenere un token di autenticazione il recupero e il raggruppamento di attributi certificati da un insieme di (attribute) authorities AA 1 Codice Fiscale CGN Un Profilo utente abilita l aggregazione di certificazioni di attributo un profilo è una vista aggregata sull insieme di attributi di un subject un profilo associa ad un insieme di attributi di un subject il corrispondente insieme di certificazioni ciascun attributo in un profilo referenzia una specifica autorità certificante Codice Fiscale Residenza Professione Qualifica1 Qualifica2 PA subject CGN... Milano Medico... Residenza Qualifica... AA 2... Milano Rappres. XYZ Un profilo definisce una Attribute Release Policy che viene attuata sotto il controllo dell utente quando un SP richiede un insieme di attributi l utente seleziona un profilo adeguato a soddisfare la richiesta soltanto gli attributi (e le relative certificazioni) contenute nel profilo sono trasferiti al SP richiedente AA n Professione Medico Qualifica Avvocato...

8 Una Profile Authority è un componente della federazione ICAR preposto alla gestione e al rilascio dei profili utente Gli utenti possono selezionare ed aggregare attributi in profili Per ogni attributo è possibile selezionare l Attribute Authority in grado di certificarne il valore per quell utente La Gestione dei profili utente: Profile Authority Una Profile Authority opera come Rappresentante dell utente nei confronti delle Attribute Authorities e degli Identity Provider

9 Una Profile Authority riceve dai Service Provider richieste di autenticazione e di attributo richiede all utente il consenso al trasferimento degli attributi al Service Provider interagisce con l utente per ottenere l autorizzazione esplicita al rilascio degli attributi presenti nei profili utente ai Service Provider richiedenti interagisce con gli Identity Provider per ottenere token di autenticazione che verranno restituiti ai Service Providers insieme alle certificazioni di attributo Fornisce un servizio di IdP Discovery agli utenti interagisce con le Attribute Authorities per ottenere le certificazioni di attributo veicola le certificazioni di identità e di attributo verso i Service Provider richiedenti La Gestione dei profili utente: Profile Authority /2

10 Gestire la complessità della federazione: SP Domain, SP e servizi Le Profile Authorities svolgono il ruolo di mediatori fra gli utenti e le autorità di certificazione (IdP e AA) Non sono gli unici elementi nell architettura ICAR a svolgere il ruolo di mediatori L interazione fra i Service Provider in un dominio e il resto della federazione può essere infatti piuttosto complessa

11 Un singolo Service Provider può erogare più servizi, ciascuno con i propri requisiti in termini di certificazioni (di identità e di attributo) Un singolo dominio erogatore (ad esempio una Regione) tipicamente comprende al proprio interno più Service Provider Es. Portale Tributi con vari servizi, Portale per il bollo auto, etc. E opportuno introdurre un componente architetturale in grado di operare come mediatore fra un Dominio erogatore (SP Domain) e il resto della federazione Gestire la complessità della federazione: SP Domain, SP e servizi

12 Mediare l interazione l con i Domini erogatori: Il componente Local Proxy Il componente Local Proxy è un gateway bidirezionale fra i ServiceProvider di un dominio (es. una Regione) e il resto della federazione ICAR Opera come Relying Party dal punto di vista della federazione Produce richieste di certificazione e ottiene risposte dagli altri componenti della federazione Opera come Asserting Party (IdP o AA) nei confronti dei Service Provider del suo dominio Riceve le richieste dai Service Provider Inoltra le richieste ricevute alla Profile Authority selezionata dall utente e riceve le risposte dalla Profile Authority Veicola la risposta ricevuta verso il service provider richiedente

13 Architettura complessiva: SP, LP, PA, AA, AR Pubbliche Amministrazioni Locali e Centrali Infrastruttura ICAR AR Autorità di Certificazione (Pubbliche Amm., Ordini e Associaz. Professionali,...) SP Domain SP1 PA Discovery IdP Discovery Attribute Authorities ADDRESS LP PA PROFESSION SPn Identity, First Name, Last name Identity Providers

14 Architettura ICAR-INF INF-3 3 e SAML 2.0 Pubbliche Amministrazioni Locali e Centrali Infrastruttura ICAR AR Autorità di Certificazione (Pubbliche Amm., Ordini e Associaz. Professionali,...) SP Domain SP1 PA Discovery IdP Discovery Attribute Authorities ADDRESS LP PA PROFESSION SPn Identity, First Name, Last name Identity Providers

15 Iniziative presenti sul territorio: Il progetto People e l infrastruttura l SiRAC SiRAC: Infrastruttura di autenticazione federata realizzata nell ambito del progetto PEOPLE (54 enti fra Comuni e Province) Utilizzo di SAML 1.1 (Security Assertion Markup Language) per trasportare le asserzioni di autenticazione fra i portali degli enti e l IdP che mantiene il profilo dell utente. Dispiegato dal 2005 e attualmente operativo sugli enti della Comunità People Adottato anche da altri enti non appartenenti alla Comunità People Facilmente integrabile con portali e servizi preesistenti sugli enti

16 Infrastruttura SiRAC-People: L opportunità di integrazione e di convergenza verso il modello e l architettura l ICAR SAML 2.0 Wrapper Federazione ICAR ICAR Bridge IdP AA LP PA

17 Iniziative sul territorio e convergenza verso ICAR - Un esempio concreto: Regione Lombardia e IdPc In Regione Lombardia La Carta Regionale dei Servizi è distribuita su larga scala Credenziale forte, unificata, distribuita a tutti e conforme alla normativa esistente Come favorirne l utilizzo nella fase di accesso ai servizi? L Identity Provider del Cittadino (IdPc) Consente ai singoli enti di delegare ad un servizio esterno regionale la verifica delle credenziali di un utente in possesso di una smart card (CRS/CNS/CIE). L IdPC è aperto verso sistemi di autenticazione ed erogatori di servizi terzi rispetto alla Regione E possibile interoperare con la comunità PEOPLE e l infrastruttura SiRAC Evolverà e si integrerà in modo naturale con il modello e l architettura ICAR 20 Identità Federata CEFRIEL in ICAR

18 Punto di vista del Cittadino Conclusioni: Opportunità e Vantaggi dell adozione di una infrastruttura federata da parte dei diversi soggetti Possibilità di utilizzo di una singola credenziale spendibile su diversi erogatori di servizi Punto di vista dell Ente erogatore dei servizi Possibilità di demandare la gestione dell identità, ed in particolare il rilascio e la verifica di validità delle credenzali digitali, ad una infrastruttura centrale condivisa per tutti gli enti coinvolti La realizzazione dei singoli servizi continua a focalizzarsi sugli aspetti specifici (autorizzazione, business logic, etc.) Punto di vista Infrastrutturale Adozione di un processo e una infrastruttura di gestione dell identità digitale condivisi fra diversi soggetti erogatori dei servizi finali Punto di vista dei Fornitori di Soluzioni applicative L adozione di protocolli e interfacce standardizzate promuove e semplifica il processo di integrazione con le soluzioni commerciali esistenti 21

19 Il modello ICAR per la gestione dell Identit Identità Digitale Federata Architettura, opportunità e prospettive di convergenza Forum PA 2008, Roma 15 maggio 2008 Massimiliano Pianciamore massimiliano.pianciamore@cefriel.it FOR DISCUSSION PURPOSES ONLY: ANY OTHER Identità USE OF Federata THIS PRESENTATION in ICAR CEFRIEL INCLUDING REPRODUCTION FOR PURPOSES OTHER THAN NOTED ABOVE, MODIFICATION OR DISTRIBUTION - WITHOUT THE PRIOR WRITTEN PERMISSION OF CEFRIEL IS PROHIBITED