l identità digitale federata nel progetto ICAR

Transcript

1 l identità digitale federata nel progetto ICAR Francesco Meschia Roma, 16 febbraio 2006

2 agenda generalità sul progetto ICAR e sul task INF-3 situazione e problemi dell identità digitale in Italia l approccio di INF-3 al problema l interazione G2C/G2B l interazione G2G le relazioni di fiducia Roma, 16 febbraio

3 Roma, 16 febbraio il progetto ICAR le Regioni hanno promosso per la seconda fase di e-government il progetto interregionale ICAR (Interoperabilità e Cooperazione Applicativa tra le Regioni), a cui partecipano 17 tra Regioni e Province autonome il progetto è in corso di avviamento con la stipula delle convenzioni tra le Regioni e il Cisis

4 Roma, 16 febbraio i task del progetto ICAR AP-1 AP-2 AP-3 AP-4 AP-5 AP-6 AP-7 INF-3 INF-2 INF-1 i tre interventi infrastrutturali costituiscono il presupposto per realizzare la cooperazione applicativa e l interscambio informativo interregionale. i casi di studio sono concepiti come applicazione degli interventi infrastrutturali per l interscambio informativo

5 Roma, 16 febbraio i task infrastrutturali INF-1 : infrastruttura fisica e logica per l interoperabilità e la cooperazione tra i domini applicativi regionali INF-2 : monitoraggio dei livelli di servizio applicativi INF-3 : sistema federato di autenticazione per l accesso ai servizi

6 il task INF-3 il Task INF3 si pone l obiettivo di realizzare un sistema di Identity Management che fornisca al sistema di cooperazione applicativa il supporto necessario all identificazione e autorizzazione degli utenti il Task INF3 è coordinato dalla Regione Piemonte Roma, 16 febbraio

7 Roma, 16 febbraio gli obiettivi di INF-3 definire un modello logico di riferimento indipendente dalla tecnologia di implementazione, che permetta di raggiungere l univoca identificazione dell utente nella Community Network interregionale definire un modello logico di riferimento che indichi le modalità con cui un servizio può verificare gli attributi posseduti da un utente ai fini dell autorizzazione all accesso

8 gli obiettivi di INF-3 fornire ai soggetti coinvolti dal progetto di un insieme di specifiche per la realizzazione di servizi di Identity Management secondo i predetti modelli logici fornire ai soggetti coinvolti dal progetto una reference implementation corrispondente alle specifiche curare che le Regioni e Province Autonome coinvolte, secondo la propria responsabilità, implementino il sistema di IdM federato adattando i propri sistemi di IdM locali Roma, 16 febbraio

9 Roma, 16 febbraio i risultati attesi verrà dispiegata e resa disponibile in un ambiente di test la reference implementation in modo da permettere i test necessari a realizzare le implementazioni regionali a cura delle regioni e province autonome coinvolte verranno poi realizzate: le implementazioni regionali dei servizi di IdM le verifiche di funzionamento attraverso il dispiegamento in almeno 3 regioni verranno fornite specifiche di integrazione al sistema di IdM interregionale dei servizi di certificazione esterni

10 Roma, 16 febbraio i soggetti coinvolgibili Regioni e Province autonome che partecipano al progetto ICAR enti della Pubblica Amministrazione Locale coinvolti da processi di cooperazione applicativa con altri Enti indipendentemente dall ambito territoriale su cui insistono il CNIPA, per la condivisione del modello di autenticazione e autorizzazione da prevedere nell ambito delle regole tecniche dell SPC

11 Roma, 16 febbraio i soggetti coinvolgibili altre Amministrazioni Centrali interessate a processi di cooperazione applicativa con le Amministrazioni locali soggetti privati che ai sensi della normativa vigente hanno un ruolo nei processi di certificazione dell identità digitale (p.es. Autorità di Certificazione)

12 stato dell identità digitale nel Paese la prima fase dei progetti di e-government ha visto la creazione di sistemi di identity management su base territoriale le persone, tuttavia, non agiscono strettamente su un solo ambito territoriale i cittadini si spostano, hanno interessi in diverse realtà, gli intermediari rappresentano persone fisiche o giuridiche in diversi ambiti a supporto di queste esigenze è auspicabile superare la frammentazione dei cosiddetti silos di identità Roma, 16 febbraio

