Autenticazione di Google Apps con un Identity Server di Ateneo utilizzando il protocollo SAML

Transcript

1 Università degli Studi di Parma Facoltà di Scienze Matematiche Fisiche e Naturali Corso di Laurea in Informatica Tesi di Laurea in Reti di Calcolatori Autenticazione di Google Apps con un Identity Server di Ateneo utilizzando il protocollo SAML Candidato: Riccardo Amaduzzi Relatore: Chiar.mo Prof. Roberto Aleri Correlatore: Dott. Ing. Marco Panella Anno Accademico 2007/2008

2 .

3 Ai miei genitori, sempre presenti. Alla Ary, il mio Amore. Ai miei Amici..

4 Indice 1 Introduzione Problema arontato Aspetti sviluppati Strumenti utilizzati Autenticazione e autorizzazione distribuita Panoramica sui protocolli di autenticazione Autenticazione Problematiche e Tecniche risolutive Autorizzazione Autorizzazione e motore di ricerca Single Sign-On Il Progetto Liberty Alliance AAI Shibboleth Informazioni generali su Shibboleth introduzione a Shibboleth Alcuni usi di Shibboleth Shibboleth 2.0 vs Shibboleth Internet Perchè Shibboleth Shibboleth e l'università di Parma Il progetto IDEM e l'università di Parma Identity Provider

5 Indice Service Provider Procedura di login tramite Shibboleth SAML Identità Federate Chi entra nel circolo La base di SAML Introduzione a SAML Perchè SAML Vantaggi rispetto alla versione precedente Caratteristiche del protocollo Asserzioni e protocolli Bindings Proles Metadati Autenticazione Considerazioni sulla privacy e la sicurezza Il progetto Google Apps & Unipr.it Cos'è Google Apps Perchè la Federazione Realizzazione del progetto Creazione account tramite attributi e cenni a LDAP Autenticazione con il protocollo SAML 2.0 e funzionamento Realizzazione del progetto di Single Sign On con Google Apps Un pò di codice Macchina virtuale Congurazione Tomcat Filtri IdP e attributi certicato Codice per eettuare collegamento e SSO con Google 99

6 Indice 5 7 Conclusioni Risultati ottenuti Cosa manca Utilizzo futuro del nuovo servizio di posta elettronica. 102 Bibliograa 104

7 Elenco delle gure 1.1 Attacco ai dati protetti Autenticazione tramite protocollo Kerberos Schema di funzionamento autenticazione tramite Kerberos Schema di funzionamento PKI Dierenza tra autenticazione web locale e autenticazione web centralizzata Homepage CAS2 Università degli Studi di Parma Esempio di funzionamento generico del CAS Senza AAI Con AAI federata Esempio di federazione AAI Esempio di Sessione IdP Esempio di sessione SP Schema procedura di login tramite Shibboleth Protocolli SAML Scambio messaggi di protocollo Accesso a Google Apps Utilizzando SAML

8 Capitolo 1 Introduzione 1.1 Problema arontato L'obiettivo della tesi consiste nello studio delle problematiche di autenticazione e autorizzazione in una federazione di domini distribuiti in rete. Il problema arontato riguarda l'autenticazione di Google Apps con un Identity Server di Ateneo utilizzando il nuovo protocollo SAML 2.0; lo scopo è quindi permettere all'utente di autenticarsi a Google utilizzando /password di Ateneo, mediante un redirect su un Identity server locale. Ovviamente l'utente deve appartenere all'università di Parma, può essere indistintamente uno studente, un professore, un membro del Centro di Calcolo, o qualsiasi utente che sia registrato su LDAP al Centro di Calcolo. Per svolgere le prerogative è stato attivato un contratto Education Edition con Google e al termine del progetto è stata personalizzato il nuovo sistema di posta tramite le API (Application Programming Interface). La parte teorica del progetto riguarda lo studio del protocollo SAML 2.0, delle sue caratteristiche, delle migliorie rispetto alle versioni precedenti e dei possibili usi futuri per quanto riguarda le applicazioni web. Per meglio comprendere le fasi successive dell'elaborato è importante introdurre il signicato del termine Identità in Rete e della sua evoluzione. L'Identità di un soggetto costituisce la base per le transazioni che preve-

9 1.1.1 Problema arontato 8 dono lo scambio di informazioni; non solo prova che egli è chi dichiara di essere, ma indica che cosa può fare e a quale risorsa può accedere. Quando si parla di federazione delle identità ci si riferisce all'istituzione di accordi di business e di strumenti crittograci per la gestione della ducia, per la condivisione di identicativi e di attributi utente tra domini di sicurezza separati per permettere l'interazione e l'interoperabilità tra i domini stessi e nei confronti dell'utente. L'utilizzo e lo sviluppo dell'identità digitale federata si è reso necessario in quanto le persone si spostano attraverso i conni di diversi ambiti di responsabilità in modo sempre più frequente e al tempo stesso è alquanto improbabile che si possa giungere ad una identità digitale unicata, in qualunque ambito che non possa essere identicato con un solo dominio di responsabilità. Il paradigma federato costringe quindi a ripensare i ruoli delle organizzazioni nella catena di servizio in quanto se prima fornitori di servizio e di identità erano la stessa organizzazione, ora appartengono a organizzazioni diverse: I fornitori di servizio (Service Provider, SP) presidiano l'oerta di funzionalità applicative; I fornitori di identità (Identity Provider, IdP) si specializzano nella gestione delle identità digitali. Uno dei proli di cooperazione più semplici è quello in cui un SP si avvale dei servizi di Identity Management oerti da più IdP e dove la federazione è l'ambito, duciario e contrattuale, che lega l'sp al centro della stella agli IdP; un altro semplice prolo di collaborazione è quello in cui un IdP ore i propri servizi a diversi SP e dove la federazione lega l'idp a tutti i SP che desiderano trarre vantaggio dalla capacità di Identity Management dell'idp. A un livello di maturità maggiore si situa il prolo Multi-provider che vede una molteplicità tanto di IdP quanto di SP, legati in una federazione ampia, ovvero in un ambito duciario in cui ci si accorda su un insieme di regole comuni e un comune modello di trust e di responsabilità (si parlerà in seguito di circle-of-trust). Un progetto di federazione necessita di stabilire regole tecniche tra le parti: occorre innanzi tutto una sintassi comune che specichi la forma degli oggetti scambiati, una grammatica comune che indichi quale signicato attribuire

10 1.1.1 Problema arontato 9 agli oggetti ed inne una semantica comune che indichi quali proli di interazione e casi d'uso vengono previsti. Per soddisfare questi requisiti bisogna porsi alcune domande come: quali sono le relazioni di ducia tra le parti? come si garantisce la ducia end-to-end? come si garantisce la privacy dell'utente? Ancor prima di questo dobbiamo chiederci: come può l'ente erogatore del servizio accertare l'identità dell'utente? Utilizzando il metodo tradizionale, ovvero utilizzando una procedura di autenticazione che permette all'utente di dimostrare il possesso di un dato segreto noto solo all'utente stesso e all'ente (Identity Management locale); oppure utilizzando un metodo federato: l'ente ripone ducia nell'assunzione di responsabilità da parte di un Identity Provider che riconosce l'utente (Identity Management delegato). Di questo argomento si tratterà ampiamente nel capitolo secondo. Inoltre verranno analizzati i motivi per i quali l'identità federata garantisce tutti i classici requisiti di sicurezza logica quali autenticazione, autorizzazione, integrità, condenzialità e ducia tra le organizzazioni che ne fanno uso. L'identità federata permette quindi il raggiungimento dell'equilibrio tra la sicurezza delle transazioni e la semplicità di utilizzo degli strumenti online da parte degli utenti nali; è l'identità che un singolo utente può utilizzare per accedere a un determinato gruppo di siti Web collegati fra loro. Senza una identità federata, gli utenti sono costretti a gestire credenziali diverse per ogni sito che utilizzano. Con il passare del tempo questa raccolta di ID e password diventa dicile da gestire e controllare, oltre a essere più esposta a eventuali furti di identità. La gestione dell'identità federata si basa sulla relazione sicura tra l'azienda e l'individuo in quanto consente all'utente di utilizzare un'unica relazione di accesso alle informazioni con un'altra azienda collegata, senza dover denire nuove credenziali. In ultima istanza una identità federata ore ad aziende, istituzioni, dipendenti e clienti una soluzione più comoda e sicura per accedere alle risorse distribuite, senza perdere il controllo dei dati sensibili, e rappresenta una componente chiave per promuovere l'utilizzo dell'e-commerce e dei

