Analisi dei possibili soggetti fiduciari per la gestione di identità in rete

Transcript

1 Università deglistudidifirenze Facoltà di Ingegneria Dipartimento di Elettronica e Telecomunicazioni Corso di Laurea in Ingegneria delle Telecomunicazioni Elaborato per il corso di Sistemi Telematici Anno Accademico 2009/2010 Analisi dei possibili soggetti fiduciari per la gestione di identità in rete 16/07/2010 Candidato Alessandro Grechi alessandrogrechi@gmail.com Tutor Maria Chiara Pettenati pettenati.mariachiara@gmail.com

2 Indice Introduzione iv 1 Pubbliche Amministrazioni il Modello di Riferimento Approccio Metodologico Modello Concettuale L Identità Federata nelle PA Modalità di interazione fra i servizi federati Sicurezza e Privacy Identificazione sicura Privacy Interoperabilità European Interoperability Framework (EIF) La Situazione Italiana Soluzioni per la gestione di identità Sistemi di Indentità Federata SAML Liberty Alliance WS-Federation

3 Indice ii OpenID Shibboleth Sistemi SSO (Single Sign-On) Microsoft Passport Facebook Connect Google Altri Providers Conclusioni Pubbliche Amministrazioni Soluzioni private Bibliografia 32

4 Elenco delle figure 1.1 Possibili interazioni tra membri di una federazione Utilizzo di una applicazione federata via web Utilizzo di una applicazione federata tramite cooperazione applicativa I livelli di Interoperabilità Scenario di Interoperabilità Europea Modello Concettuale di Interconnessione tra le PA Approcci diversi alla Gestione di Identità Federata adottati in alcuni paesi Comparazione tra differenti soluzioni per la Gestione di Identità Federata

5 Introduzione Che cosa è l identità? Generalmente è Cosa sei? Cosa ti piace?. In una visione allargata l identità è anche la reputazione: Cosa dico su di me? Cosa dicono gli altri su di me? Nel mondo reale l identità può venire accertata in modo diretto o verbale solo se conosciamo (o ci fidiamo) dell interlocutore. Altrimenti il metodo più utilizzato è l utilizzo di carte identificative, rilasciate da un autorità terza (e di solito certificata e ritenuta affidabile dalle parti), contenente i principali dati e la foto. Ma come avviene lo scambio di identità sul web? Il problema di fondo è che Internet ed i browser non sono stati pensati per identificare univocamente gli utenti. Quando facciamo l accesso ad un sito immettendo username e password, in realtà non stiamo accertando che siamo fisicamente noi, ma che qualcuno in possesso di quelle credenziali sta lavorando o immettendo dati. E analogo ad una chiave di casa: chiunque in possesso della chiave giusta può entrare, anche se non autorizzato. Una identità digitale di questo tipo è semplicemente quello che il sito web conosce su di te. Ciascuno di noi può avere più identità, dipendenti dal contesto. Così come nella vita reale possiamo avere un passaporto, una patente di guida, una tessera universitaria, una carta di credito che, pur appartenendo alla

6 Introduzione v medesima persona, abilitano differenti funzioni nei rispettivi contesti, così nel mondo digitalizzato abbiamo una fragmentazione dell identità. Il problema è che non c è un modo semplice, affidabile e sicuro per gestire questo complesso portafoglio di identità digitali. Il quadro che si sta delineando è dunque la presenza di una propria identità digitale frammentata e dispersa per la rete e questo si traduce non solo in un moltiplicarsi di password, account e profili ma anche di un importante rischio per la propria privacy, dato che è spesso improbabile, se non impossibile, tener traccia di tutti i propri dati e aver la possibilità di gestirli, aggiornarli, modificarli o semplicemente cancellarli. Dato che saranno sempre necessari tanti e diversi tipi di identità, l idea di una identità unica, centralizzata e gestita da un solo sistema è sicuramente da scartare. Il problema dell identità non si limita a quella dei servizi Internet. Con la crescente diffusione dell e-government, la necessità di soluzioni sicure ed affidabili per la gestione delle identità dei cittadini si è fatta molto più stringente. Anche nell ambiente della Pubblica Amministrazione ci troviamo di fronte ad una identità (del cittadino) frammentata e dispersa in molteplici banche dati. La soluzione ideale è un framework che sia trasparente all utente finale, ma che abiliti nel back-office tutta una serie di procedure finalizzate a collegare in modo sicuro i vari frammenti dell identità del cittadino. In questo elaborato saranno analizzati i possibili soggetti fiduciari per la gestione di identità, sia per i privati che per le pubbliche amministrazioni, focalizzando l attenzione soprattutto sulla gestione di identità federata. Concluderò con un confronto tra le varie soluzioni analizzate.

7 Capitolo 1 Pubbliche Amministrazioni Il primo soggetto che è conveniente prendere in considerazione come Identity Provider sono le Pubbliche Amministrazioni (PA). Appare naturale pensare alle PA come soggetti a cui affidare la gestione della nostra identità in quanto posseggono già intrinsecamente alcuni requisiti: Potere di legiferare Possesso dei dati amministrativi Lo scopo è il benessere dei cittadini Fiducia dei cittadini e delle imprese Presenza capillare sul territorio Le pubbliche amministrazioni per loro natura sono in possesso di database contenenti informazioni sui cittadini ad ogni livello: dati anagrafici, stato civile, situazione contributiva, retributiva, sanità, ecc. La maggior parte di queste banche dati però sono distribuite in luoghi e piattaforme diverse,