13 andare oltre la frammentazione il problema della frammentazione dei silos di identità non è nato nella pubblica amministrazione nasce da esigenze pratiche e commerciali nel mercato statunitense, caratterizzato da frequenti acquisizioni e fusioni l attuale tendenza dell industria non è più quella di unificare i silos di identità si preferisce parlare di federazione dei silos federare due sistemi di identity management significa fare sì che i rispettivi linguaggi non siano più stranieri l uno all altro si ottiene l interoperabilità delle identità digitali attraverso un insieme comune di regole e di grammatiche, non attraverso una sola forma di rappresentazione Roma, 16 febbraio

14 Roma, 16 febbraio la sfida dell identità digitale federata rendere interoperabili le rappresentazioni delle identità digitali è solo uno degli aspetti si tratta di una prospettiva tecnica l effettiva utilità giunge quando si può riporre fiducia nell identità digitale a prescindere da chi la emette si pensi a quanto accade nella realtà con i passaporti dall interoperabilità si arriva all utilità se c è anche un modello tecnico-organizzativo che supporti la fiducia tra le parti la fiducia genera fiducia

15 Roma, 16 febbraio la sfida dell identità digitale federata il progetto ICAR ha avuto il merito di vedere nell identità digitale federata il presupposto per accrescere l impatto dei servizi di e-government il task INF-3 ha il compito di attuare questo presupposto attivando la federazione dell identità digitale tra le regioni il compito presenta sfide architetturali, tecnologiche e organizzative le Regioni del Veneto, della Lombardia e del Piemonte hanno promosso un laboratorio per accelerare la modellazione di base

16 i compiti del laboratorio prendere in considerazione casi d uso rappresentativi interazioni G2C/G2B e G2G in cooperazione applicativa modellare il contesto organizzativo di riferimento quali soggetti sono coinvolti quali relazioni coinvolgono i soggetti come si propagano le relazioni di fiducia Roma, 16 febbraio

17 i compiti del laboratorio modellare il contesto tecnologico di riferimento quali oggetti informatici rappresentano i soggetti della federazione quali dati vengono scambiati come vengono garantite privacy, sicurezza e fiducia produrre una implementazione di riferimento sia del modello organizzativo sia del modello tecnico regole, procedure e modulistica software riusabile Roma, 16 febbraio

18 i casi d uso presi in considerazione interazione G2C/G2B un cittadino o intermediario accede al portale dei servizi di un ente interazione G2G un incaricato di un ente accede ai servizi di un altro ente secondo il modello della semplificazione amministrativa Roma, 16 febbraio

19 Roma, 16 febbraio l interazione G2C/G2B è il caso di un cittadino o intermediario che accede al portale dei servizi di un ente si tratta di utenti esterni se il servizio comporta visure di dati personali, l ente deve identificare l utente l identificazione si ottiene attraverso il superamento di una procedura di autenticazione in questa procedura l utente dimostra la propria identità mostrando di conoscere un segreto che può essere noto solo a lui

20 il problema dell autenticazione come può l ente erogatore del servizio accertarsi che l utente sia a conoscenza del segreto? risposta tradizionale: anche l ente ne è a conoscenza, perché l ente stesso lo ha dato all utente se l ente è certo che un dato segreto sia stato consegnato ad un dato utente, può far derivare l identità dell utente dalla conoscenza del segreto in realtà il procedimento deve essere visto da una prospettiva di catena di responsabilità e quindi di catena di fiducia Roma, 16 febbraio

21 la catena di responsabilità/fiducia l ente erogatore del servizio è responsabile del trattamento dei dati che raccoglie se il trattamento comporta rendere visibili questi dati ad una persona, l ente erogatore deve sapere chi è questa persona per sapere chi è l utente, l erogatore ripone la propria fiducia in un processo di identity management che comprende la registrazione con fornitura delle credenziali, la gestione dell albo dei registrati e l identificazione Roma, 16 febbraio

22 Roma, 16 febbraio la catena di responsabilità/fiducia service provisioning (fornitura del servizio) e identity provisioning (fornitura dell identità) sono funzioni logicamente distinte ove sussistano relazioni di fiducia tra service provider e identity provider, queste funzioni possono essere distinte anche organizzativamente e fisicamente così come le relazioni di fiducia all interno del sistema bancario rendono possibile che la banca titolare di uno sportello bancomat (service provider) fornisca il contante dietro presentazione della tessera di un altra banca (identity provider)