11 1.1.1 Problema arontato 10 Figura 1.1: Attacco ai dati protetti servizi personalizzati, nonché dei servizi Web in generale. Le motivazioni più importanti che hanno portato allo sviluppo del progetto sono state: 1. riuscire ad avere una visione omogenea e coerente dell'intero sistema dal punto di vista delle relazioni tra individui e le risorse alle quali consentire l'accesso; 2. migliorare la qualità del servizio (posta elettronica universitaria), semplicandone gli accessi e la navigazione; 3. trovare una soluzione che riducesse costi, gradi di complessità e punti di intervento per l'amministrazione, evitando di dover intervenire di volta in volta sulle singole applicazioni e sui vari componenti del sistema. L'utilizzo dell'identità federata ha permesso all'utente nale di utilizzare le credenziali fornite dal proprio ente di appartenenza (Università degli studi di Parma); all'università di mantenere il controllo sul processo di autenticazione e sull'accesso ai servizi remoti da parte dei propri utenti; al fornitore di servizi (nel caso specico del progetto si tratta di Google) di evitare gli oneri di gestione delle credenziali personali e di disporre, per l'autorizzazione e la congurazione e/o personalizzazione del servizio di attributi relativi all'utente concordati con la federazione e trasmesse a cura dell'università.

12 1.1.1 Problema arontato 11 Quando si parlerà di attributi verra analizzato SAML 2.0 come protocollo standard per lo scambio delle informazioni di autorizzazione tra i domini dell'università di Parma e di Google Apps, il quale è stato scelto come caso d'uso di dominio federato con l'università, per le sue caratteristiche che ben si adattavano allo sviluppo del progetto.

13 1.1.2 Aspetti sviluppati Aspetti sviluppati Prima di entrare nel dettaglio del progetto realizzato è stato eettuato uno studio approfondito degli standard, delle applicazioni e delle tecnologie disponibili e utilizzabili per poterlo realizzare. Lo studio è stato rivolto inizialmente alle caratteristiche generali dell'autenticazione e Autorizzazione analizzandone i vantaggi e le dierenze fra l'implementazione in ambiente locale e distribuito (capitolo secondo), descrivendo i signicati di password, Kerberos, PKI, Single-Sign-On e CAS, portando come esempio locale le ACL su le e directory e come esempio distribuito la centralizzazione di ruoli e attributi su un directory server. E' stato in seguito esaminato Shibboleth 2.0 e i suoi utilizzi nell'ambito del progetto (capitolo terzo) e studiato nel dettaglio il protocollo SAML 2.0 (capitolo quarto). Dopo una breve panoramica sul progetto Google Apps - sviluppato da Google - verrà descritto nel dettaglio il progetto realizzato (capitolo quinto), ne verranno indicati gli utilizzi, le aspettative, i vantaggi, i risultati ottenuti ma anche le mancanze e i possibili miglioramenti che potrebbero essere apportati in futuro. 1.3 Strumenti utilizzati Per sviluppare il progetto sono stati scelti strumenti rigorosamente Open Source fra cui i seguenti: CentOS : Community ENTerprise Operating System, versione 5.1; IdP e SP Shibboleth2 : sviluppati da internet2; Java 6 : fornita da Sun, versione ; Apache2 : fornito da the Apache Software Foundation; Tomcat versione ; Google Apps : servizi forniti da Google gratuitamente alle organizzazioni universitarie.

14 Capitolo 2 Autenticazione e autorizzazione distribuita Autenticazione e Autorizzazione sono i concetti principali della gestione dell'accesso e dell'identità. L'autenticazione riguarda il problema di assicurare l'identità del processo con cui si sta comunicando; l'autorizzazione si occupa, invece, di stabilire che cosa può fare un processo. Solitamente la fase di autorizzazione consiste solamente in una ricerca dentro tabelle locali o in un DataBase; per questo motivo l'attenzione del progetto è stata rivolta soprattutto alla fase di autenticazione, portando ad esempio alcuni tipi di implementazioni in ambito locale e distribuito. Inoltre è stato approfondito lo studio per quanto riguarda l'approccio Single Sign-On che permette di eliminare, fra le altre cose, la necessità di eseguire l'accesso più volte quando si visualizzano dati protetti, fornendo un ambiente più sicuro per la comunità, nel nostro caso in quella universitaria Panoramica sui protocolli di autenticazione L'autenticazione è la tecnica usata dai processi per vericare che la loro controparte nella comunicazione sia veramente chi dice di essere, e non un impostore. Il modello generale utilizzato da tutti i protocolli è il seguente: l'utente A

15 Panoramica sui protocolli di autenticazione 14 inizia la comunicazione inviando un messaggio all'utente B o a una terza persona considerata data - solitamente il KDC (Key Distribuition Center) - e in seguito è previsto lo scambio di altri messaggi, in varie direzioni, che possono essere intercettati, modicati o rinviati da parte di un utente ingannevole che intende contrastare i due interlocutori. In molti protocolli gli utenti A e B stabiliscono anche una chiave segreta (chiave di sessione) da usare per continuare la loro conversazione, anche se nella realtà per motivi prestazionali tutto il traco è cifrato con la crittograa a chiave simmetrica, mentre la crittograa a chiave pubblica è largamente usata nei protocolli di autenticazione per stabilire una chiave di sessione. Le ragioni dell'utilizzo di una dierente chiave casuale per ogni nuova connessione sono molteplici: minimizzare la quantità di traco inviato usando le chiavi permanenti degli utenti (segrete o pubbliche), ridurre la quantità di testo cifrato che può cadere nelle mani di un intruso, e minimizzare i rischi connessi alla situazione in cui un processo vada in crash e il relativo core dump cada nelle mani sbagliate. Progettare un protocollo di autenticazione è molto più complicato di quanto sembri; per essere sicuri di svolgere un procedimento corretto è importnte seguire sempre quattro regole base: fare in modo che chi inizia l'autenticazione provi la sua identità prima che lo faccia chi risponde; fare si che i due soggetti, cioè chi inizia l'autenticazione e chi risponde, usino due chiavi dierenti per provare la loro identità; far si che i due soggetti utilizzino, per le richieste, numeri presi da insiemi diversi; rendere il protocollo resistente ad attacchi che coinvolgono una seconda sessione parallela, dove le informazioni ottenute da una sessione possono essere usate per l'altra. Vediamo ora alcune fra le implementazioni più utilizzate per eettuare la fase di Autenticazione. L'autenticazione tramite Password è il metodo più semplice fra quelli analizzati e consiste come è noto nell'inserimento di uno username e di una password che viene vericata quando si tenta di accedere ad un'area privata;

16 Panoramica sui protocolli di autenticazione 15 la sua semplicità comporta grossi problemi dal lato pratico in quanto viene ampiamente meno il fattore sicurezza Un protocollo di autenticazione usato in molti sistemi reali è invece Kerberos, progettato per fornire un accesso sicuro alle risorse di rete agli utenti di workstation; il protocollo è pensato per fornire sicurezza di autenticazione su reti aperte e insicure dove la comunicazione tra gli host che ne fanno parte può essere intercettata. Bisogna tuttavia essere consapevoli, che Kerberos non dà nessuna garanzia se le macchine in gioco sono vulnerabili: i server di autenticazione, i server applicativi (imap, pop, smtp, telnet, ftp, ssh) e i client devono essere mantenuti costantemente aggiornati anché si possa garantire l'autenticità dei richiedenti e dei fornitori di servizi. Figura 2.1: Autenticazione tramite protocollo Kerberos Ecco di seguito quali sono gli obiettivi che tale protocollo vuole raggiungere: 1. la password dell'utente non deve mai viaggiare sulla rete; 2. la password dell'utente non deve mai essere memorizzata in nessuna forma sulla macchina client: essa dopo essere utilizzata deve essere subito scartata;

17 Panoramica sui protocolli di autenticazione le password dell'utente non dovrebbero essere memorizzate in chiaro neanche nel database dei server di autenticazione; 4. all'utente è richiesto di inserire la password una sola volta per sessione di lavoro. Potrà pertanto accedere, durante detta sessione, a tutti i servizi per il quale è autorizzato, in modo trasparente, senza dover reinserire la password. Questa procedura è nota come Single Sign-On, e verrà descritta nel prossimo paragrafo; 5. la gestione delle informazioni di autenticazione è centralizzata e risiede sul server di autenticazione. I server applicativi non devono contenere informazioni di autenticazione dei loro utenti; 6. non solo gli utenti devono dimostrare di essere chi dicono di essere, ma, quando richiesto, anche i server applicativi devono provare la loro autenticità ai client; questa caratteristica prende il nome di Mutua autenticazione; 7. se richiesto, dopo che l'autenticazione e l'autorizzazione sono avvenute, client e server devono poter stabilire una connessione criptata. A tal scopo, Kerberos fornisce supporto alla generazione e allo scambio di una chiave crittograca da utilizzare per cifrare i dati. Kerberos suppone che tutti gli orologi siano sincronizzati e utilizza tre server in aggiunta alla workstation client: Authentication Server (AS) : verica gli utenti durante il login; Ticket Granting Server (TGS) : emette tiket che provano l'identità di chi li possiede; Server ricevente : compie il lavoro che il client ha richiesto. L'AS condivide una password segreta con ogni utente, mentre il TGS ha il compito di emettere dei tiket da usare per convincere i server veri e propri del fatto che il loro possessore è realmente chi dichiara di essere. Kerberos fa fronte al rischio intercettazioni utilizzando la cifratura simmetrica e un sistema dato di terze parti - KDC - per autenticare gli utenti di una rete e consentire loro di accedere ai servizi desiderati. Avvenuta l'autenticazione, Kerberos immagazzina un ticket specico per quella sessione