8 Capitolo 1. Pubbliche Amministrazioni 2 spesso non interoperabili tra loro e con dati ridondati. In uno scenario ottimo il cittadino dovrebbe essere in grado di utilizzare la propria identità digitale senza doversi preoccupare di dove i dati sono salvati, quali attributi servono e che tipo di procedure sono necessarie per ottenerli. Tutte le operazioni di questo tipo dovrebbero avvenire automaticamente nel back-office, attraverso comunicazioni sicure ed affidabili tra le PA (B2B: Back-office to Back-office). Il nocciolo della questione a questo punto si sposta sulla scelta del Modello di Gestione Federata delle Identità Digitali (GFID) 1.1 il Modello di Riferimento Un modello GFID di riferimento, sviluppato nell ambito italiano dal CNI- PA è l SPCoop, il modello condiviso di cooperazine applicativa per la P.A., la cui ultima revisione (1.5) è stata approvata nel dicembre 2008 [1]. Il modello si basa sulla realizzazione di un framework cooperativo che integra policy (relazioni di trust) ed infrastrutture tecnologiche fra le entità federate. Implementando il modello le amministrazioni federate avranno accesso a molteplici nuove applicazioni tramite il riutilizzo delle credenziali e delle identità già utilizzate al loro interno, mantenendo inalterate le modalità con cui vengono gestite le identità dai singoli enti Approccio Metodologico Lo scenario di riferimento alla base del modello è quello di un ente, più propriamente una amministrazione centrale od una amministrazione locale, che offre ai propri utenti oltre ai suoi servizi specifici anche la possibilità di fruire di servizi offerti da altre Amministrazioni. Il modello descritto trae

9 Capitolo 1. Pubbliche Amministrazioni 3 ispirazione dagli standard ad oggi esistenti (SAML-Core, SAML-TechOv, WS-Security) oltre che dalle esperienze estere già in essere, inoltre valorizza lo sforzo che le Regioni hanno compiuto nell ambito del task INF-3 del del progetto ICAR nell ambito della gestione federata delle identità digitali e della cooperazione applicativa. [2] L approccio utilizzato parte inizialmente dalla definizione delle informazioni utilizzate nel modello per la gestione delle identità digitali. A valle delle definizioni si introducono le entità logiche del modello assieme alle loro responsabilità. Successivamente si descrivono gli scenari in ambito di interazione in modalità di cooperazione applicativa ed autenticazione federata degli utenti appartenenti ai soggetti cooperanti. Gli scenari descritti sono scenari generali, indipendenti dai possibili procedimenti amministrativi o dalle amministrazioni coinvolte. Le modalità di cooperazione che di volta in volta verranno individuate per portare a termine un determinato procedimento dovranno essere riportate ad uno degli scenari descritti nel modello Modello Concettuale Il contesto di riferimento del modello è il Sistema Pubblico di Connettività (SPC) ed in particolare il sistema pubblico di cooperazione (SPCoop). L SP- Coop è il sottosistema dell SPC che comprende i sistemi di cooperazione applicativa e di interoperabilità e si basa sui seguenti principi: É un modello di cooperazione indipendente dai soggetti cooperanti in termini di asset informatici e tecnologici. Ogni soggetto cooperante mantiene la responsabilità dei propri servizi e dei dati da esso gestiti e custoditi. La cooperazione applicativa è regolata sulla base di accordi tra le parti.

10 Capitolo 1. Pubbliche Amministrazioni 4 Tali principi vengono tradotti in un architettura ed un modello organizzativo basato su elementi come: La cooperazione, che si basa su accordi servizio che descrivono l accordo stipulato fra le parti riguardo l erogazione/fruizione del servizio in questione. Ogni amministrazione gestisce i flussi informativi appartenenti alla cooperazione applicativa tramite un unico point of contact indicato con il termine Porta di dominio dei Servizi Applicativi. Risulta chiaro che per soddisfare tali necessità la cooperazione fra differenti amministrazioni, o generici soggetti pubblici, deve essere supportata da una infrastruttura, non riconducibile a nessuna amministrazione specifica, in grado di supportare e facilitare la cooperazione fra amministrazioni. Tale componente è indicato con il termini SICA (Servizi di Interoperabilità, Cooperazione ed Accesso). Il contesto di riferimento descritto trova nella gestione delle identità federate il modo più naturale per conciliare gli obiettivi di cooperazione fra differenti amministrazioni con la necessità di generare un basso impatto a livello implementativo ed infrastrutturale, cosi da mantenere gli investimenti operati sugli asset tecnologici da parte di ogni soggetto cooperante L Identità Federata nelle PA Il concetto di identità federata è una delle evoluzioni più interessanti legate all identity management, essa assimila ed estende alla cooperazione applicativa i concetti tipici del modello RBAC (Role Based Access Control), in cui i