23 la catena di responsabilità/fiducia un analogo ragionamento si può fare per la funzione di attribute provisioning gli attributi sono le qualifiche che contestualizzano le identità delle persone qualifiche professionali appartenenza ad albi e ordini il service provider può usare gli attributi posseduti dall utente a scopi di autorizzazione e per fare questo deve riporre fiducia nell attribute provider Roma, 16 febbraio

24 la modellazione del contesto riprendendo concetti già noti e in uso, il laboratorio ha modellato il contesto fin qui tracciato facendo uso del concetto di dominio informatico il dominio informatico di un ente racchiude il suo sistema informativo il suo perimetro è il perimetro di sicurezza dell ente al suo interno l ente è autonomo in quanto a scelte e politiche di sicurezza Roma, 16 febbraio

25 schematizzazione del modello DOMAIN 1 DOMAIN 2 CIRCLE OF TRUST Service provider User Profiles PROFESSION ADDRESS C.A. TRUST TRUST Globally trusted authority TRUST C.A. Service provider certified user attributes PROFESSION ADDRESS? C.A. Service provider C.A. = Certification Authority Service provider Service provider DOMAIN 3 Outline Varie sorgenti di informazioni (es. PA) in grado di certificare le identità degli utenti Relazioni di trust mutue tra domini attraverso un circle-of-trust gestito da un autorità centrale riconosciuta Gli utenti accedono ai servizi presenti in qualunque dominio del circle-of-trust, previo scambio di credenziali certificate Roma, 16 febbraio

26 schematizzazione del modello gli enti che decidono di federarsi nel quadro di cooperazione ICAR entrano a far parte di un ambito fiduciario comune (circle of trust) grazie all esistenza di questo ambito fiduciario è possibile sgravare i domini delle P.A. dal compito di identity e attribute provisioning perché questo compito può essere svolto da domini specializzati (domini certificatori) la fiducia si mantiene perché i certificatori sono accreditati e convalidati all interno del dominio di cooperazione che rappresenta ICAR Roma, 16 febbraio

27 schematizzazione del modello gli utenti (cittadini o intermediari) si rivolgono ai certificatori di identità riconosciuti per farsi registrare ed ottenere le credenziali questa funzione potrà tipicamente essere svolta dalle attuali Certification Authority rivolgendosi poi ai certificatori di attributo potranno ottenere le attestazioni digitali delle proprie qualifiche ordini ed albi professionali potranno fornire questo servizio identità ed attributi diventeranno parte del profilo dell individuo, che potrà essere gestito grazie a servizi di comunità detti certificatori di profilo Roma, 16 febbraio

28 Roma, 16 febbraio asserzioni ed interoperabilità i domini certificatori metteranno a disposizione, nel dominio di cooperazione ICAR, i loro servizi i servizi produrranno delle attestazioni di identità, attributo e profilo che sono dette asserzioni le asserzioni dovranno seguire un formato concordato che possa garantire l interoperabilità altrettanto concordato dovrà essere il modo in cui certificatori, fornitori di servizio e individui interagiranno

29 asserzioni ed interoperabilità il paradigma a scambio di asserzioni è alla base di tutte le iniziative dell industria in tema di identità digitale federata sin dal 2001 esiste su questo tema una famiglia di specifiche aperte, denominata SAML (Security Assertion Markup Language), mantenuta dal consorzio internazionale OASIS il laboratorio ha esaminato la versione più recente della specifica (SAML 2.0) trovandola idonea alla realizzazione di quanto modellato Roma, 16 febbraio

30 Roma, 16 febbraio scenario di esempio Dominio richiedente 8 Erogazione servizio Dominio erogante 1 Richiesta di servizio Service Provider 3 2 Controlla profilo 7 Dominio di profilazione Profile Authority Verifica origine utente 4 Recupera indirizzi authority Access Manager 6 Gestione Politiche di Autorizzazione Profili utente 5 Credenzial Indirizzo Professione Certification Authority Credenziali Attribute Authority 1 Indirizzo Professione Attribute Authority 2 Attribute Authority N Dominio certificatore

31 Roma, 16 febbraio il circle of trust ogni attestazione che viaggia tra le entità del modello (asserzioni di profilo, identità, attributo) reca con sé la firma elettronica dell entità che l ha emessa nel dominio di cooperazione esiste una entità super partes che chiamiamo garante e che ha il compito di certificare quali sono le autorità riconosciute e i loro compiti il garante pubblica un albo di queste certificazioni, che a loro volta sono asserzioni che recano la firma del garante questo garantisce ogni parte rispetto alla validità delle asserzioni, alimenta la fiducia tra le parti e crea così il circle of trust