18 Panoramica sui protocolli di autenticazione 17 sul computer dell'utente e tutti i servizi kerberizzati, per eettuare l'autenticazione, invece di chiedere la password all'utente cercheranno direttamente quel ticket. Quando un utente si collega alla propria workstation connessa a una rete Kerberos, il suo principal viene inviato al KDC sotto forma di richiesta TGT. Questa richiesta può essere inviata dal programma di login (in modo trasparente) o dal programma kinit una volta che l'utente si è collegato. Il KDC controlla il principal nel suo database. Se viene trovato, crea un TGT, lo cifra usando la chiave dell'utente e lo invia come risposta all'utente. Il programma di login o kinit decifra il TGT utilizzando la chiave (che ricava dalla password dell'utente). La data di scadenza viene impostata in modo che un TGT compromesso possa essere utilizzato solo per un periodo limitato (che generalmente è di otto ore); questo è un metodo più sicuro rispetto a quello tradizionale basato sulla password, poiché una password compromessa può continuare a essere utilizzata nché non viene cambiata. In seguito, non occorre che l'utente reinserisca la password se non quando scade il TGT o quando si ricollega; quando un utente deve accedere a un servizio di rete, il client utilizza il TGT per richiedere un ticket per il servizio al Ticket Granting Service (TGS), in esecuzione sul KDC. Figura 2.2: Schema di funzionamento autenticazione tramite Kerberos

19 Panoramica sui protocolli di autenticazione 18 Lo scopo del protocollo è rendere l'utente client in grado di accedere ai server su tutta la rete in modo sicuro senza che la sua password debba mai essere trasmessa sulla rete; infatti la password rimane sulla workstation, e solo per pochi millisecondi. E' importante comunque sottolineare che ogni server si prende carico delle proprie autorizzazioni: quando il client presenta al server il suo ticket, questo serve solo a dimostrare al server l'identità del client, stabilire che cosa il client sia autorizzato a fare è compito del server. Kerberos non è comunque la soluzione ottimale in quanto è un protocollo di autenticazione per host dati su reti non di ducia: a nulla servono le strategie di Kerberos se qualcuno che ottiene accesso privilegiato ad un server, può copiarsi il le contenente la chiave segreta. L'impostore, infatti, metterà tale chiave su di un'altra macchina e gli basterà ottenere un semplice spoof di DNS o di indirizzo IP perché tale server appaia nei confronti dei client il server autentico. Tuttavia esistono metodi di gran lunga migliori, in quanto più ecienti e sicuri, quindi maggiormente utilizzati per la creazione di infrastrutture di comunicazione. Uno di questi è il PKI - Public Key Infrastructure -, ovvero una infrastruttura a chiave pubblica composta da una serie di accordi che consentono a terze parti date di vericare e/o farsi garanti dell'identità di un utente, oltre che di associare una chiave pubblica a un utente, normalmente per mezzo di software distribuito in modo coordinato su diversi sistemi. Le chiavi pubbliche tipicamente assumono la forma di certicati digitali. La struttura della PKI non solo riguarda la CA (Certication Authority), ma anche: la Registration Authority, attraverso la quale gli utenti si rivolgono per richiedere la certicazione delle chiavi, identicandosi e fornendo almeno la chiave pubblica e l'indirizzo . il Certicate Server ovvero un servizio di directory accessibile mediante un operational protocol, tipicamente LDAP (di cui si parlerà in seguito); esso è principalmente una lista di pubblicazione dei certicati e delle liste di certicati revocati e sospesi.

20 Panoramica sui protocolli di autenticazione 19 Gli accordi alla base di una PKI consentono agli utenti di essere mutualmente autenticati, e di utilizzare le informazioni contenute nei rispettivi certicati per cifrare e decifrare i messaggi in transito. In generale una PKI consiste di software client, software server (ad esempio un'autorità di certicazione), hardware e procedure operative. Un utente potrebbe rmare i propri messaggi con la sua chiave privata, e un altro utente controllare questa rma usando la chiave pubblica contenuta nel certicato del mittente, fornito dall'autorità di certicazione facente parte della PKI. Questo procedimento consente a due (o più) parti desiderose di comunicare di vericare la condenzialità, l'integrità dei messaggi e l'autenticazione degli utenti senza il bisogno di un precedente scambio di informazioni segrete. Figura 2.3: Schema di funzionamento PKI La maggior parte delle PKI al livello delle imprese fanno adamento su catene di certicati per stabilire l'identità delle parti: un certicato viene emesso da un'autorità di certicazione, a sua volta autenticata da un certi- cato emesso da un'autorità di livello più alto, e così via. In questo modo si stabilisce una gerarchia di certicati, composta da computer, organizzazioni e pacchetti software diversi. Gli standard sono fondamentali per il funzionamento di una PKI, e gli standard pubblici sono fondamentali per le PKI di uso esteso. Molti degli standard nel campo delle PKI sono opera del gruppo di lavoro PKIX della IETF. Le PKI a livello di impresa sono spesso strettamente legate ai servizi di di-

21 2.2.1 Autenticazione 20 rectory dell'azienda, in cui la chiave pubblica di ogni dipendente può essere memorizzata (incorporata in un certicato) assieme ad altri dettagli personali (numero di telefono, indirizzo , dipartimento...). Oggi la principale tecnologia per i sistemi di directory è LDAP e il formato più comune usato per i certicati è X.509, uno standard che denisce una PKI. 2.1 Autenticazione Col termine Autenticazione si denisce il processo tramite il quale un computer, un software o un utente verica la corretta identità di un utente che vuole comunicare attraverso una connessione. Nell'accesso ad alcuni servizi messi a disposizione dal Web è importante per l'utente denire in modo univoco la propria identità, essere riconosciuto e per questo ottenere l'accesso ai propri servizi; allo stesso modo è fondamentale conoscere l'identità di chi si trova dall'altra parte della linea di comunicazione ed essere certi che l'interlocutore col quale si stanno scambiando informazioni sia veramente chi dice di essere. L'autenticazione può essere eseguita in diversi modi. Lo standard più comune di autenticazione, indipendentemente dal fatto che venga eseguito in base alla directory o all'applicazione, è composto dal nome utente e dalla password. I problemi di sicurezza relativi a questo metodo potrebbero anche non essere gravi, a seconda dell'ambiente in cui ci troviamo. Tuttavia la 'sda' posta dalle ricerche in ambito aziendale (e universitario) consiste nell'associare il metodo più idoneo di autenticazione in base a ciò che si vuole ottenere. Un metodo di autenticazione più eciente può avere un ruolo di primaria importanza quando un insieme di dati riservati può essere visualizzato dagli utenti; è quindi possibile che il nome utente e la password non rappresentino più un metodo di autenticazione accettabile. Nel contempo, la valutazione degli utenti o la conoscenza eettiva degli utenti viene limitata dal costo o dal fatto di non essere un elemento della losoa aziendale, per questo sono stati sviluppati strumenti in grado di porre ne a questi problemi quali i certicati, la biometria e l'autenticazione a più fattori dell'infrastruttura a

22 2.2.1 Autenticazione 21 chiave pubblica (PKI). Le esigenze di una struttura possono essere soddisfatte grazie a tre concetti a livello di autenticazione di base. 1. Livello di autenticazione 1 - Un Utente può eseguire l'accesso alla propria stazione di lavoro con un nome utente e una password corretti. 2. Livello di autenticazione 2 - I dati di accesso sono obbligatori per eseguire l'accesso manuale o tramite Single Sign-On (SSO) a ogni link relativo a dati sensibili. 3. Livello di autenticazione 3 - Viene utilizzata l'autenticazione a due o più fattori che usa la biometria o un certicato x509 per visualizzare le informazioni sui certicati, convertire i certicati in diverse forme, rmare le richieste di certicati o modicarne le impostazioni di sicurezza. Le ACL - Access Control List - sono uno strumento utilizzato per denire dierenti livelli di sicurezza per i vari utenti all'interno di un sistema; attraverso le ACL si cerca di regolamentare l'accesso ad un certo oggetto in funzione del processo che tenta di accedere alla risorsa. Anche se si tratta di un concetto abbastanza ampio, che può essere applicato in diversi ambiti della sicurezza informatica, ci limiteremo a prendere in esame solamente la gestione dei permessi dei le. Esistono dierenti implementazioni di ACL, che rappresenta uno dei più alti livelli di astrazione nella gestione dei permessi. Tra le sue applicazioni principali, ci sono la congurazione di Firewall e dei diritti di accesso a le e directory. Una ACL è una lista ordinata di regole che viene usata per prendere una decisione, ad esempio se far transitare o meno un pacchetto lungo un canale o se permettere o meno ad un certo utente l'accesso ad un le. Ciascuna regola, detta Access Control Entry (ACE), esprime una o più proprietà dell'oggetto da valutare (ad esempio, l'indirizzo sorgente di un pacchetto IP), e se queste proprietà sono vericate indica quale decisione prendere (ad esempio, far passare il pacchetto oppure riutarlo). La valutazione inizia dalla prima regola e continua no a quando le condizioni di una regola non sono vericate. Se le condizioni sono vericate, la valutazione nisce e viene applicata la decisione presa, altrimenti, la valu-

23 Problematiche e Tecniche risolutive 22 tazione prosegue alla regola successiva. Se nessuna regola viene soddisfatta, viene applicata una decisione di default, denominata policy dell'acl Problematiche e Tecniche risolutive Il semplice uso della combinazione username/password può creare problemi ai fornitori di servizi: gli utenti tendono a dimenticare la password; un numero crescente di chiamate o di che giungono ai centri di assistenza riguarda password dimenticate. Inoltre costi dell'attivazione di nuove password stanno diventando un onere gravoso per i gestori; sempre più utenti si connettono a Internet in modi diversi, ma esigono lo stesso servizio dal fornitore. I vari tipi di accesso possono fondarsi su congurazioni tecniche diverse, dall'accesso tramite un PC al WAP, anche se la maggior parte delle volte la connessione a Internet avviene da computer diversi, in Internet caè o biblioteche pubbliche: in tal modo gli utenti sono costretti a ricordare svariate password; alcuni utenti inne non amano inserire nome utente e password in quanto lo considerano un ostacolo alla navigazione. Gli utenti tendono a minimizzare lo sforzo richiesto scegliendo password brevi che non risultano sicure e spesso sono utilizzate per accedere a diversi siti. Qualsiasi soluzione ai tre problemi citati comporta una delega parziale del processo di autenticazione da parte dell'utente. Attualmente le tecniche più utilizzate sono quattro: 1. La gestione della password è delegata al browser sul PC dell'utente, come nel caso del gestore di password Mozilla. Sebbene l'utente non deve reinserire ogni volta la password la soluzione non è ottimale in quanto non viene risolto il problema di utenti mobili che accedono ai servizi da PC diversi. Nessuna impresa esterna controlla i dati. 2. La gestione della password è delegata a un proxy server su Internet, messo eventualmente a disposizione da un fornitore di servizi Internet. In questo caso anzichè utilizzare il browser come gestore delle

24 2.2.2 Autorizzazione 23 password si ricorre alla stessa funzione integrata in un proxy server; un proxy server può servire numerosi utenti quindi è necessario registrare una password per utente e per sito visitato: Nel procedimento di autenticazione l'utente deve identicarsi sul proxy il quale dopo l'identicazione ore all'utente i servizi richiesti. Rispetto alla soluzione precedente il vantaggio del proxy consiste nella possibilità di accedervi da diversi PC e/o da altri dispositivi. 3. L'autenticazione è gestita da terzi che utilizzano un protocollo di autenticazione specico. Si tratta di protocolli con la stessa architettura basilare che consiste di tre parti: utente nale, fornitore di servizi e provider di autenticazione; prima di accedere al fornitore di servizi, l'utente nale deve far vericare l'identità al provider di autenticazione. Il fornitore di servizi ha un rapporto di ducia col provider di autenticazione e consente l'accesso all'utente. 4. L'autenticazione è eettuata da una parte contraente nell'ambito di un circuito di ducia; viene utilizzato un protocollo specico, come quello del Liberty Alliance project. Il sistema Liberty Alliance utilizza un modello federato in cui l'utente può registrarsi congiuntamente presso due fornitori di servizi. Quando l'account è stato registrato, un fornitore di servizi accetta l'integrazione con l'altro, che funge da servizio di autenticazione. 2.2 Autorizzazione L'autorizzazione fornisce una soluzione al problema di bilanciamento dei diritti degli utenti in modo che possano svolgere le proprie attività. La mappatura dei dati o dei risultati di ricerca corretti nell'ambito dei diritti dell'utente e la visualizzazione di tali dati rappresentano un problema. Le directory integrate e i certicati SSO e PKI sono esempi di servizi di autorizzazione che possono essere utilizzati per facilitare l'identicazione degli utenti e per convalidarne l'identità.

25 Autorizzazione e motore di ricerca 24 Di seguito, vengono riportati alcuni esempi di concetti a livello di autorizzazione: 1. Livello di autorizzazione 1 - Chiunque può accedere alle informazioni interne pubbliche ed è solo necessario avere l'accesso alla rete. 2. Livello di autorizzazione 2 - Le informazioni sono riservate ed è necessario disporre di dati di accesso secondari per la visualizzazione. 3. Livello di autorizzazione 3 - Applicato ai dati sensibili, a cui hanno accesso solo gruppi specici Autorizzazione e motore di ricerca Gli SPI di autorizzazione consentono ai motori di ricerca di utilizzare le credenziali degli utenti memorizzate all'esterno degli schemi di autenticazione; l'implementazione dell'spi di autorizzazione si basa sugli standard SAML 2.0 e attraverso i quali viene eseguita la codica. Quando un utente esegue una ricerca e il motore di ricerca deve determinare se i risultati possono essere visualizzati contatta l'host di destinazione, o connettore di accesso, utilizzando l'url o la destinazione in questione e l'identità dell'utente; ogni volta, l'host di destinazione, in base agli standard SAML 2.0, consentirà, negherà l'accesso o darà una risposta indeterminata. Questa funzione viene attivata dal protocollo di accesso (SOAP)tramite HTTPS. 2.3 Single Sign-On Una delle tecniche maggiormente adottate per risolvere i problemi legati all'autenticazione è il Single Sign On (SSO): un sistema specializzato che permette ad un utente di autenticarsi una sola volta e di avere accesso a tutte le risorse informatiche alle quali è abilitato. Si parla infatti di sistema basato su SSO quando le richieste di autenticazione non vengono direttamente gestite dal sistema stesso ma vengono redirette verso un altro sistema di autenticazione che ha precedentemente certicato le credenziali dell'utente connes-

26 2.2.3 Single Sign-On 25 so, senza avere quindi la necessità di richiedere nuovamente le credenziali per l'accesso. Il SSO ha fra gli obiettivi principali quelli di: semplicare la gestione delle password (riduzione numero password in uso per ogni utente); semplicare la gestione degli accessi ai vari servizi; semplicare la denizione e la gestione delle politiche di sicurezza. Si cerca quindi di rendere la sicurezza trasparente all'utente nale, in quanto questi deve rendersi conto di lavorare in un sistema sicuro, senza vivere la sicurezza come un onere aggiuntivo. Figura 2.4: Dierenza tra autenticazione web locale e autenticazione web centralizzata Altro vantaggio signicativo del SSO è la scalabilità: un soggetto che si autentica presso un certo Identity Provider può accedere a risorse protette da un Service Provider, in quale non ha bisogno di mantenere internamente

27 2.2.3 Single Sign-On 26 informazioni sul soggetto; tale fenomeno ha come conseguenza diretta un considerevole aumento dei soggetti servibili a parità di investimento. Nell'ambiente Web il SSO si applica esclusivamente all'accesso autenticato a risorse web, tipicamente eettuato tramite un browser; i soggetti che accedono ad una tale risorsa per la prima volta nell'arco di una stessa sessione, vengono rediretti presso un servizio di autenticazione Identity Provider). A seguito di un esito positivo dell'autenticazione, questi vengono rediretti nuovamente presso la risorsa inizalmente richiesta, protetta da un Service Provider, a cui verranno comunicati gli aggiornamenti sullo stato di autenticazione di tali soggetti. L'approccio al SSO è quindi di tipo federativo: non viene imposta l'adozione di un particolare IdP, ma vengono forniti gli strumenti per stringere legami di ducia con una Federazione di tali providers, senza vincoli gerarchici precostituiti. Proprio in virtù dell'esigenza di semplicare le procedure di autenticazione nasce il concetto di Federated Identity Management, e quindi di uno standard Liberty Alliance utilizzato nell'ambito di Fidelity. Infatti nel futuro gli sforzi principali delle organizzazioni si focalizzeranno per dare vita a un numero sempre maggiore di reti federate, per consentire ai Service Provider di realizzare specici accordi economici e commerciali con gli Identity Provider, i quali diventeranno non solo i gestori delle credenziali di identicazione degli utenti, ma anche i fornitori di servizi evoluti di e-business, e-government, e- health. In questo modo, grazie agli accordi preventivi stabiliti nel contesto della rete federata, è possibile realizzare un ambiente sicuro e semplicato per tutte le transazioni del navigatore in rete. L'utente internet, del tutto garantito in termini di protezione della privacy, può navigare da un sito all'altro in modalità Single Sign On, ossia con una sola e unica password di autenticazione. In altre parole se l'accesso alla rete è tanto sicuro quanto il più possibile semplicato, ne trae benecio tutto il sistema, sia in termini di adabilità dei servizi sia sotto il prolo dell'economia di gestione. Il CAS - Central Authentication Service - è un sistema di autenticazione sviluppato in origine da Yale University per fornire a una applicazione un

28 2.2.3 Single Sign-On 27 modo adabile per autenticare un utente; è un protocollo Sign-On che permette alle applicazioni web la possibilità di rinviare tutte le autenticazioni a un server centrale o a più server di ducia; il suo scopo è quello di consentire a un utente di accedere a più applicazioni in modo simultaneo ed automatico; esso consente inoltre ad applicazioni inattendibili di autenticare gli utenti senza avere accesso alle credenziali di sicurezza, come ad esempio la password. Consente quindi di concentrare in un unico punto l'autenticazione di tutte le applicazioni Web dell'organizzazione. Al momento dell'autenticazione il client viene dirottato sul server CAS con un canale cifrato HTTPS e dopo l'autenticazione con credenziali standard (password Posix e Certicati X.509) ritorna sull'applicazione avendo a disposizione un Token utilizzabile per autenticazioni successive (Single Sign On). I limiti di questo tipo di utilizzo stanno nella scalabilità limitata e nella scarsa essibilità nella denizione delle Policy di accesso (Autorizzazione). Il protocollo CAS è composto da almeno 3 parti: un client browser web, la richiesta di autenticazione di una applicazione web, e il server CAS; può anche implicare un servizio di back-end, come ad esempio un server database, che non ha una propria interfaccia HTTP, ma comunica con una applicazione web. Quando il client visita una applicazione che richiede l'autenticazione la richiesta viene reindirizzata al CAS, il quale convalida l'autenticità del cliente, di solito mediante il controllo di una username e password su una banca dati (come Kerberos o Active Directory). Se l'autenticazione ha esito positivo, CAS rimanda il client all'applicazione richiesta, accompagnandolo con un ticket di sicurezza; l'applicazione quindi valuta il ticket contattando il CAS su una connessione sicura e fornendogli il proprio servizio di identicazione e il ticket; a questo punto CAS restituisce all'applicazione informazioni circa l'avvenuta autenticazione dell'utente. CAS consente l'autenticazione multitier tramite proxy. Un database o un server di posta, può partecipare al CAS, convalidando l'autenticità degli utenti attraverso le informazioni che riceve da applicazioni web: in questo modo, un client webmail e un server webmail possono implementare il CAS.

29 2.2.3 Single Sign-On 28 Scopi principali del Central Authentication Service: facilitare il Single Sign-On su più applicazioni web; consentire l'autenticazione degli utenti senza dover accedere alle loro password; semplicare le procedure che le domande devono seguire per eseguire l'autenticazione. localizzare l'autenticazione a un unica applicazione web, che rende più facile per gli utenti salvaguardare le proprie password e che consente di modicare la sua autenticazione logica, se necessario, senza dover cambiare numerose applicazioni. Vediamo ora una panoramica architetturale del protocollo. Il server di autenticazione centrale (CAS) è concepito come una applicazione web standalone. E 'attualmente implementato come diversi servlet Java e passa attraverso il server HTTPS su secure.its.yale.edu. Si accede attraverso tre URL qui di seguito descritte: l'url di accesso, l'url di convalida, e l'url di logout che è opzionale. Per utilizzare il servizio di autenticazione centralizzato, una applicazione reindirizza i suoi utenti, o semplicemente crea un collegamento ipertestuale all'url di login. Ad esempio, l'url di login del CAS dell'università di Parma utilizzato per l'implementazione del progetto è la pagina cas2.unipr.it. Gli utenti possono inoltre accedere a questo indirizzo manualmente, se desiderano pre-autenticare le loro sessioni. Per consentire la possibilità di una ri-autenticazione successiva, il CAS permette di inviare un cookie (che scade automaticamente quando il browser viene chiuso) indietro al browser; tale cookie identica l'utente come uno che ha già eettuato l'accesso con successo. Vale la pena di notare che questo cookie è una parte opzionale del meccanismo di autenticazione del CAS; con esso, l'utente ottiene l'aspetto di single sign-on a più applicazioni web; ovvero inserisce il suo username e password solo una volta e può accedere a tutti i servizi che utilizzano il CAS. Senza il cookie, l'utente dovrebbe inserire il suo username e la password ogni volta che una applicazione lo reindirizza al

30 2.2.3 Single Sign-On 29 Figura 2.5: Homepage CAS2 Università degli Studi di Parma CAS (gli utenti possono dirigere il CAS di distruggere il cookie andando ad un logout URL). In aggiunta a trattamento primario di autenticazione, il CAS rileva inoltre il servizio da cui l'utente è stato reindirizzato (linkato); questo si può fare in quanto le applicazioni che reindirizzano a un utente l'url di accesso sono tenute a trasmettere al CAS un identicatore di servizio. Se l'autenticazione ha esito positivo, il CAS crea un lungo numero casuale, che noi chiamiamo ticket; quindi associa il ticket all'utente che ha autenticato con successo e il servizio per il quale l'utente stava cercando di autenticarsi. Ciò signica che, se l'utente è passato dal servizio S, il CAS crea il ticket T che permette di accedere a servizi di S. Questo ticket è inteso come un one-time-use-only, è utile solo per l'utente in questione, solo per il servizio S, e solo una volta; scade appena viene utilizzato. Una volta che l'autenticazione primaria è completata, il CAS reindirizza il browser dell'utente all'indietro alla applicazione dalla quale proviene. Il CAS reindirizza il browser dell'utente indietro a questo URL, aggiungendo il ticket discusso in precedenza come un parametro della richiesta.

31 Il Progetto Liberty Alliance 30 Figura 2.6: Esempio di funzionamento generico del CAS Il Progetto Liberty Alliance Costituito nel 2001, è un consorzio che comprende organismi senza scopo di lucro e svariati governi. L'obiettivo è denire standard 'aperti' per un'identità federata sulla rete attraverso speciche tecniche non proprietarie. L'autenticazione semplicata (simplied sign-on) e l'identità federata sulla rete (un sistema per collegare diversi account a un dato utente) rappresentano elementi chiave del sistema; l'autenticazione unica (single sign-on) consente al cliente di identicarsi una sola volta presso un provider di identità per navigare poi sui siti dei diversi fornitori di servizi all'interno di un dominio di ducia senza doversi identicare nuovamente. Il sistema funziona nell'ambito di domini o circuiti di ducia; si tratta di una federazione di fornitori di servizi e provider di identità le cui relazioni commerciali si basano sull'architettura di Liberty Alliance e su accordi operativi attraverso i quali i committenti possono eettuare transazioni in un ambiente sicuro e privo di ostacoli. 2.4 AAI L'obiettivo della AAI (Authentication Authorization Infrastructure) consiste, in sintesi, nella semplicazione dell'iter-organizzativo per l'accesso alle risorse web; ad esempio con un unico login uno studente può accedere a sistemi e-

32 2.2.4 AAI 31 Figura 2.7: Senza AAI Figura 2.8: Con AAI federata learning di più università. La AAI si avvale di un concetto chiamato Federated Identity Management che comprende la gestione e l'utilizzo di informazioni di identità attraverso i domini di sicurezza (security domains), come ad esempio tra le singole università. Tratta questioni quali interoperabilità, responsabilità, sicurezza, privacy e ducia. Tutte le parti coinvolte traggono vantaggio da uno standard AAI: A causa dell'id virtuale, le risorse possono risparmiare lo sforzo di registrare e gestire gli utenti sulla base di informazioni personali. Grazie a delle interfacce standardizzate, le risorse possono integrare gli utenti di altre organizzazioni senza molto sforzo.

33 2.2.4 AAI 32 Tramite un meccanismo di autenticazione standard, gli utenti sono autorizzati ad accedere a varie risorse di un certo numero di organizzazioni con una sola password, indipendentemente dalla loro ubicazione. Al giorno d'oggi gli studenti vogliono un accesso semplice e sicuro a risorse web di cui hanno bisogno per svolgere le loro mansioni, anche a quelle situate al di fuori delle università a cui sono iscritti. Al tempo stesso, gli amministratori delle risorse web desiderano fornire agli utenti un accesso sicuro e il diritto di utilizzare le loro risorse, con il più basso overhead possibile. È qui che AAI mostra i suoi punti di forza in quanto permette un accesso facile e sicuro alle applicazioni web. Senza un AAI, un utente è registrato con ogni risorsa a cui vuole l'accesso e per ognuna di queste è richiesto l'invio di una coppia di record <nome utente - password>, chiamate credenziali. I problemi di questo approccio sono evidenti in quanto gli utenti hanno a che fare con troppi nomi utente e password (solitamente è necessaria una coppia per ogni risorsa) e ogni amministratore di risorse deve registrare i propri utenti. La AAI semplica le procedure per tutte le parti coinvolte nel processo utilizzando il concetto di gestione delle identità federate: 1. Un utente si registra una sola volta con la sua organizzazione a cui è direttamente collegato (CAS Università Parma). L'organizzazione è quindi responsabile del mantenimento delle informazioni correlate all'utente e lo annuncia tramite le sue credenziali. Le organizzazioni possono essere istituzioni come università, biblioteche, università, ospedali etc. 2. L'autenticazione è sempre eettuata dall organizzazione madre dell'utente, che può anche fornire ulteriori informazioni sull'utente alla risorsa, su richieste di altre risorse e consensi personali; fatto questo, tutte le risorse AAI abilitate sono a disposizione di un utente utilizzando un unico set di credenziali. Allo stesso tempo, non vi è alcuna necessità per gli operatori della risorsa di registrare nuovi utenti, in quanto (gli operatori) sono in grado ottenere le informazioni richieste direttamente da parte degli utenti dell'organizzazione.

34 2.2.4 AAI La risorsa prende una decisione sul controllo dell'accesso basandosi sulle informazioni recuperate riguardanti l'utente. In tal modo la gestione delle identità federate si basa sul concetto che le risorse richieste a seguito di una autenticazione da parte dell'utente alla sua organizzazione ottengono da questa alcune informazioni riguardanti l'utente per le sue autorizzazioni. Una federazione è un insieme di organizzazioni che decidono di interoperare sottostando a determinate regole. Le federazioni di solito deniscono autorità e attributi, tramite la distribuzione di metadati che rappresentano tali informazioni. In generale ogni organizzazione che partecipa a una federazione gestisce un Identity Provider per i suoi utenti e uno svariato numero di Service Providers. Figura 2.9: Esempio di federazione AAI

35 Capitolo 3 Shibboleth Informazioni generali su Shibboleth introduzione a Shibboleth Shibboleth è una iniziativa inter-universitaria volta sviluppare una soluzione open source che consenta alle organizzazioni lo scambio di informazioni sui propri utenti in modo sicuro e rispettoso della privacy. E' basato su SAML (Security Assertion Markup Language) ed è stato sviluppato da Internet 2 e da un gruppo di architetti middleware (MACE) con la collaborazione di membri appartenenti alle università e alle imprese partner che hanno preso parte a questo progetto le cui nalità sono la progettazione, la specica e l'implementazione open source di sistemi per la condivisione di risorse web soggette ad autenticazione. Lo scopo del progetto consiste nel semplicare il problema dell'accesso a contenuti didattici riservati fra più campus universitari, ciascuno dei quali con una dierente infrastruttura di autenticazione, e gestire lo scambio di informazioni per determinare se una persona, utilizzando i browser web (ad esempio Mozzilla Firefox, Netscape Navigator, Internet Explorer), possieda o meno i permessi per accedere a una risorsa o a un target di risorse. Soluzione aperta signica avere contemporaneamente una architettura e un funzionamento 'aperto' e una implementazione open-source, mentre basata su standard signica che le informazioni scambiate tra organizzazioni devono

36 introduzione a Shibboleth 35 essere in grado di interoperare con informazioni provenienti da altre soluzioni software. I concetti chiave all'interno di Shibboleth includono: Amministrazioni federate di cui abbiamo parlato in precedenza; Controllo degli accessi basato su attributi: le decisioni sul controllo di accesso sono eettuate utilizzando tali asserzioni. La raccolta delle asserzioni può includere l'identità, anche se in molte situazioni questa non è richiesta (ad esempio, per l'accesso a una risorsa a disposizione degli studenti di un particolare corso, o per l'accesso a una licenza di una risorsa utilizzata da tutti i membri attivi di una determinata comunità). Active management della privacy: il sito di origine e il browser dell'utente controllano quali informazioni sono rilasciate al target; un tipico valore di default è semplicemente un membro della comunità. Le persone sono in grado di gestire individualmente i loro attributi (release) tramite una interfaccia utente basata sul web: la conseguenza fondamentale è che gli utenti non sono più in balia delle norme sulla privacy. Shibboleth è basato su standard: utilizza OpenSAML per il formato dei messaggi e delle asserzioni, e vincoli di protocollo basati su Security Assertion Markup Language (SAML) sviluppato dal Security Service OASIS (di questo protocollo si tratterà nel capitolo successivo). Un framework facilmente scalabile adatto a un insieme di utenti: Shibboleth fa uso delle politiche di insieme per specicare una serie di parti dell'insieme che hanno acconsentito all'uso di politiche comuni (un sito può comunque essere in più insiemi di politiche). Questo sposta il framework (infrastruttura) al di la di accordi bilaterali, fornendo essibilità quando situazioni dierenti richiedono insiemi dierenti di politiche. Un vocabolario attributo-valore semplice ma estendibile: Shibboleth ha denito un insieme standard di attributi; il primo insieme si

37 Alcuni usi di Shibboleth 36 basa su un oggetto di classe eduperson che include gli attributi di una persona più usati nello scambio di informazioni. Possiamo quindi aermare che Shibboleth è uno strumento middleware nato per sviluppare e implementare nuove tecnologie in grado di facilitare le collaborazioni inter-istituzionali, nonché l'accesso ai contenuti digitali. Non è prevista una gerarchia tra i providers (IdP e SP) in quanto ogni organismo è responsabile direttamente dei propri utenti e delle proprie risorse; si ha quindi una struttura orizzontale che viene denominata federazione. Il SP che decide di aderire a una federazione accetta un legame con tutti gli IdP che ne fanno parte; simmetricamente un IdP che entra in una federazione accetta di emettere asserzioni su richiesta di un qualsiasi SP della stessa Alcuni usi di Shibboleth Shibboleth fornisce 2 importanti funzionalità: 1. risolve il problema dell'uso di svariate password e modalità di signon, con il conseguente miglioramento della sicurezza; 2. garantisce la protezione contro la divulgazione inutile (e non necessaria) di informazioni(attributi) personali, con l'importantissima conseguenza di preservare la privacy degli utenti. Rimanendo in termini scolastici si consideri un tipico studente laureato e le attività che esso può svolgere: Se un utente desidera accedere alle risorse digitali di una libreria l'approccio tramite proxy servers ha lo svantaggio di essere molto impegnativo da mantenere mentre adottando il sistema di password condivise la privacy può essere compromessa se l'identità è impropriamente passata alla libreria; tramite Shibboleth si risolve il problema in quanto questo permette di accedere direttamente al contenuto del campus senza bisogno del server proxy, richiede l'autenticazione da parte del campus anche se l'identità non è passata alla libreria e può essere utilizzato dalla stessa libreria per nuovi approcci ai contenuti coperti da licenza Se invece un utente desidera avere accesso a una ricerca su un sito web o

38 Shibboleth 2.0 vs Shibboleth presso un'altra università l'approccio tradizionale propone l'utilizzo di un account di gruppo o di un nuovo account remoto individuale e quindi comporta la condivisione della password che implica problemi di sicurezza e di controllo o l'immissione di nuovi account; Shibboleth consente l'uso di account campus locali, permettendo accessi basati su un ruolo e richiedendo una gestione attiva della privacy da parte degli utenti. Come ultimo esempio riportiamo il caso in cui una classe di utenti condivisa voglia accedere a un altro sito web universitario: il metodo tradizionale consiste ancora negli account di gruppo o nuovi account individuali con gli svantaggi elencati nell'esempio precedente, mentre con l'utilizzo di Shibboleth è permesso l'uso di account del campus con la conseguenza di avere la garanzia della privacy individuale Shibboleth 2.0 vs Shibboleth 1.3 Shibboleth 2.0 è basato principalmente su SAML 2.0 e comprende un gran numero di migliorie funzionali realizzate grazie alle esperienze precedenti maturate tramite l'utilizzo e lo sviluppo di Shibboleth 1.3. La maggior parte dei dettagli dei cambiamenti realizzati sono discussi qui di seguito. Prima di tutto occorre sottolineare che Shibboleth 2.0 è pienamente compatibile con Shibboleth 1.3, sia da 2.0 a 1.3 SP IdP e viceversa. Vediamo ora come è cambiato il prolo di default di Shibboleth; Shibboleth 1.3 e le versioni precedenti erano principalmente implementazioni dell'architettura Shibboleth basata su SAML 1.1. Questo prolo includeva alcune estensioni proprietarie, come ad esempio la richiesta di un prolo per l'autenticazione; inoltre le versioni precedenti utilizzavano una query diretta a una parte separata dell'idp, chiamata Attribute Autority, per recuperare gli attributi. Il prolo di default utilizzato da Shibboleth 2.0 invece è pienamente compatibile con l'implementazione del prolo SSO Web Browser di SAML 2.0: gli attributi sono ora inclusi di default in una asserzione SAML 2.0 criptata inviata dall'idp al SP. Questo non riduce in alcun modo la privacy o le caratteristiche di sicurezza garantite da Shibboleth e dovrebbe tradursi in una più facile implementazione.

39 Shibboleth 2.0 vs Shibboleth Per quanto riguarda i metadati sia Shibboleth 1.3 sia Shibboleth 2.0 possono contare sui metadati standard di SAML 2.0; lo stesso le di metadati può essere utilizzato da providers di entrambe le versioni SAML. Tuttavia, per trarre vantaggio dalle nuove funzionalità di crittograa di Shibboleth 2.0, i providers devono avere accesso alle chiavi pubbliche dei loro partner; questo è molto più semplice da attuare se la chiave del fornitore o il certicato è posto direttamente nei metadati. Analizzando l'utilizzo degli attributi, si nota che Shibboleth 1.x ha sviluppato l'uso di un URI per identicare gli attributi SAML, e Shibboleth 2.0 continua ad adottare questo sistema come default. Tuttavia, Shibboleth 1.3 e le precedenti versioni includevano esempi fondati su eduperson che si basano su un namespace specializzato delegato dal gruppo di lavoro MACE-Dir. Nella maggior parte dei casi questo è stato superato dalla specica SAML 2.0 del prolo attributi LDAP/X.500, utilizzando il namespace URN: OID. La con- gurazione predenita dei le forniti con il software è compatibile coi nomi basati su OID per garantire la massima interoperabilità. Tutti i namespace formalmente delegati rimangono validi, ma vanno seguite buone pratiche di denominazione quando vengono deniti nuovi attributi. Inoltre, è stato adottato un insieme signicativo di norme molto semplicate per la sintassi degli attributi nelle asserzioni SAML 2.0 per aumentare l'interoperabilità con altre implementazioni di SAML. In conclusione il software Shibboleth 2.0 include una serie di miglioramenti al ne di massimizzare la sua capacità di produrre più varianti di sintassi possibili, ed inoltre è molto più estensibile. L' Identity Provider Shibboleth è stato completamente riprogettato per la versione 2.0 mentre il Service Provider è strutturalmente simile alla prima generazione di software, ma incorpora molte modiche interne atte a ridurre i conitti di software, a migliorare la portabilità e la maneggiabilità e fornire maggiori opzioni per l'integrazione di applicazioni. La maggior parte dei le di congurazione del software è stata completamente rinnovata, senza però alterare il modello di distribuzione globale. Shibboleth 2.0 è in grado di interoperare con qualsiasi implementazione di SAML (2.0, 1.1, 1.0) compatibile, entro i limiti di ogni specica dei proli supportati. Siccome SAML tralascia molti dettagli - in particolare nel settore

40 Internet 2 39 della sicurezza - per gli implementatori, i prodotti con un buon supporto per i metadati SAML 2.0 sono più semplici da integrare. Quindi possiamo aermare che la compatibilità a ritroso si estende no al software di Shibboleth 1.3, mentre non è garantita una signicativa compatibilità con la versione Internet 2 Internet2 è un consorzio no prot che sviluppa tecnologie e applicazioni avanzate per la rete, spesso per trasferimenti ad alta velocità, promuovendo la collaborazione e l'innovazione, le quali hanno un impatto fondamentale sul futuro di internet. E' gestito da diverse università Statunitensi e industrie specializzate nel settore. Oltre alle caratteristiche sopraelencate, la comunità di Internet 2 si impegna attivamente nello sviluppo della tecnologia middleware, della sicurezza e nella misura delle prestazioni che sono fondamentali per il progresso di internet Perchè Shibboleth Come già detto Shibboleth è un software open-source basato su uno standard che consente di orire in tutta sicurezza un servizio di SSO (Single-Sign-On). Scott Cantor, responsabile dello sviluppo di sistemi presso l'università statale dell'ohio ha guidato lo sviluppo tecnologico di Shibboleth, con l'obiettivo di estendere il sistema di autenticazione utilizzato dalle università e da ricercatori al di fuori da questi due ambiti. Si è lavorato non solo per rendere più uido il funzionamento del sistema, ma anche per costruire un ponte tra Shibboleth e la serie di iniziative proposte parallelamente dalle aziende. Il sistema ha enormemente semplicato la gestione delle relazioni basate su Internet, garantendo i necessari livelli di sicurezza e adabilità per ciascuna transazione; Shibboleth non funge solo da sistema di autenticazione ma anche - paradossalmente - da guardiano della privacy. Poniamo che uno studente della Università di Parma desideri accedere alle apps di Google: l'università custodisce in completa sicurezza tutti i suoi dati

41 3.3.2 Shibboleth e l'università di Parma 40 identicativi, il nome, l'età, il campus di appartenenza e così via. Quando lo studente clicca sul link con le apps di Google è Shibboleth ad assumere il controllo, inoltrando a Google solo il dato identicativo che esso è tenuta a conoscere, ossia che l'utente è registrato come studente dell'università di Parma. Se alcune università hanno cominciato a utilizzare Shibboleth n dal 2003, l'adozione del sistema si è estesa con grande rapidità solo nel Oggi serve oltre 500 siti su scala mondiale, inclusi sistemi scolastici in Australia, Belgio, Inghilterra, Finlandia, Danimarca, Germania, Svizzera e Olanda; inoltre anche le istituzioni cinesi stanno dando la loro adesione. Il dato signicativo è che il sistema si sta spostando anche verso il settore privato. In conclusione nei prossimi anni i navigatori del Web potrebbero avere la possibilità di accedere a siti diversi con una sola procedura di login man mano che le aziende implementeranno sistemi di autenticazione interoperabili. 3.2 Shibboleth e l'università di Parma Essendo Shibboleth è un framework basato su SAML, in grado di permettere di instaurare relazioni basate sulla ducia all'interno della comunità dei partecipanti, l'università di Parma lo ha adottato per sviluppare il progetto IDEM - IDEntity Management -. Questo progetto utilizzato per l'accesso federato elimina la necessità per i ricercatori, i docenti e gli studenti di dover mantenere più credenziali per poter avere accesso a diversi servizi di rete. I fornitori dei servizi (Service Providers) di rete non hanno più bisogno di gestire onerose procedure di accreditamento e di amministrazione degli utenti. Le organizzazioni di appartenenza degli utenti diventano i gestori delle identità (Identity Providers) che possono essere scambiate, fornendo le adeguate garanzie e sempre nel rispetto della privacy degli utenti. IDEM è il progetto pilota del GARR per realizzare un'infrastruttura di Autenticazione e Autorizzazione federata. Con Identity Management si intende la completa gestione delle identità digitali di una persona sica, dal processo di creazione e organizzazione, - no all'eliminazione dell'identità digitale. Ogni singola persona, dipendente di una azienda o utente esterno di un servizio, è oggetto di un processo di

42 3.3.2 Shibboleth e l'università di Parma 41 assegnazione di molte identità digitali che possono riguardare l'account di posta o l'accesso alla intranet aziendale, in maniera coerente con il suo speci- co ruolo aziendale. Nell' Identity Management ciascuna di queste identità digitali va attivata (Provisioning) e disattivata (deprovisioning) in maniera coerente alle politiche aziendali e in modo automatico per evitare errori o ritardi. Ad esempio nel caso di licenziamento di un dipendente l'intero processo di disattivazione dei suoi account deve essere eseguito nel modo più rapido ed ecace possibile. Processi ripetitivi possono essere facilmente eliminati riducendo notevolmente i costi operativi di gestione delle identità digitali grazie all'automazione di processi e servizi self service, ad esempio il processo di rigenerazione di una password smarrita. Le soluzioni di Identity Management, spesso associate ad architetture basate su Single Sign On (SSO), rendono molto più sicura ed eciente una infrastruttura di servizio eliminando le problematiche di autenticazione e autorizzazione. Inne la possibilità di eettuare auditing e monitoraggio sulle attività di ogni identità digitale, consente di mettersi al riparo da impiegati fraudolenti o furti di identità, consentendo una maggior aderenza alle politiche di sicurezza aziendale e, quando necessario, un più facile percorso di certicazione. L'azienda può infatti conoscere in ogni momento chi sta utilizzando il servizio e come. Utilità dell'identity Management Nella catena della sicurezza informatica, l'anello debole consiste nella gestione degli accessi e delle identità digitali. Teoricamente un'azienda dovrebbe fornire un processo automatizzato per garantire a ogni suo utente l'accesso alle applicazioni di sua competenza, ma anche per eliminare immediatamente questo accesso non appena diventa inutile o dannoso, come ad esempio quando un dipendente lascia la società. Le identità digitali di tutti i dipendenti dovrebbero essere sincronizzate in tutti i sistemi e un'azienda dovrebbe avere le tecnologie necessarie a garantire l'identità di fornitori, partner e altre realtà 'terze' che comunque accedono ai sistemi interni. In pratica accade spesso che ex dipendenti possano accedere ancora alla rete

43 3.3.2 Shibboleth e l'università di Parma 42 aziendale, prima che l'it manager riceva l'ordine uciale di cancellarli dalla rete; inoltre gli impiegati devono ricordare talmente tante password che alla ne si sentono autorizzati a sceglierne di troppo vulnerabili. Molti sono i benefici che un sistema di ID Management può apportare a una azienda o a una istituzione; in primo luogo riduce i costi di gestione IT e dell'help desk, aumenta la sicurezza di tutta l'infrastruttura e anche la produttività degli utenti, che non perdono tempo a loggarsi in sistemi diversi con procedure dierenti; un altro vantaggio non meno importante è che un sistema di ID Management aiuta a soddisfare le normative legate alla sicurezza aziendale. Occorre comunque prestare attenzione e stabilire secondo criteri logici chi può creare, modicare e visualizzare i dati degli utenti; quale particolare evento dà il via libera alla creazione di un nuovo prolo di privilegi per un nuovo utente o per un utente che cambia ruolo all'interno dell'impresa; quale, all'opposto, richiede una cancellazione immediata dei privilegi. Per realizzare l'idem bisogna assicurarsi che l'infrastruttura che regge il sistema informatico e aziendale sia solida e adabile; per questo motivo è necessario un maggiore dialogo tra infrastrutture già alla fonte, ovvero tra sistemi operativi, che sono la base su cui poggia ogni applicazione informatica aziendale. L'IDEM può essere distinta in due stili implementativi del tutto dierenti: L'IDEM ISOLATO è il modello più diuso in cui ogni servizio ha un proprio bacino di utenza indipendente e ad ogni utente viene assegnata una credenziale distinta per ogni servizio a cui faccia accesso; è un approccio molto semplice in quanto semplica la gestione delle identita da parte dei SP, ma presenta molti problemi di usabilità per gli utenti all'aumentare dei servizi utilizzati. L'IDEM FEDERATO - si parla anche di identity federation - può essere denito invece come l'insieme di regole, tecnologie, standards e accordi che permettono a un insieme di SP di accettare come validi gli identicatori utente gestiti da un altro insieme di providers, chiamati Identity Providers (IdP). L'insieme di SP e IdP prende il nome di federazione. Come vedremo in seguito questo approccio implementa implicitamente il

44 3.3.3 Il progetto IDEM e l'università di Parma 43 SSO, ovvero la possibilità di un utente di autenticarsi presso uno qualsiasi dei provider della federazione e, successivamente, di accedere ai servizi di tutti gli altri. Punti cardine di questo approccio sono: all'origine di una richiesta ci deve essere sempre una richiesta esplicità da parte dell'utente; la corrispondenza tra gli identicatori collegati in una federazione deve essere corretta: infatti devono tutti far riferimento a una stessa identità digitale; la circolarità tra i providers delle informazioni sull'utente deve essere regolata da opportune policies accettate da tutte le parti in gioco al momento della federazione dell'identità. 3.3 Il progetto IDEM e l'università di Parma Come già detto in precedenza gli ultimi anni hanno visto il proliferare di numerosi servizi web ognuno con un dierente sistema di autenticazione. Partendo dalla tradizionale autenticazione con username/password no ad arrivare ai più recenti sistemi basati su smartcard e certicati personali, l'accesso alle informazioni è generalmente regolato da una serie di iscrizioni che richiedono ad ogni singolo utente di fornire di volta in volta dierenti credenziali. Considerando inoltre che tali identità digitali implicano spesso il passaggio nella rete di dati personali soggetti a regole di sicurezza e riservatezza diverse, si capisce n da subito come questa modalità renda dicile e insicuro l'accesso a servizi online forniti da soggetti diversi dalla propria organizzazione di appartenenza. In tale ambito il Consortium GARR, come già hanno fatto enti omologhi - come Switch in Svizzera - intende favorire e supportare l'attivazione di una Federazione dei sistemi di autenticazione degli Atenei e Enti di Ricerca (chiamata Federazione GARR-AAI) basata su rapporti di reciproca ducia, all'interno della quale sia accettata l'identità digitale dell'utente riconosciuta dall'organizzazione di appartenenza. Un processo analogo, dal punto di vista logico, a quanto accade per i cittadini dei paesi membri della comunità europea the accettano la carta di identità del paese di riferimento.

45 3.3.4 Identity Provider 44 La prima tappa della Federazione GARR-AAI è stata quella di far partire il progetto pilota denominato IDEM, basato su tecnologia Shibboleth, all'interno del quale vericare l'eettiva realizzabilità di una infrastruttura di tale tipo in Italia. Per fare ciò il GARR promuove e supporta il progetto fornendo l'infrastruttura centrale e i servizi mettendo a disposizione: supporto tecnico per l'implementazione di un IDentity Provider (IDP) e Service Provider (SP); realizzazioni di riferimento opensource; il servizio WAYF (Where Are You From); gestione della mappa della federazione. Il CILEA è stato uno tra i primi enti ad aver attivato un Identity Provider Shibboleth conforme alle direttive della GARR-AAI e sta lavorando al ne di rendere Shibboleth compatibili alcuni dei propri servizi per gli utenti come quello sviluppato dall'università di Parma che è stata in grado di implementare l'autenticazione via Shibboleth. 3.4 Identity Provider Un IdP (Identity Provider) è un sistema informatico che tratta individualmente le credenziali degli utenti nali e verica che queste risultino valide. Un IdP potrebbe essere un ente nanziario, una impresa commerciale, un organismo governativo, o, come nel caso di questo progetto, una istituzione scolastica. Ogni IdP è in grado di autenticare l'utente e fornire informazioni aggiuntive o attributi sul suo conto; può operare uno o più servizi di credenziali, ciascuno dei quali tratta le credenziali dell'utente basandosi su degli standard per la verica dell'identità. Un utente può possedere credenziali da più Identity Provider, alcuni dei quali possono essere gestiti dalla stessa organizzazione o dalla stessa società. E-Authentication ha stabilito una Federazione di IdP che comprende istituti nanziari, imprese commerciali e agenzie governative.

46 3.3.5 Service Provider 45 Figura 3.1: Esempio di Sessione IdP L'Identity Provider esegue i seguenti controlli: 1. Se esiste già una sessione per l'utente ; 2. Se il timeout della sessione (inattività) non è superato (default: 30 min); 3. Se il timeout del metodo di autenticazione (ad esempio, PKI, UsernamePassword) non è superato (UsernamePassword default: 30 min); 4. Se l'attributo ForceAuthn non è settato; Se uno di questi punti non è vericato, l'idp applica una autenticazione per l'utente. Entrambi i timeout (sessione e metodo di autenticazione) sono basati su inattività; essi vengono aggiornati nel corso di ogni richiesta di autenticazione. Se la sessione scade, tutti i timeout del metodo di autenticazione sono cancellati. In conclusione si può aermare che un Identity Provider che entra in una federazione garantisce ai propri soggetti una migliore oerta di servizi in termini di quantità, qualità e diversicazione.

47 3.3.5 Service Provider 46 Figura 3.2: Esempio di sessione SP 3.5 Service Provider Il Service Provider è l'ente presso il quale è gestita la risorsa web a cui l'utente fa richiesta e che ha il compito di proteggerla attraverso qualche forma di policy di acceso; il Service Provider controlla: Se esiste già una sessione per l'utente ; Se il timeout della sessione (inattività) non è superato (default: 1 ora); Se il tempo di vita della sessione (manutenzione nella cache) non è superato (default: 8 ore); Se il tempo massimo dopo l'ultima autenticazione non è superato (di default non è impostato). Se uno di questi punti non corrisponde, è avviata la procedura di autenticazione. I dati associati a una sessione SP sono gli attributi, le informazioni di autenticazione (tempo, metodo, classe,...); in altre parole, tutte le informazioni che sono state fornite dall' IdP entro l'asserzione(i). Ciò signica che tutte le

48 3.3.6 Procedura di login tramite Shibboleth 47 autorizzazioni di accesso e i controlli vengono eettuati dalla sessione delimitata dai dati. Nota: Se il Discovery Service imposta un cookie contenente l'identità della selezione dell'idp dell'utente, alcuni passi vengono omessi e l'utente del browser viene reindirizzato direttamente all'identity Provider dell'utente. In conclusione possiamo aermare che un Service Provider è motivato ad aderire a una federazione in quanto può accedere ad un bacino di utenza più ampio costituito da tutti gli IdP della federazione. 3.6 Procedura di login tramite Shibboleth La procedura di login tramite Shibboleth è all'incirca come qualsiasi altro processo di login. Per accedere a una risorsa protetta, l'utente deve autenticarsi; tuttavia, nel caso di Shibboleth l'utente non autentica se stesso a una risorsa, ma autentica se stesso alla sua Organizzazione. L'utente non ha bisogno di fornire il suo nome utente e la password a terzi, ma solo alla sua Organizzazione. Una volta che l'utente è autenticato a Shibboleth, può accedere a qualsiasi altra risorsa abilitata senza fornire login e password; si noti che il procedimento è reso però necessario se l'utente chiude il proprio browser web o se non si è acceduto alla risorsa Shibboleth per un determinato periodo di tempo. Primo passo - Accesso al Service Provider (Utente browser <> Service Provider): L'utente apre un browser Web e accede al Service Provider; il suo browser invia una richiesta (GET). Poiché la pagina è protetta dal Service Provider Shibboleth viene controllato se l'utente ha già una sessione Shibboleth aperta e quindi se è già stato autenticato. Se l'utente non è autenticato, il server web risponde con un reindirizzamento HTTP all'organizzazione dell'utente. Secondo passo - Inizio sessione per la richiesta di autenticazione A seguito della risposta, l'inizializzatore della sessione crea una richiesta di

49 3.3.6 Procedura di login tramite Shibboleth 48 Figura 3.3: Schema procedura di login tramite Shibboleth autenticazione e la restituisce all'interno di un auto-submit-post-form. A questo punto l'identity Provider controlla la richiesta di autenticazione, e poiché l'utente non è autenticato, invia un reindirizzamento all'appropriato gestore di login (nome utente/password). Il browser viene reindirizzato al gestore e l'identity Provider reindirizza quindi a una specica pagina web il nome utente/password; in seguito il browser invia una richiesta GET per la pagina web e il server web risponde con la pagina richiesta. Terzo passo - Autenticazione, controllo attributi e accesso A questo punto l'utente può digitare il suo nome utente e password e presentarli all'idp; l'autenticatore dell'idp verica le credenziali. Dopo che l'utente è stato autenticato con successo, vengono eguiti l'attribute resolving e l'attribute ltering. Viene quindi generata una pagina HTML che include una asserzione SAML; siccome questa asserzione contiene non solo una dichiarazione di autenticazione, ma anche una dichiarazione-attributo con gli attributi dell'utente, questo modo di inviare gli attributi viene chiamato Attribute Push. L'asserzione viene trasmessa utilizzando una auto-submitpost-form. Il browser POSTA immediatamente la richiesta e inne invia un