11 Capitolo 1. Pubbliche Amministrazioni 5 diritti di accesso ad una data risorsa sono basati sul ruolo posseduto dall utente. Una gestione delle identità federata prevede in pratica la creazione di relazioni di fiducia tra realtà diverse per l identificazione e l autorizzazione degli utenti di una di esse ad accedere alle risorse governate da un altra. L identità Federata è governata da un complesso di relazioni di trust appropriate che compongono un ambito fiduciario comune identificato in letteratura come Circle of Trust. [3] Il Circle Of Trust si basa su: l accreditamento e la validazione all interno del dominio federativo. enti che ricoprono il ruolo di certificatori/validatori delle identità. un insieme di accordi (policy) che comprendono un modello comune all interno della federazione. la definizione di precise responsabilità nell ambito della cooperazione. Il principio è di creare un layer di astrazione che mascheri i sistemi, eventualmente già presenti, per la gestione delle identità. Attraverso esso aziende o amministrazioni diverse possano condividere le informazioni sulle identità e la sicurezza pur mantenendo inalterate le proprie soluzioni di gestione degli account utente e degli accessi applicativi. A livello macro all interno della federazione l utente che vuole fruire di un servizio applicativo deve in primo luogo autenticarsi presso il proprio dominio (dominio fruitore) presentando le sue credenziali. Il dominio fruitore, in caso di verifica positiva, emette un messaggio che garantisce l identità dell utente verificando i privilegi (ruolo) associati all utente che sta chiedendo l accesso. Il dominio fruitore terminate le verifiche invia le informazioni al dominio erogatore del servizio applicativo dove vengono elaborate. Il compito del dominio erogatore è garantire che l accesso dell utente sia coerente con le procedure e le politiche locali.

12 Capitolo 1. Pubbliche Amministrazioni 6 Per garantire il livello di integrazione descritto serve necessariamente un sistema standard per passare le informazioni di sign-on ed eventualmente di autorizzazione fra i due domini federati. Il framework SAML nasce per indirizzare tali esigenze. Come mostrato in figura 1.1 i macro scenari per un utente sono: 1. Utilizzo di un applicazione all interno del proprio dominio (evidenziato in giallo), è il tipico caso di un ente che ha il proprio sistema di gestione di Identity e Access Management. In questo caso non c è cooperazione. 2. Nomadicità (evidenziato in grigio), l utente richiede direttamente tramite il suo browser un applicazione federata appartenente al dominio erogatore. Il richiedente viene diretto presso il proprio dominio per potersi autenticare e solo dopo può fruire dei servizi richiesti presso il dominio erogatore. 3. Utilizzo di un applicazione federate tramite web services (evidenziato in nero), l utente si è autenticato presso un applicazione locale che coopera con una applicazione appartenente ad un altra Amministrazione. Nel caso 2 bisogna far interagire i domini federati tramite un bridge (indicato il figura come Federation Gateway) con l obiettivo di : trasformare le informazioni da veicolare all interno della federazione (l identità ed i ruoli) in linguaggio SAML così da poter essere recepite dalla controparte e tradotte nel linguaggio interno adottato per controllare gli accessi alle applicazioni; disaccoppiare l amministrazione dalla complessità della federazione, l Amministrazione deve limitarsi ad interagire con il FG tramite pochi comandi SAML.

13 Capitolo 1. Pubbliche Amministrazioni 7 Nel caso 3 invece si utilizza la Porta di Dominio, che similmente al FG è il point of contact per i flussi informativi appartenenti alla cooperazione applicativa. Figura 1.1: Possibili interazioni tra membri di una federazione Il modello, anche se inizialmente affronta la problematica ad un livello più astratto, prende sin da subito come riferimento il Framework SAML come metodo per comunicare le asserzioni di identificazione ed autorizzazione fra i domini federati Modalità di interazione fra i servizi federati Possiamo individuare due modalità di accesso ai servizi erogati da una PA. 1. Accesso al gateway tramite web

14 Capitolo 1. Pubbliche Amministrazioni 8 2. Accesso tramite Porte di Dominio (caso di cooperazione applicativa) Accesso via web Figura 1.2: Utilizzo di una applicazione federata via web Lo scenario è centrato sull utente: è lui che interagisce con tutti i soggetti coinvolti. 1. Verifica Identità con l IP 2. Associazione Profilo con l AP 3. Recupero Uri dall AARS 4. Verifica attributi con l AA 5. Accesso al servizio

15 Capitolo 1. Pubbliche Amministrazioni 9 Cooperazione Applicativa Qui al centro dello scenario non troviamo più l utente, ma l Applicazione, che interagisce con le entità presenti per verificare le credenziali e gli attributi del soggetto richiedente ed abilitarlo al servizio. Figura 1.3: Utilizzo di una applicazione federata tramite cooperazione applicativa 1. Richiesta Servizio all interno della proprio Amministrazione 2. Verifica Identità con l IP 3. Associazione Profilo con l AP 4. Recupero Uri dall AARS 5. Verifica attributi con l AA 6. Cooperazione Applicativa

16 Capitolo 1. Pubbliche Amministrazioni Sicurezza e Privacy All interno del quadro presentato possiamo individuare due problematiche fondamentali che dobbiamo prendere in considerazione nella realizzazione di un sistema federato di identità all interno della Pubblica Amministrazione: 1. Garantire la sicurezza e la privacy dei dati dei cittadini, nonché un accesso sicuro ad essi; 2. Implementare politiche e tecniche di collaborazione tra le varie PA. Quello a cui i cittadini sono interessati in primo luogo è la sicurezza che i dati forniti siano preservati in luoghi sicuri, non accessibili a terzi senza il proprio consenso. Per garantire queste richieste sarà opportuno implementare delle policy di accesso, nonché garantire la sicurezza attraverso sistemi crittografici, in modo che possano essere visualizzati solamente da chi ha le credenziali per farlo Identificazione sicura Come identificare in modo sicuro ed univoco il cittadino che vuole accedere ai servizi oppure gestire la propria identità? Una coppia username/password non sembra sufficiente a garantire i requisiti richiesti, dato che chiunque in possesso di questi dati (spesso trascritti in luoghi accessibili) potrebbe assumerne l identità senza possibilità di essere scoperto. Il sistema attualmente più utilizzato (e probabilmente anche quello più opportuno) è l utilizzo di Smart Card elettroniche, con microchip contenenti certificati e chiavi di sicurezza. Attraverso uno sportello abilitato, o tramite un lettore attaccato al computer, il cittadino può quindi identificarsi al sistema in tutta sicurezza, ancor di più se a questa viene associato un PIN numerico.