32 l interazione G2G è il caso d uso che si presenta quando un incaricato di un ente deve utilizzare i servizi offerti secondo cooperazione applicativa da un altro ente si tratta quindi di utenti interni il modello sin qui delineato mantiene la sua validità ed utilità anche in questo scenario anche in questo caso agli enti sono associabili i loro domini informatici Roma, 16 febbraio

33 l interazione tra domini l interazione tra domini informatici all interno del dominio di cooperazione segue le linee guida promosse da CNIPA, che troveranno implementazione nel lavoro del task INF-1 tra domini cooperanti esiste una relazione di fiducia legata all accesso ai servizi offerti attraverso la porta di dominio ogni dominio servizio specifica i propri accordi di servizio nei confronti degli altri domini Roma, 16 febbraio

34 la sicurezza tra i domini ogni dominio è libero di decidere negli accordi di servizio quali saranno le politiche di autorizzazione all accesso ai servizi un primo livello di accordo di servizio prescriverà quali siano le porte delegate autorizzate all uso dei servizi di una porta applicativa un secondo livello potrà giungere a specificare politiche di accesso diverse per gruppi di utenti diversi all interno del medesimo dominio richiedente Roma, 16 febbraio

35 la sicurezza tra i domini non è pratico né corretto autorizzare singolarmente gli utenti dei domini esterni, ma è possibile e utile che essi siano categorizzati in base ai ruoli ricoperti nel dominio richiedente è un modello basato sui ruoli: si autorizza chiunque, sotto la responsabilità del dominio richiedente, ricopre un dato ruolo circoscrive bene gli ambiti di responsabilità e evita ai domini la complicazione di dover riconoscere utenti esterni Roma, 16 febbraio

36 la sicurezza tra i domini il modello basato sui ruoli richiede: un albo dei ruoli condiviso a livello di dominio di cooperazione l esistenza di relazioni di fiducia tra i domini in merito ai ruoli che rilasciano la modellazione del laboratorio, basata sulle autorità di certificazione nel dominio di cooperazione, agisce a supporto di queste esigenze Roma, 16 febbraio

37 Roma, 16 febbraio lo scenario di interazione l incaricato di un dominio richiedente si fa riconoscere dal proprio servizio di front-end per mezzo di un sistema legacy, o di un sistema già conforme alle specifiche del modello INF-3 quando il front-end attiva il servizio di back-end del dominio esterno (dominio erogante), la porta delegata inserisce nella richiesta le asserzioni relative ai ruoli dell incaricato le asserzioni sono firmate da autorità riconosciute dal garante il dominio erogante può autorizzare in base ad esse il circle of trust lega tra loro i due domini

38 Roma, 16 febbraio scenario di esempio Dominio fruitore Dominio 1: servizi di front-end Dominio 2: servizi di back-end 1 Richiesta di servizio Service Provider Service Provider creazione portafoglio delle asserzioni 3 Access Manager 2 Autentica e autorizza richiesta servizio back-end Access Manager 10 Autentica e autorizza inoltro richiesta 4 9 protezione portafoglio (WS-Security) 5 INF-3 GATEWAY (neutral semantic) Local Semantic Adapter (WS) INF-3 GATEWAY (neutral semantic) Local Semantic Adapter (CORBA) 8 estrazion portafog 6 invio a dominio 2 consegna a dominio 2 7 PDD 1 PDD 2 CANALE DI COMUNICAZIONE SICURO E AFFIDABILE

39 Roma, 16 febbraio il ruolo di INF-3 nella cooperazione i servizi INF-3 agiscono come un middleware tra il livello dei servizi e quello di trasporto SERVIZIO 1 Richiesta di servizio SERVIZIO 2 FEDERAZIONE AUTENTICAZIONE AUTORIZZAZIONE SAML. FEDERAZIONE AUTENTICAZIONE AUTORIZZAZIONE INF-3 TRASPORTO (Porte di dominio) SOAP, HTTP, HTTPS... TRASPORTO (Porte di dominio) INF-1 INF-2

40 Roma, 16 febbraio risultati salienti del laboratorio ideazione di un modello distribuito e federato per le attribuzioni di identità ideazione di un modello a supporto del trust distribuito con l introduzione di un autorità garante leggera modello adatto a interazioni sia G2C/G2B sia G2G uso di standard aperti apertura verso prodotti di terze parti, open source o commerciali, che implementino questi standard