17 Capitolo 1. Pubbliche Amministrazioni 11 Secondo le attuali norme italiane, la carta che servirà a tale scopo è la Carta di Identità Elettronica (CIE), che progressivamente prenderà il posto degli attuali documenti cartacei. La sua implementazione è stata rimandata nel corso degli anni, ed attualmente è la data per l inizio del suo impiego (al di là dei comuni-pilota già abilitati) è fissata per l 1/1/2011, salvo ulteriori proroghe. In questi anni di transizione sono stati avviati anche progetti locali o interregionali che utilizzano carte alternative, come la Carta Nazionale dei Servizi, che in alcune regioni coincide con la Tessera Sanitaria. Alla fine delle sperimentazioni però i progetti si sono sempre conclusi, con un evidente spreco di risorse e di denaro. Altri possibili sistemi che potranno aggiungersi alle Smart Card in futuro sono quelli di riconoscimento biometrico, per esempio delle impronte digitali o dell iride, che associano inequivocabilmente la carta al suo possessore Privacy É assolutamente prioritario che i dati raccolti e immagazzinati nelle banche dati vengano salvati ed elaborati con tutte le accortezze necessarie a garantire la loro integrità ed inviolabilità. Sarà dunque opportuno dotare i server di sistemi crittografici sicuri, così come garantire la sicurezza nelle reti di telecomunicazioni attraverso l utilizzo di protocolli sicuri. Una recente alternativa alla crittografia potrebbe essere l utilizzo di tecniche di segmentazione: i dati generati dall utente vengono spezzettati e ordinati in modo casuale e poi inviati nella rete per essere salvati in server diversi. Anche in mancanza di una connessione sicura viene garantita l integrità dei dati, poiché solo l utente che li ha generati ha la capacità di ricostruirla dai singoli pezzi. [4]

18 Capitolo 1. Pubbliche Amministrazioni Interoperabilità Una volta che il cittadino ha fatto l accesso al sistema, non si dovrebbe preoccupare di dove il dato richiesto sia fisicamente presente. L accesso all identità dovrebbe dunque essere indipendente dal luogo fisico da cui accedo (es: Comune, ASL, Università, ministeri, uffici). Non è opportuno né conveniente creare un grosso database centrale. Affinché questo avvenga i database delle PA dovrebbero essere collegati tra loro. L interoperabilità non dovrebbe essere solo orizzontale, ma anche verticale: può sorgere infatti la necessità di accedere a banche dati nazionali e europee, per cui appare evidente come sia fondamentale garantire sistemi capaci di comunicare, nonostante le difficoltà intrinsiche. Definire standard aperti ed un framework condiviso è l unico modo per raggiungere lo scopo European Interoperability Framework (EIF) Interoperabilità significa lavorare insieme, collaborazione di sistemi, servizi e persone. Per lavorare insieme le persone hanno bisongno di comunicare e fare accordi. Devono accordarsi sui compiti da svolgere e su come scambiarsi i risultati ottenuti. Se inoltre provengono da nazioni differenti, devono trovare il modo di superare le barriere linguistiche, culturali e legali. Le Amministrazioni che forniscono servizi elettronici (eservices) hanno bisogno di elaborare una serie di accordi su un grande numero di problematiche, considerando aspetti organizzativi, semantici e tecnici. L European Interoperability Framework (EIF) [5] è stato stilato per risolvere tali problemi, in modo da facilitare l interoperabilità dei servizi di egovernment ad un livello pan-europeo. La versione 1.0 dell EIF, approvato nel 2004 dalla Commissione e sviluppato in collaborazione con un gruppo di esperti dei paesi membri,

19 Capitolo 1. Pubbliche Amministrazioni 13 Figura 1.4: I livelli di Interoperabilità si basa su questi principi fondamentali: 1. Accessibility 2. Multilingualism 3. Security 4. Privacy 5. Subsidiarity 6. Use of Open Standards 7. Assess the benefits of Open Source Software 8. Use of Multilateral Solutions

20 Capitolo 1. Pubbliche Amministrazioni 14 Tali direttive sono state largamente recepite a livello europeo, ma con la crescita dell e-government e dell IT negli ultimi anni si è reso necessario rivedere ed estendere il framework del E in corso di approvazione infatti la versione 2.0 dell EIF, di cui è già disponibile un Draft [6]. I punti centrali sono più o meno gli stessi, ma vengono estesi e trattati in modo molto più approfondito. Ne possiamo elencare 11: 1. Subsidiarity and Proportionality 2. User Centricity 3. Inclusion and Accessibility 4. Multilingualism 5. Security and Privacy 6. Administrative Simplification 7. Transparency 8. Preservation of Information 9. Openness 10. Reusability 11. Technological Neutrality and Adaptability 12. Effectiveness and Efficiency

21 Capitolo 1. Pubbliche Amministrazioni 15 Figura 1.5: Scenario di Interoperabilità Europea Figura 1.6: Modello Concettuale di Interconnessione tra le PA

22 Capitolo 1. Pubbliche Amministrazioni La Situazione Italiana Dopo aver visto i modelli generali e le direttive europee ci possiamo chiedere quale è la situazione attuale in Italia per quanto riguarda l e-government ed l e-identity. La situazione attuale è a dir poco confusionaria: Nonostante molti politici usino da anni parole come digitalizzazione ed e-gov, in pratica molto poco è stato fatto e molto c è ancora da fare. Quello che è mancato fino ad ora è un progetto a lungo termine coordinato da una forte regia centrale e abilitato da una specifica legge di attuazione, con adeguati finanziamenti. Fino ad ora ci sono stati solo progetti sperimentali frammentati, per lo più a livello locale o regionale. Per quanto riguarda le modalità di accesso, la strada verso cui si sta andando è l utilizzo della Carta di Identità Elettronica (CIE) come unico strumento abilitante per tutti i servizi. Prima che diventi diffusa e obbligatoria per tutti, però, dovranno essere risolti ingenti problemi organizzativi e soprattutto economici. Nel periodo transitorio sono stati previsti due modalità di accesso ai dati della PA ed ai servizi online offerti: l uso di carte elettroniche come la CNS o la Tessera Sanitaria, oppure la semplice (ed insicura) coppia username e password. Quest ultimo metodo, del tutto insicuro e obsoleto è stato di volta in volta prorogato (attualmente fino alla fine del 2010). Per adesso ogni amministrazione utilizza un proprio sistema, di solito incompatibile con gli altri, alla faccia dell interoperabilità. Il problema è che fino ad ora si è puntato più sui servizi che sull integrazione dei sistemi ed i progetti aggregativi locali (ad esempio PEOPLE) sono tutti morti una volta terminati i finanziamenti. Dal canto suo la politica fa molte promesse e pochi fatti: si fanno leggi spesso

23 Capitolo 1. Pubbliche Amministrazioni 17 inutili, perché non tengono conto di tecnica e implementazione. Le banche date attualmente utilizzate sono integrate e inaccessibili, speso per questioni meramente burocratiche. Negli ultimi anni abbiamo visto un susseguirsi di vari organismi che avrebbero il compito di promuovere, gestire e regolamentare la digitalizzazione: AIPA, poi CNIPA, riorganizzata quest anno nel DigitPA. Anche la stessa CIE, per quanto avanzata possa essere, pone delle problematiche che andranno prese in considerazione: qualcuno addirittura ritiene che la Smart Card sia una tecnologia già superata[7].

24 Capitolo 2 Soluzioni per la gestione di identità Le Pubbliche Amministrazioni non sono le uniche ad aver a che fare con la gestione dei dati degli utenti. Il Web attuale (definito 2.0, ma ormai qualcosa di ben oltre) non è più una vetrina di contenuti statici come era ai suoi albori: al centro non c è più il servizio offerto, ma l utente. Tutto è personalizzato e personalizzabile, l utente non è solamente fruitore passivo, ma anche creatore di contenuti, di informazioni, cittadino attivo della rete. Dato che molti servizi nati nel Web 2.0 si basano sulla creazione di profili, di solito un utente per fruire del servizio richiesto è obbligato ad inserire i propri dati personali. Nonostante ci siano alcune leggi che regolamentano la privacy, spesso non sappiamo mai veramente che fine fanno e come vengono trattati in nostri dati. In qualche modo dobbiamo fidarci del privato a cui li affidiamo, sperando che li usi solamente per gli scopi dichiarati. Al di là del problema della privacy, c è anche l esigenza dell utente di dover gestire una quantità notevole di servizi telematici e sociali: gestione bancaria,

25 Capitolo 2. Soluzioni per la gestione di identità 19 social networks, blog, forum, e-commerce, , instant messaging, ecc. 2.1 Sistemi di Indentità Federata Sono stati sviluppati diversi metasistemi o framework di identità per raggiungere gli scopi proposti. Essi si collocano tra il servizio finale offerto e l utente, implementando il livello di astrazione in più che serve al nostro scopo. Vediamo una panoramica dei principali. [8] [9] SAML SAML (Security Assertion Markup Language) è uno standard basato su XML su cui si appoggiano quasi tutti i sistemi attuali di gestione di identità. Il suo scopo è quello di scambiare dati di autenticazione e di autorizzazione tra domini di sicurezza distinti, di solito tra un Identity Provider (che fornisce le identità) e un Service Provider (che fornisce il servizio). SAML è uno standard mantenuto dall OASIS security Services Technical Committee ed ha avuto in passato diverse revisioni. Quella attuale, la 2.0 (marzo 2005), deriva anche dalla convergenza del Liberty ID-FF promosso dalla Liberty Alliance. SAML descrive la comunicazione al livello di messaggi XML (sotto forma di asserzioni, profili e attributi) tra Idendity Providers e Service Providers, senza descrivere le implementazioni specifiche dei sistemi, che quindi vengono lasciati alla scelta arbitraria dei singoli providers Liberty Alliance Liberty Alliance è un alleanza formata nel settembre 2001 con l obiettivo di stabilire uno standard aperto per la gestione di identità federata. Tra i suoi

26 Capitolo 2. Soluzioni per la gestione di identità 20 membri ci sono compagnie che si rivolgono ai consumatori, produttori di tecnologia e software, organizzazioni governative. Possiamo citare per esempio SUN, Fidelity, CA, AOL, Nowell, NTT, Oracle. Le specifiche di Liberty si basano su estensioni a SAML 1.1 che introducono carratteristiche importanti per la federazione multilaterale, come il global signout e l account linking. Queste estensioni sono state incorporate da OASIS nel SAML 2.0 nel marzo I concetti base sono: Single Sign-On, Single Lockout e circle of trust. Quest ultimo in particolare fa riferimento alla fiducia che gli Identity Providers e i Service Providers si creano intorno, basati su accordi tecnologici, operazionali e legali WS-Federation WS-Federation (2009) fornisce servizi per l identità federata simili a quelli della Liberty Alliance e di SAML 2.0. E supportata da Microsoft, IBM, VeriSign, BEA e RSA. Le differenze principali con Liberty Alliance sono nella tecnologia che c è sotto. WS-Federation si basa su componenti non supportati da Liberty, come WS-Trust e WS-Policy. WS-Federation utilizza SOAP per scambiare i messaggi, ma è compatibile anche con SAML sebbene non ne faccia ufficialmente parte OpenID Una soluzione completamente libera ed OpenSource, basata su standard aperti e riconosciuti. Lo scopo è fondamentalmente lo stesso, ma la forma è totalmente snella, flessibile e gratuita. Da qui il vantaggio di poter essere scalabile ed utilizzabile in tutte le realtà, dai piccoli siti alle grandi aziende. Tra i Providers che si sono già associati, possiamo elencare nomi

27 Capitolo 2. Soluzioni per la gestione di identità 21 importanti quali Google, Yahoo!, Microsoft, Google, MySpace, WordPress, Blogger, Verisign, Facebook, AOL. Il framework di OpenID è quello che probabilmente sta emergendo di più tra le soluzioni pensate per Internet, con una visione user-centrica. Si basa su tecnologie già esistenti (URI, HTTP, SSL) e parte dalla considerazione dal fatto che gli utenti creano in continuazione identità per sé stessi attraverso blogs, forum, profili ed è dunque facile pensare di utilizzare uno di questi URI già esistenti come account in tutti gli altri siti che supportano OpenID. Altra cosa positiva è che in OpenID non ci sono autorità centrali: non sono richieste registrazioni o approvazioni ed un utente può scegliere il proprio provider preferito, mantenendo il proprio identificatore personale anche se cambia provider in seguito. Nonostante sia supportato dalle maggiori Internet Company, quello di cui probabilmente ancora ha bisogno è quella spinta mediatica e sociale che lo elevi a soggetto preferito nelle gestione delle e-identities dei navigatori Shibboleth Shibboleth (2008) è un pacchetto opensource sviluppato e principalmente utilizzato in ambito accademico, ed è particolarmente adatto per domini in cui i soggetti hanno molto in comune, come le università, ma meno versatile di Liberty Alliance. Si basa anch esso su SAML e fornisce Single Sign-On, un framework per lo scambio di attributi, un sistema di accesso controllato a risorse condivise e garantisce inoltre estese funzionalità di privacy, dando all utente la possibilità di controllare gli attributi rilasciati alle applicazioni.

28 Capitolo 2. Soluzioni per la gestione di identità Sistemi SSO (Single Sign-On) In questa sezione vengono riportati alcuni sistemi che sono finalizzati esclusivamente a fornire il servizio di Single Sign-On, ovvero di autenticazione dell utente, senza dover ricorrere ad una gestione più avanzata dell identità. Soluzioni del genere sono comunemente usate nei siti web per identificare i propri utenti in modo semplice ed efficace Microsoft Passport Uno dei primi sistemi presentati è stato Microsoft Passport (ora conosciuto anche come Live ID) nel Una volta creato il proprio ID su questa piattaforma, è possibile utilizzarlo per accedere ai siti di terze parti che hanno implementato tale framework di autenticazione. Il punto di forza di questo sistema è sicuramente la centralità offerta da Microsoft, leader mondiale nel software per Personal Computer e in particolare per Windows, sistema operativo presente nel 90% dei computer; per questo probabilmente è uno dei sistemi di autenticazione più diffusi e utilizzati. Il funzionamento è semplice: l utente vede e riconosce il bottone di MS Passport, ci clicca, appare un popup in cui inserisce le credenziali Passport e viene automaticamente autenticato sul sito originario. Benché diffuso, questo sistema è stato in definitiva rifiutato dalla Comunità, principalmente per via dei suoi alti costi implementativi (che escludevano siti piccoli) difficoltà di installazione, codice chiuso e proprietario Facebook Connect Il social network che ha visto una maggiore crescita negli ultimi due anni è sicuramente Facebook. Un successo inimmaginabile anche nelle più rosee

29 Capitolo 2. Soluzioni per la gestione di identità 23 previsioni del suo inventore, Mark Zuckerberg. Partito da un idea innovativa e vincente, ha avuto l accortezza e lungimiranza di stare al passo con i rapidi cambiamenti in atto, implementando sempre nuove tecnologie con lo scopo di rendere il web più sociale, reclamando ovviamente su di sé lo scettro di re dei networks. Uno dei prodotti sicuramente più riusciti è il loro Facebook Connect, con gli stessi obiettivi degli altri metasistemi già citati. I punti di forza di Facebook Connect sono però tanti: La familiarità della piattaforma ed il successo del marchio: Ormai Facebook è il sito più visitato dalla maggioranza dei navigatori; molti di loro hanno iniziato ad utilizzarlo conoscendo ben poco dei social networks o addirittura prima di utilizzare le . Le sue procedure intuitive e la grafica sono diventate parte dell abitudine quotidiana di milioni di persone. Vedere un bottone blu con la scritta Facebook è istantaneamente riconosciuto e inconsciamente ritenuto affidabile. Una grande quantità di dati disponibili: Nei profili di Facebook gli utenti includono una grande varietà di informazioni riservate: dati anagrafici, luoghi di residenza, rete sociale, preferenze su prodotti e mercato, foto, ecc. La maggior parte di queste informazioni sono disponibili all esterno attraverso API documentate Profili Reali: La più grande differenze rispetto alle altre piattaforme è probabilmente il fatto che dietro la maggior parte dei profili si celano persone reali, associate al loro vero nome e cognome, cosa impensabile per la concorrenza (Accountability). Ormai l importanza della propria identità su Facebook è vista alla pari di quella reale, così come la reputazione che ne deriva. Molti fanno attenzione all immagine che vogliono

30 Capitolo 2. Soluzioni per la gestione di identità 24 dare agli altri di sé stessi, tanto che una esclusione dal network sarebbe vista da qualcuno come una stregua di suicidio digitale. Gestione centralizzata della privacy: Un altra cosa positiva è che gli utenti possono gestire la privacy dei dati in modo centralizzato ma anche granulare. Possiamo dunque decidere chi, tra i nostri contatti, ha il diritto di vedere cosa. I cambiamenti al profilo centrale si riflettono automaticamente a tutte le applicazioni di terze parti collegate, permettendo un controllo totale su di essi. Dobbiamo considerare però anche il rovescio della medaglia: i punti di forza elencati fin ora possono essere visti anche in chiave negativa. Negli ultimi mesi Facebook è stata accusata molte volte di giocare con la privacy degli utenti, lasciando molti dubbi sul loro effettivo utilizzo. La centralità ed il successo dell azienda sta portando ad un preoccupante monopolio dei dati, con tutte le conseguenze che questo potrebbe comportare. Essendo inoltre nato in modo service-oriented è pensato e costruito fin dall inizio per funzionare bene ai fini della piattaforma in questione, e non nell ottica di un apertura esterna. Come tutte le aziende private il fine ultimo di Facebook non è il benessere dei cittadini, ma il profitto. E quindi evidente che l azienda farà sempre di tutto per trarre il massimo guadagno dai dati raccolti, nei limiti delle leggi in vigore. La banca dati che ormai Facebook possiede sicuramente fa molto gola agli investitori che intravedono un ottima possibilità di pubblicità mirata sulle abitudini e sulle preferenze, dunque mirata Google Nella partita ovviamente non poteva essere assente la grande azienda di Mountain View, Google, che offre una grande quantità di prodotti diversi:

31 Capitolo 2. Soluzioni per la gestione di identità 25 , foto, video, blog, notizie, analisi dei siti web, note, calendari, ricerche web, documenti, geolocalizzazione, messaging... Per accedere a tutti questi prodotti è necessario un solo profilo. A sua volta tale profilo è utilizzabile (con le stesse modalità di OpenID e Facebook Connect) su siti di terze parti attraverso Friend Connect. Pur essendo molto diffuso, attualmente l utilizzo dei profili di Google come identità principali è molto limitato. Le ragioni sono semplici: pur non offrendo nulla di innovativo rispetto ai concorrenti, possiede i lati negativi di entrambi. Non è infatti un sistema aperto e libero come OpenID, né possiede gli utenti, la familiarizzazione con essi e l accountability tipica di Facebook. 2.3 Altri Providers Oltre ai metasistemi presentati, per lo più service-oriented, possiamo ipotizzare altri soggetti privati nel ruolo di Identity Providers: Banche: dovendo gestire il denaro degli utenti, devono per forza investire nella sicurezza delle transazioni di dati e di soldi. Potrebbero avere le infrastrutture giuste, ma probabilmente non avrebbero né le motivazioni, né l appeal per gli utenti, né tantomeno un sistema aperto (e quindi trasparente). Discorso a parte possiamo fare per servizi online come PayPal: un intermediario per i pagamenti (quindi esso stesso un middleware) che negli ultimi anni si sta imponendo come standard de-facto per l e-commerce online. Soprattutto grazie alla spinta di ebay, alle sicurezza utilizzata ed alle garanzie fornite, è riuscito a ottenere una buona fiducia degli utenti, che possono in questo modo effettuare pagamenti sicuri utiliz-

32 Capitolo 2. Soluzioni per la gestione di identità 26 zando semplicemente uno username ( ) ed una password, senza quindi reinserire i numeri di carta di credito. Operatori di Telecomunicazioni: la loro diffusione nel territorio e tra gli utenti potrebbe far pensare anche a loro. In effetti non mancherebbero le tecnologie necessarie (sia nel backend che nel frontend). Vengono infatti già utilizzati dei sistemi di identificazione via SMS: Inviare un SMS può essere già sufficiente infatti per associare un numero di telefono mittente ad una persona fisica titolare del contratto telefonico, che è già stata identificata in fase di registrazione del contratto stesso. Sistemi del genere vengono già utilizzati in ambienti mobili, per esempio per richiedere l accesso in mobilità ad hot-spot WiFi.

33 Capitolo 3 Conclusioni Dopo l analisi fatta sui i possibili gestori di identità digitale possiamo tirare alcune conclusioni. Abbiamo visto che esistono moltissimi sistemi diversi, che possono differire tra loro anche di molto. Ma quali sono i parametri di scelta che possono portare a scegliere una soluzione al posto di un altra? Non esiste una risposta secca, perché a seconda del contesto in cui operiamo e alle richieste del caso in esame una soluzione potrebbe essere più completa di un altra, ma allo stesso tempo rivelarsi troppo dispendiosa dal punto di vista economico, tecnico e organizzativo. Per esigenze di piccole aziende e siti internet, speso l unico requisito realmente necessario è il Single Sign-On ed in generale un Session Management che consenta di identificare l utente in modo univoco e semplice, adottando un sistema che sia meno costoso possibile (meglio se gratuito e Open Source), che sia interoperabile con altri sistemi (si basi dunque su standard aperti) e che sia facile da implementare e mantenere nel tempo. In questi casi, soluzioni come OpenID o comunque basate su SAML sembrano promettere il miglior rapporto funzionalità/semplicità, insieme con l estrema scalabilità.

34 Capitolo 3. Conclusioni 28 Se abbiamo a che fare con grandi aziende e federazioni di identità estese e complesse, abbiamo bisogno di qualcosa di più complesso. In questo caso le soluzioni migliori sono quelle che si basano sulla gestione di identità federata, per esempio Liberty Alliance o WS-Federation, o comunque basate su SAML 2.0. Anche qui dobbiamo tener conto delle risorse a disposizione per lo sviluppo, l implementazione e la gestione del sistema, che possono essere anche molto ingenti o sovradimensionate rispetto ai bisogni reali. Liberty Alliance, per esempio è sicuramente una soluzione molto versatile, ma per sua stessa natura molto articolata e complessa. In questo caso potremmo pensare di affidarci ad una implementazione commerciale di questi sistemi, comprendente sia il set-up che la gestione del sistema. [10] 3.1 Pubbliche Amministrazioni Per le pubbliche amministrazioni la questione presenta qualche differenza. Prima di tutto bisogna pensare una PA come una grande federazione di identità, suddivisa in tanti settori collegati tra loro sia in modo verticale che orizzontale. Risulta quindi fondamentale la scelta di un sistema scalabile che si adatti sia alle realtà locali ed ai piccoli enti, sia agli organismi governativi o anche sovranazionali. In generale ogni paese ha adottato una strada leggermente differente dagli altri, ciascuno in relazione ai propri bisogni, alla popolazione, alle risorse tecniche ed economiche disponibili. Certo, l adozione di un progetto completo a livello nazionale è cosa ben diversa che implementare un sistema di gestione di identità a livello di sito web o piccola azienda. Non solo per la dimensione del progetto, ma anche perché deve sottostare alle volontà e soprattutto ai tempi della Legge, che ben poco si coordina con il rapido sviluppo tecno-

35 Capitolo 3. Conclusioni 29 logico. In Italia il progetto presentato nel capitolo 1 è, dal punto di vista teorico, abbastanza completo e soddisfacente. Quello che manca adesso è un impegno concreto per l attuazione, in modo che le promesse politiche siano, almeno in questo, seguite da fatti. Probabilmente una spinta decisiva potrà venire dall Unione Europea, spingendo i governi dei singoli stati ad seguire delle raccomandazioni ed attuare delle politiche adatte a sviluppare un e-governement europeo avanzato. In figura 3.1 vediamo una tabella che riassume diversi approcci adottati in paesi del mondo diversi per cultura, posizione e popolazione alla Gestione dell Identità Federata. E interessante notare come molte delle soluzioni più recenti (Italia compresa) si basino su SAML e sull utilizzo di certificati digitali, dato che la sicurezza e la privacy sono un requisito imprescindibile quando si trattano dati dei cittadini. [9] 3.2 Soluzioni private Nella figura 3.2 sono riportate a confronto le principali caratteristiche dei sistemi di identità descritti nel capitolo 2. Vengono evidenziate la gratuità del sistema su vari livello, gli standard su cui si basa, i servizi offerti, la scalabilità della soluzione, la possibilità di gestire uno scambio di attributi di identità e la possibilità di utilizzare un certificatore di terze parti per alcuni attributi. Le soluzioni migliori, al di là delle singole differenze, sembrano comunque essere quelle basate sullo standard SAML 2.0 che garantisce il più alto grado di funzionalità e interoperabilità tra i sistemi.

36 Capitolo 3. Conclusioni 30 Figura 3.1: Approcci diversi alla Gestione di Identità Federata adottati in alcuni paesi

37 Capitolo 3. Conclusioni 31 Figura 3.2: Federata Comparazione tra differenti soluzioni per la Gestione di Identità

38 Bibliografia [1] Modello SPCOOP-GFID. [Online]. Available: http : // Coop ModelloGFID V 1.5.pdf [2] Progetto ICAR, task INF-3. [Online]. Available: http : //tinyurl.com/icarin F 3 [3] FIDIS, Liberty Alliance, Circle of Trust. [Online]. Available: http : // idis.net/resources/deliverables/privacy and legal social content/d142 study on privacy in business processes by identity management/doc/26/ [4] FOKUS SECURE EIDENTITY-LAB. [Online]. Available: http : // t estbeds/secure e identity lab/index.html [5] European Interoperability Framework v1.0. [Online]. Available: http : //ec.europa.eu/idabc/en/document/2319 [6] European Interoperability Framework v2.0 Draft. [Online]. Available: http : //ec.europa.eu/idabc/en/document/7733 [7] A. Osnaghi Perché fallisce l e-government. [Online]. Available: http : //saperi.f orumpa.it/story/33418/perche f allisce le government

39 BIBLIOGRAFIA 33 [8] D.Hardt: Passport vs OpenID vs Facebook Connect. [Online]. Available: http : //identity20.com/?p =153 [9] R. Baldoni, Federated Identity Management Systems in e- Government: the Case of Italy, Electronic Government: An International Journal, vol. 8, no. 1, [Online]. Available: midlab [10] A. Myllyniemi, Identity Management System - A Comparison of Current Solutions. [Online]. Available: