UNIVERSITÀ DEGLI STUDI DI PARMA

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 Centralizzata con il sistema CAS, integrando un infrastruttura a chiave pubblica in Ambito Universitario Candidato: Matteo Sironi Relatore: Chiar.mo Prof Roberto Alfieri Correlatore: Dott.Ing Marco Panella Anno Accademico 2008/2009

2

3 Ai miei genitori Ai miei nonni Alla mia Maider

4

5 Indice 1 Introduzione Contributo della tesi Aspetti sviluppati Autenticazione distribuita Introduzione alla crittografia Chiavi e algoritmi Due principi fondamentali della crittografia Algoritmi a chiave simmetrica Algoritmi a chiave pubblica Protocolli di autenticazione Autenticazione basata su segreto condiviso Autenticazione con KDC Autenticazione con Kerberos Autenticazione con crittografia a chiave pubblica Metodi di autenticazione Vantaggi e svantaggi dei metodi di autenticazione Autenticazione centralizzata SSO...32

6 Indice 6 3 L Identità digitale Tipi di firme elettroniche Firma digitale Creazione della firma digitale Il valore legale della firma digitale in Italia Gestione delle chiavi pubbliche Certificati digitali Certificati X Smart card e Token USB Carta Nazionale dei Servizi Infrastruttura a chiave pubblica Strutturazione delle PKI I servizi di directory Liste dei certificati revocati Il servizio di autenticazione centralizzata: CAS Strutturazione del sistema CAS Caratteristiche di CAS Schemi di funzionamento del sistema CAS Funzionamento di CAS in modalità diretta Funzionamento di CAS in modalità proxy La versione 3 del server CAS Limitazioni di CAS nelle versioni 1 e CAS Valutazioni sull uso di CAS Integrazione del sistema CAS nell Università di Parma Strutturazione del servizio CAS nell Università di Parma Il server LDAP: Lightweight Directory Access Protocol Integrazione di LDAP nel sistema CAS...82

7 1 Indice 7 6 Problematiche affrontate: miglioramento del servizio di Autenticazione Scelte progettuali Installazione componenti Primo problema affrontato: gestione della scadenza password Modifiche al protocollo di autenticazione locale Tecniche risolutive adottate Modifiche ai file sorgenti Java di CAS Modifiche ai file di configurazione di CAS Compilazione e installazione del pacchetto CAS Secondo problema affrontato: gestione dei certificati X Configurazione di Apache Tomcat per il supporto dei certificati X Configurazione di CAS per il supporto dei certificati X Compilazione e installazione del pacchetto CAS con certificati X Problemi con le Certification Revocation List Conclusioni Risultati ottenuti Utilizzo dei nuovi servizi Sviluppi futuri Bibliografia 119 Ringraziamenti 123

8 Indice delle figure 8 Indice delle figure 2.1 Modello generale di comunicazione cifrata tra A e B, con possibilità di intrusione Modello di crittografia simmetrica Modello di crittografia asimmetrica Autenticazione a due vie con protocollo challenge-response Autenticazione con centro di distribuzione chiavi KDC Protocollo di autenticazione Kerberos Mutua autenticazione con crittografia a chiave pubblica Differenze tra autenticazione normale e centralizzata Creazione di un documento firmato e cifrato Principali differenza tra firma autografa e firma digitale Struttura dello standard X509 per i certificati digitali Esempi di Smart Card, lettori e token USB Esempio di Carta Nazionale dei Servizi fornita dalla Cnipa Esempio di autenticazione distribuita prima e dopo l introduzione di CAS Esempi di plug-in di autenticazione per CAS Schema di autenticazione CAS in modalità diretta Schema di autenticazione CAS in modalità proxy Catena di autenticazione tramite proxy Finestra di autenticazione CAS dell Università di Parma Pagina di conferma di avvenuta autenticazione riportante l avviso di scadenza password Certificato Digitale dell Università di Parma in formato PEM Esempio di autenticazione CAS tramite invio di un certificato digitale

9 Capitolo 1 Introduzione L obbiettivo di questa tesi è quello di approfondire le problematiche relative all autenticazione in rete di un utente, in un ambito universitario. L autenticazione è un processo necessario quando due entità coinvolte in uno scambio di messaggi o informazioni sulla rete, vogliono essere sicuri dell identità della controparte. Infatti sempre più persone utilizzano la rete di Internet, ed è sempre più numerosa la quantità di enti e soggetti che utilizzano Internet oltre che per scambiare importanti informazioni, anche per effettuare dei pagamenti o transazioni bancarie. Per questi motivi le varie entità in gioco devono poter essere sicure delle reciproche identità, e diventa quindi necessario introdurre il concetto di Identità Digitale: l Identità Digitale di un soggetto è quell insieme di informazioni che identificano univocamente un soggetto in rete, nello stesso modo in cui le caratteristiche somatiche di un individuo lo identificano nella vita reale.

10 1 Introduzione 10 Al momento sono sempre più frequenti le frodi sulla rete di Internet, nelle quali soggetti malintenzionati cercano di rubare le credenziali di un utente, il che rende il problema della sicurezza in fase di autenticazione un argomento da non sottovalutare. Il problema della sicurezza comunque non si ferma alla sola fase di autenticazione. Altri problemi sono la segretezza, il principio del non ripudio e l integrità dei dati. La segretezza riguarda la necessità che due soggetti possano scambiarsi messaggi o informazioni riservati, senza che nessuno possa intercettarli, leggerli o modificarli. È quindi sempre più comune nascondere il contenuto originale dei documenti in transito sulla rete, cifrandoli con tecnologie crittografiche sempre più avanzate, che permettono uno scambio di messaggi sempre più sicuro. Il principio del non ripudio è fortemente legato al concetto di firma. Infatti si vuole che un documento in formato elettronico possa non essere ripudiato come avviene per un documento cartaceo, ovvero con l apposizione di una firma che garantisce la validità del documento. Inoltre sempre per quanto riguarda i documenti elettronici scambiati, disporre di una metodologia che permetta il riconoscimento immediato del proprietario, è fondamentale. Il problema dell integrità dei dati è concettualmente collegato alla problematica precedente, infatti si cerca di avere uno strumento che permetta di verificare in maniera definitiva, se un documento elettronico è originale oppure ha subito modifiche. Per queste motivazioni nasce quindi l idea di introdurre nei documenti elettronici una Firma Digitale, che permetta una sicura e veloce identificazione del firmatario e garantisca l integrità dell intero documento. Anche la sicurezza in fase di autenticazione può trarre un sostanziale beneficio dall introduzione del concetto di Firma Digitale: avere uno speciale documento elettronico debitamente firmato che attesti l identità di un soggetto, non può che migliorare e garantire un alto grado di sicurezza del sistema. Questo è il concetto che sta alla base dei Certificati Digitali e di tutta l infrastruttura necessaria per un loro utilizzo sicuro e garantito. Contengono informazioni personali sul proprietario, e gli consentono un autenticazione più

11 1.1 Contributo della tesi 11 Sicura. I certificati digitali vengono rilasciati da una specifica Autorità che li firma e ne certifica dunque la validità. Disporre di un sistema che offra un servizio sicuro e qualificato, che certifichi l Identità Digitale di un utente sulla rete, aumenta notevolmente la sicurezza sia del sistema stesso, sia di tutta la rete di Internet. Con l introduzione di una tecnologia del genere tuttavia si è introdotto un nuovo problema, ovvero quale deve essere l Autorità che garantisca il rilascio dei certificati digitali validi con relativa firma. A questa problematica purtroppo non esiste una soluzione globale per tutta la rete internet. La soluzione sta nell avere svariate Autorità di certificazione considerate fidate, a cui le varie organizzazioni si appoggiano. 1.1 Contributo della tesi Questo progetto di tesi si è concentrato sullo studio dei vari protocolli di autenticazione, valutandone i principali vantaggi e svantaggi, cercando di applicare gli aspetti studiati per migliorare il servizio di autenticazione web tramite il sistema CAS dell Ateneo di Parma. Le motivazioni più importanti che hanno spinto questo lavoro sono state: Studiare approfonditamente le diverse metodologie di autenticazione, con particolare attenzione ai vantaggi in termini di sicurezza che si possono ottenere introducendo le nuove tecnologie disponibili. Migliorare la qualità e la sicurezza del sistema di autenticazione dell Università di Parma. Offrire nuove funzionalità ai propri utenti, permettendo nuove modalità di accesso ai servizi web offerti, garantendo sicurezza, efficienza, comodità e trasparenza.

12 1.2 Aspetti sviluppati Aspetti sviluppati Per sviluppare gli obbiettivi preposti è stato eseguito uno studio approfondito delle varie tematiche annesse al progetto, per poter affrontare in maniera più consapevole l integrazione di queste in un contesto concreto, in questo caso una struttura universitaria. Nel secondo capitolo verranno discusse approfonditamente le varie tecniche di autenticazione disponibili e i diversi protocolli, con particolare attenzione per quanto riguarda il tema della sicurezza, offrendo anche una panoramica della crittografa ad essi associata. Verranno introdotte le nuove tecnologie di autenticazione, con una precisa valutazione dei benefici che possono portare. Successivamente verrà spiegato dettagliatamente cosa significa autenticazione centralizzata Single Sign On, ovvero un servizio che permetta di centralizzare in un unico punto tutte le autenticazioni. Il terzo capitolo darà ampio spazio all argomento dell Identità digitale e delle relative implementazioni. Verrà largamente trattato il tema della Firma Digitale, cosa è e quali tecniche sono utilizzate, specificando inoltre il contesto legale che essa rappresenta. Grazie all introduzione della Firma Digitale si dirà come è possibile legare l identità digitale di un soggetto ad un certificato in formato elettronico, ed introdurre un infrastruttura che gestisca questo concetto. Il quarto capitolo studierà approfonditamente il protocollo CAS in tutte le sue modalità, riportando i miglioramenti che si possono ottenere con la sua introduzione in un servizio di autenticazione. Il quinto capitolo mostrerà come il sistema CAS è attualmente integrato nell Università di Parma, mentre il sesto capitolo discuterà il progetto affrontato per migliorare il servizio corrente In particolare verrà specificato come e perché introdurre nel protocollo CAS un sistema per la gestione della scadenza password degli utenti locali di Ateneo. In secondo luogo verranno chiarite le modalità per l introduzione di un infrastruttura a chiave pubblica per la gestione dei certificati digitali, motivando in maniera precisa le scelte effettuate, ed illustrando l utilità di un servizio di questo tipo e anche gli svantaggi ad esso associati.

13 Capitolo 2 Autenticazione distribuita L autenticazione nell ambito della sicurezza informatica è uno dei concetti principali per la gestione dell identità, durante una comunicazione tra due processi remoti: si vuole essere sicuri che l interlocutore col quale stiamo dialogando, sia veramente chi dice di essere, e viceversa. Talvolta si confonde il termine autenticazione con il termine autorizzazione. Sebbene questi concetti siano legati tra loro ed entrambi importanti per la sicurezza, il loro significato è profondamente differente. Infatti come già detto l autenticazione si preoccupa del problema di assicurare l identità del processo col quale stiamo dialogando, invece l autorizzazione si occupa di gestire che cosa ad un processo è permesso di fare. Il problema dell autenticazione è più complicato di quanto si possa pensare, e talvolta richiede l ausilio di protocolli crittografici complessi. Invece l autorizzazione, che di norma viene eseguita dopo l autenticazione, normalmente consiste nella ricerca in tabelle o database o servizi di directory dei vari permessi concessi all utente. Per questo motivo l interesse di questa tesi si sviluppa principalmente sul problema dell autenticazione. L autenticazione può avvenire attraverso varie tecniche, come la digitazione di una password segreta, l invio di informazioni personali garantite come certificati

14 2.1 Introduzione alla crittografia 14 digitali o smart card, token USB o altri metodi. Dato che l invio di dati personali sulla rete può essere un processo pericoloso in quanto intercettabile, sulla rete l'autenticazione deve essere effettuata solamente utilizzando scambi di messaggi e dati, che fanno parte di un protocollo di autenticazione. Di questi ne esistono diversi, ognuno con le proprie caratteristiche, vantaggi e svantaggi. L'autenticazione deve avvenire on-line, cioè istantaneamente e deve essere distinta dall'autenticazione di colloqui passati. Il prossimo paragrafo da un introduzione alla crittografia, che è essenziale per ogni protocollo di autenticazione e capire al meglio i vari argomenti trattati. 2.1 Introduzione alla crittografia Questo paragrafo ha lo scopo di accennare alcuni elementi di crittografia senza entrare nel dettaglio, data l enorme vastità degli argomenti. Tuttavia alcuni aspetti sono fondamentali per capire meglio alcune delle tecniche utilizzate, come il concetto di chiave e di algoritmo simmetrico o a chiave pubblica. Il termine crittografia deriva dal greco antico, da due parole che possiamo tradurre come scrittura segreta. Ha radici storiche molto antiche, in quanto già in passato era necessario comunicare segretamente senza che altri intercettassero il contenuto della comunicazione. Le varie tecniche che consentono di mantenere segreto il contenuto di un messaggio, vengono chiamate tecniche di cifratura e decifratura. I messaggi da cifrare, detti testi in chiaro, vengono trasformati da una funzione parametrizzata da una chiave. L output di questo processo di cifratura viene chiamato testo cifrato. Decifrare è l operazione legittima di lettura del messaggio cifrato, mentre decriptare è l attività di decifrazione da parte di un intruso malintenzionato. Un possibile intruso che cerca di scoprire il contenuto del messaggio durante la sua spedizione, non può fare altro che essere a conoscenza della chiave di cifratura per poterlo leggere, altrimenti vedrà solo lettere o simboli incomprensibili.

15 2.1.1 Chiavi e algoritmi 15 Gli intrusi appartengono principalmente a due categorie: Intrusi passivi : cercano solo di capire il contenuto del messaggio Intrusi attivi : cercano di modificare il contenuto del messaggio Figura 2.1 Modello generale di comunicazione cifrata tra A e B, con possibilità di intrusione Chiavi e Algoritmi La segretezza della chiave è quindi un elemento fondamentale affinché la comunicazione resti sicura. La funzione o l algoritmo di cifratura invece non deve essere segreto. Questo può sembrare un controsenso, ma dopo anni di esperienza si è concluso che, credere di avere un algoritmo segreto, quando in realtà l intruso detto anche criptoanalista lo ha scoperto, produce più danno che guadagno. In più rendendo pubblico un algoritmo di crittografia, si ottiene gratuitamente il test di numerose menti brillanti, che desiderano forzare il sistema per mostrare la propria intelligenza, avendo conferma o meno della sua robustezza. Il principio è quindi di avere un algoritmo di cifratura pubblico ma complesso, per impedire all intruso di capire quale sia la chiave crittografica, pur avendo a disposizione una grande quantità di testo cifrato.

16 2.1.2 Due principi fondamentali della crittografia 16 Esistono vari metodi per un criptoanalista per cercare di decriptare un messaggio, innanzitutto deve capire quale algoritmo è stato usato per la cifratura, poi deve scoprire la chiave. Per farlo può iniziare ragionare su di essa, oppure tentare un cosiddetto attacco a forza bruta, che significa provare tutte le possibili chiavi e combinazioni. Qui entrano quindi in gioco le diverse tipologie di chiave. Dato che la vera segretezza sta in essa, la sua lunghezza è alla base della progettazione del sistema crittografico. Al giorno d oggi gli algoritmi utilizzano come chiave una stringa che può variare dai 128 bit, ai 1024 bit, dipendendo anche dalla tecnica utilizzata. Una chiave da 128 bit, genera un possibile spazio di chiavi di x chiavi Due Principi fondamentali della crittografia Sono due i principi della crittografia alla base dello studio dei diversi sistemi crittografici: Ridondanza Il primo principio dice che tutti i messaggi cifrati devono al loro interno contenere una parte ridondante, cioè una parte d informazione non necessaria alla comprensione del messaggio stesso. Il destinatario deve quindi essere in grado di stabilirne la validità, con un semplice esame del contenuto o con un breve calcolo. Questo tecnica è necessaria per prevenire attacchi da parte di intrusi attivi, al contrario facilita la decrittazione degli intrusi passivi. Questo è però il concetto che sta alla base dell idea della firma digitale, che verrà spiegata dettagliatamente nei prossimi capitoli. Attualità Il secondo principio afferma che è necessario avere la possibilità di controllare che ogni messaggio sia stato trasmesso di recente. Questo per evitare che intrusi attivi inviino messaggi vecchi, proponendoli per nuovi, e per evitare attacchi a ripetizione di forzatura del codice.

17 2.1.3 Algoritmi a chiave simmetrica Algoritmi a chiave simmetrica Il principio alla base di questo tipo di algoritmi, sta nel fatto che viene usata la stessa chiave sia per cifrare che per decifrare il messaggio. La maggior parte di questi utilizzano la tecnica della cifratura a blocco. Si prendono in input n bit alla volta dal testo in chiaro, e producono n bit di testo cifrato utilizzando la chiave. Tipicamente i blocchi vanno da un minimo di 64 bit ad un massimo di 256 bit. La trasformazione in testo cifrato avviene tramite varie iterazioni di trasposizione e sostituzione dei bit. Tra i più famosi, possiamo citare DES 1 (in disuso), triple DES (obsoleto, ma ancora in uso), AES 2, IDEA 3. Uno dei vantaggi nella scelta di usare un algoritmo di tipo simmetrico è per la sua velocità. Infatti sia la cifratura che la decifratura risultano molto efficienti e rapidi. Lo svantaggio maggiore però, è che la chiave da utilizzare deve essere stata stabilita prima dell inizio della comunicazione, e questo può pregiudicare fortemente la sicurezza. Figura 2.2 Modello di crittografia simmetrica

18 2.1.4 Algoritmi a chiave pubblica Algoritmi a chiave pubblica Gli algoritmi a chiave pubblica o asimmetrica si distinguono rispetto ai precedenti, per il fatto che la chiave con la quale si cifra un messaggio è diversa dalla chiave con cui viene decifrato il messaggio. Inoltre la chiave di cifratura non è in alcun modo derivabile da quella di decifratura. Ad ogni soggetto coinvolto che intenda comunicare, è quindi associata una coppia di chiavi: Una chiave privata, tenuta segreta ed utilizzata per decifrare i messaggi in arrivo dalla rete. Una chiave pubblica, resa disponibile a tutti, usata da qualsiasi soggetto del mondo esterno per cifrare un messaggio diretto al proprietario della relativa chiave privata. Lo scenario di comunicazione opera in questo modo 4 : 1. Bob intende comunicare con Alice. Si procura quindi la sua chiave pubblica, che è disponibile a tutti. 2. Cifra il messaggio con la chiave appena ottenuta, e lo invia ad Alice. 3. Alice riceve il messaggio, ed è l unica che lo può decifrare, perché è la sola in possesso della chiave segreta relativa alla sua chiave pubblica. Se ora Alice volesse rispondere a Bob in maniera sicura, dovrebbe quindi procurarsi la chiave pubblica di Bob, cifrare con questa il messaggio ed inviarlo. Bob dal canto suo sarebbe l unico in grado di decifrarlo. Il concetto generale alla base della crittografia asimmetrica, si fonda su principi matematici solidi. Precisamente sull uso di un problema complesso, ovvero un operazione matematica facile da eseguire, ma difficile poter risalire agli elementi di partenza solo attraverso il risultato. Uno dei metodi più utilizzati è la scomposizione in fattori primi di numeri molto grandi, dalle trecento cifre in su. E molto facile e veloce moltiplicare due numeri primi, ben più difficile, laborioso e soprattutto lungo riottenere quei numeri dal risultato della loro moltiplicazione. 4 Vengono Mantenuti i nomi storici Alice e Bob per indicare i soggetti coinvolti nella comunicazione segreta come nella maggior parte dei libri di crittografia.

19 2.1.4 Algoritmi a chiave pubblica 19 Tra gli algoritmi più famosi possono citare RSA 5, DSS 6 e lo scambio di chiavi Diffie-Hellman 7. Uno dei vantaggi più interessanti della tecnica degli algoritmi a chiave pubblica è la sicurezza. Infatti i soggetti coinvolti possono comunicare in tutta riservatezza, senza problema di essere intercettati. Tuttavia un lato molto negativo può subentrare quando uno dei soggetti dichiara di essere chi in realtà non è. Questo è un problema molto grave e sono state inventate svariate soluzioni per risolvere ciò, come la firma e i certificati digitali e le PKI. Questi sfruttano un ulteriore proprietà degli algoritmi asimmetrici, ovvero che l ordine in cui vengono usate le due chiavi può essere scambiato: si può cifrare un messaggio con la chiave privata e decifrarlo con la chiave pubblica. Un altro dei principali svantaggi nell uso di crittografia a chiave pubblica è la sua lentezza. Infatti per avere una buona sicurezza, è necessario utilizzare chiavi molto grandi. Per esempio l algoritmo RSA che utilizza il metodo dei fattori primi, per essere considerato sicuro deve utilizzare chiavi da almeno 1024 bit, il che lo rende abbastanza lento. Figura 2.3 Modello di crittografia asimmetrica 5 Nome dovuto alle iniziali dei nomi dei suoi tre creatori Rivest, Shamir e Adleman

20 2.2 Protocolli di autenticazione Protocolli di autenticazione Il problema di stabilire le identità di due processi remoti durante una comunicazione è non banale. Perciò esistono vari protocolli di autenticazione, per garantire ad entrambi gli attori coinvolti che, quando il protocollo è stato completato, l identità delle due parti è considerata sicura. Il modello generale utilizzato in tutti i protocolli è il seguente: Alice inizia la comunicazione inviando un messaggio a Bob, o ad una terza persona fidata, chiamata KDC 8. Si susseguono vari scambi di messaggi nelle due direzioni, i quali possono anche essere intercettati o modificati dall intruso Trudy 9. Al termine del protocollo, Alice è sicura di dialogare con Bob e viceversa. Un buon metodo molto utilizzato per avere una comunicazione veloce e sicura, consiste nell uso combinato delle due tecniche di crittografia simmetrica e asimmetrica. Inizialmente i due soggetti coinvolti si scambiano messaggi tramite crittografia a chiave pubblica. All interno di questi messaggi sicuri, viene stabilita una nuova chiave di sessione segreta, da utilizzare successivamente per tutto il resto della comunicazione, tramite crittografia simmetrica. Sono molteplici le ragioni per cui si utilizza una nuova chiave casuale diversa per ogni connessione: minimizzare la quantità di traffico inviato usando le chiavi permanenti degli utenti, riducendo quindi la quantità di testo cifrato simile che può essere intercettato da un intruso, e rendere minimi i rischi in una sfortunata situazione dove un processo va in crash, e il relativo core dump entra in possesso di malintenzionati. Sono quattro le regole generali da seguire per la progettazione di un protocollo corretto: Chi inizia l autenticazione deve provare la sua identità, prima che lo faccia chi risponde. 8 Key Distribution Center, centro di distribuzione delle chiavi 9 Nome storico per i crittografi per indicare l intruso.

21 2.2.1 Autenticazione basata su segreto condiviso 21 Per provare la mutua identità, inizialmente devono essere usate chiavi differenti. Per le richieste di entrambi, devono essere utilizzati insiemi differenti. Rendere il protocollo resistente ad attacchi, nel caso in cui vi sia una sessione parallela, e le informazioni ottenute da una sessione possano essere utilizzate per forzare l altra. Se anche solo una di queste regole viene meno, è più probabile che il protocollo subisca una forzatura indesiderata Autenticazione basata su segreto condiviso Questi protocolli presuppongono che tra Alice e Bob vi sia già una chiave di sessione segreta nota ad entrambi, KAB, scambiata anche tramite metodi fisici (telefono o di persona), ma mai in viaggio sulla rete. Si utilizza un principio base comune a molti protocolli di autenticazione: Il soggetto A invia un numero casuale al soggetto B, che trasforma il numero arrivatogli con un particolare algoritmo e ritrasmette il risultato. I numeri casuali utilizzati ad ogni nuova connessione sono detti nonce 10 e una tecnica di questo tipo è chiamata challenge-response: Nel messaggio 1 iniziale, Alice invia la propria identità A in chiaro a Bob. Bob dal canto suo non può sapere se si tratta di Alice o Trudy, quindi crea una richiesta per Alice contenente un numero casuale molto grande, RB, e lo invia in chiaro nel messaggio 2. Alice riceve il numero, lo cifra con la chiave condivisa KAB, e reinvia a Bob il numero cifrato, nel messaggio 3. Bob a questo punto è sicuro che sta comunicando con Alice, perché è improbabile che Trudy abbia scoperto KAB, e quindi generato il messaggio 3. Alice però non è ancora sicura di interagire con Bob, quindi invia nel messaggio 4 un altro numero casuale RA. Bob risponde con il messaggio 5, contenente il numero casuale arrivatogli da Alice RA, cifrandolo di nuovo con la chiave condivisa KAB. 10 Contrazione del inglese number used once, Numeri usati una sola volta.

22 2.2.2 Autenticazione con KDC 22 A questo punto entrambi i soggetti sono sicuri della rispettiva identità, e possono eventualmente scambiarsi una nuova chiave di sessione, cifrata con la chiave KAB. Figura 2.4 Autenticazione a due vie con protocollo challenge-response Questo protocollo è abbastanza sicuro, tuttavia non è esente da possibili attacchi. L unica violabilità si ha quando Alice è un server in grado di accettare più sessioni alla volta e non ben configurato. L attacco viene chiamato per riflessione, perché aprendo una seconda sessione, è possibile ingannare il server e facendolo rispondere alla sua stessa domanda, senza conoscere la chiave Autenticazione con KDC La tecnica basata su segreto condiviso impone che ad ogni coppia di soggetti che intendano comunicare, sia corrisposta una relativa chiave condivisa. Questa tecnica può essere buona se le persone coinvolte sono relativamente poche, però con l aumentare di soggetti, aumenta notevolmente il numero delle chiavi. Questo può portare a notevoli rischi, oltre ad una elevata scomodità. Un metodo per risolvere questo problema, può essere usando di un centro di distribuzione chiavi (KDC). In questo modello ogni utente possiede una singola chiave condivisa con il KDC, e la coordinazione dell autenticazione e dell instaurazione della chiave di sessione sono gestite dal KDC.

23 2.2.2 Autenticazione con KDC 23 Il protocollo opera in questo modo: Alice sceglie una chiave di sessione KS, ed invia un messaggio al KDC, cifrato con la chiave che condivide con esso, contenente la chiave di sessione scelta ed il soggetto con cui vuole dialogare, cioè Bob. Il KDC vede questa richiesta, decifra il messaggio proveniente da Alice ed estrae l identità del destinatario, e la chiave di sessione scelta. Invia quindi un messaggio a Bob cifrato con la sua chiave condivisa col KDC, contenente l identità di Alice e la chiave di sessione da utilizzare. Bob si vede recapitare il messaggio, lo decifra, e subito sa che Alice intende dialogare con lui usando la chiave di sessione KS. La fiducia nel KDC garantisce che l identità dei soggetti sia quella dichiarata. Tuttavia questo protocollo è soggetto ad attacchi del tipo a ripetizione. L intruso potrebbe intercettare il messaggio 2, ed inviarlo ripetutamente a Bob. Bob che si fida del KDC, vede i continui tentativi di connessione di Alice, li accetta, e continua ad eseguire quello che gli viene richiesto. Esistono molte soluzioni per evitare attacchi a ripetizione, come per esempio inserire in ciascun messaggio un contrassegno temporale chiamato timestamp, così da scartare subito i messaggi scaduti. Il problema è che su di una rete distribuita gli orologi non sono mai perfettamente sincronizzati, e anche permettendo un intervallo temporale maggiore, l intruso avrebbe difficoltà ma ancora campo libero. Oppure come in precedenza si potrebbe inserire in ciascun messaggio un numero casuale, un nonce. In questa seconda soluzione però, il soggetto dovrebbe memorizzare tutti i nonce in arrivo, e scartare i messaggi con quelli già usati. Combinazioni di queste due tecniche, come il protocollo di Needham-Schroeder 11 su cui si basa l autenticazione con Kerberos, possono portare ad una soluzione. Figura 2.5 Autenticazione con centro di distribuzione chiavi KDC 11

24 2.2.3 Autenticazione con Kerberos Autenticazione con Kerberos Il protocollo Kerberos è pensato per fornire sicurezza di autenticazione su reti aperte e insicure, dove la comunicazione tra gli attori che ne fanno parte può essere intercettata o soggetta ad attacchi a ripetizione. Il suo nome deriva dal famoso personaggio mitologico Cerbero. Questi era un cane a tre teste posto a guardia dell inferno, per evitare l ingresso a persone non desiderate. Fu progettato dal MIT 12, per fornire un accesso sicuro alle risorse di rete agli utenti, che si potevano connettere da differenti workstation, ed assume che queste siano sicure al loro interno. Si basa sul protocollo di Needham-Schroeder, supponendo che gli orologi dei vari componenti siano sincronizzati. Gli obiettivi che originariamente si intendevano raggiungere con il sistema Kerberos erano autenticazione, autorizzazione e accounting 13, fornendo all utente trasparenza, fiducia, sicurezza e scalabilità. Alla fine però solo il primo obiettivo, ovvero l autenticazione è stato portato a termine. Precedentemente gli utenti, per connettersi scambiavano un informazione segreta col server, generalmente una password. Il problema era che questa informazione veniva trasmessa in rete, quindi poteva essere intercettata. Il protocollo permette uno scambio di messaggi cifrati tra le workstation e i server, senza che circolino informazioni segrete sulla rete. Kerberos utilizza tre differenti server, dove i primi due integrano un KDC: Authentication Server (AS): verifica gli utenti durante il login. Ticket Granting Server (TGS): emette un ticket 14 utilizzato per provare l identità di chi lo possiede. Service server (SS): compie il lavoro richiesto dall utente. Per permettere lo scambio di messaggi cifrati, ogni utente ed ogni servizio dovranno avere una chiave condivisa ed utilizzare un algoritmo di crittografia forte. Il server AS conserva al suo interno un database con le chiavi degli utenti e le chiavi dei servizi, quindi è in grado di scambiare con essi messaggi cifrati senza che Verifica della quantità di risorse utilizzate da un particolare utente connesso 14 Letteralmente un "biglietto", che un client presenta ad un server di servizio applicativo, per dimostrargli l'autenticità della sua identità.

25 2.2.3 Autenticazione con Kerberos 25 venga scambiata la chiave. La tecnica adottata per utilizzare la password dell utente nelle operazioni di cifratura, si basa su di una conversione che trasforma la password, in una chiave di cifratura simmetrica condivisa tra utente e server AS. Quindi nemmeno il server conosce la reale password, ma solo una sua cifratura. Il funzionamento del protocollo si distingue in tre diverse fasi: La prima fase, l'authentication Service Exchange, avviene all'atto del login dell'utente, dove vi è uno scambio di messaggi con il server AS, cifrati con la loro chiave condivisa. In questa fase, la workstation controlla in locale la validità della password. Se la password è errata, l utente non può decifrare il messaggio in arrivo dal server AS. Dunque la password non è entrata in rete ed è rimasta sulla workstation solo per pochi millisecondi. Nella seconda fase, il Ticket Granting Service Exchange, viene concesso il ticket di servizio dal server TGS all utente che lo richiede, dopo aver presentato opportune credenziali valide passate nella fase uno dal server AS. Il ticket ha una validità temporale, così da evitare che intrusi usino ticket scaduti. Ed infine la terza fase, il Client/server Authentication Exchange, dove l utente si presenta al servizio applicativo forte del ticket appena ricevuto. Figura 2.6 Protocollo di autenticazione Kerberos.

26 2.2.3 Autenticazione con Kerberos 26 Lo scopo di tutta questa infrastruttura è di permettere al client di accedere ai server su tutta la rete in modo sicuro, senza che le sue informazioni segrete viaggino in rete. Infatti la password è rimasta sulla workstation e solo per pochi istanti. Successivamente se l utente vuole accedere ad un servizio di un altro server applicativo, deve semplicemente richiedere un altro ticket al server TGS, senza autenticarsi nuovamente ad AS. Questa tecnica è il preludio al concetto di autenticazione centralizzata con CAS, che verrà trattata esaustivamente. Si può però notare che il lavoro di autorizzazione è lasciato completamente ai singoli server applicativi. Infatti i ticket che gli utenti presentano, servono solo a dimostrare la loro identità, ma non a concedere permessi privilegiati. Kerberos è utilizzato in molti sistemi reali, ed è una buona soluzione, tuttavia non da nessuna garanzia se l infrastruttura è vulnerabile: i server di autenticazione AS e TGS, i server applicativi (imap, pop, smtp, telnet, ftp, ssh, AFS, lpr,...) ed i client devono essere mantenuti costantemente aggiornati perché si posso garantire la sicurezza.

27 2.2.4 Autenticazione con crittografia a chiave pubblica Autenticazione con crittografia a chiave pubblica La mutua autenticazione può essere eseguita anche con la crittografia a chiave pubblica. Se Alice vuole comunicare con Bob, ha bisogno della sua chiave pubblica. Se esiste una terza parte fidata che gestisce le chiavi pubbliche, solitamente una Public Key Infranstructure (PKI), Alice può richiedergli la chiave pubblica di Bob ed iniziare la comunicazione. Solitamente la chiave pubblica è contenuta all interno di un certificato digitale, argomento prevalente dei prossimi capitoli. Ottenuta la chiave, Alice invia un messaggio a Bob comprendente la sua identità ed un numero casuale, cifrato con la sua chiave pubblica. Quando Bob riceve il messaggio, lo decifra con la sua chiave privata, e vede l identità di Alice. Però è ancora ignaro sulla sua vera identità, chiede quindi alla PKI di fornirgli la chiave pubblica di Alice. Ricevuta la risposta, crea un pacchetto cifrato con la chiave pubblica di Alice, e glielo invia. Il pacchetto contiene il numero casuale generato da Alice, un altro numero casuale generato sul momento da Bob, ed una chiave di sessione da utilizzare. Alice riceve il pacchetto da Bob e lo decifra con la sua chiave privata. Vedendo che Bob le ha reinviato il suo numero casuale, il messaggio non è una ripetizione, quindi è sicura di parlare con lui. Come ultimo passo, Alice reinvia il numero casuale generato da Bob, cifrandolo con la chiave di sessione da lui scelta, così da confermare la mutua autenticazione. Figura 2.7 Mutua autenticazione con crittografia a chiave pubblica

28 2.3 Metodi di autenticazione Metodi di autenticazione L identità di un soggetto durante un tentativo di autenticazione può essere controllata principalmente in tre diversi modi: Quello che si sa: All utente è associato un username ed una password. Solitamente l username è una stringa contenente un nome, un indirizzo e- mail, oppure un nickname. La password invece è una stringa, che generalmente non ha un particolare significato. E come una chiave da inserire, per dimostrare di conoscerla, ed essere veramente chi si dichiara. La password dovrebbe essere sufficientemente complessa per non essere indovinata, e non troppo difficile da non ricordare. Quello che si ha: un certificato digitale o una smart card. Un certificato digitale è un documento elettronico, che stabilisce le proprie credenziali sul web. Una smart card invece è una carta di plastica, come una vera e propria carta di credito, e necessita di un architettura hardware esterna per poter essere letta. Contiene un micro-chip dove sono salvate varie informazioni sul possessore, e talvolta queste informazioni sono proprio sotto forma di certificato digitale. Quello che si è: si utilizzano dati biometrici personali per identificare l utente. Questi possono essere riconoscimento della voce, impronte digitali, dimensioni delle dita e della mano, scansione della retina ecc. In ogni caso sono necessari complessi dispositivi fisici per effettuare i riconoscimenti, il che porta quest ultimo tipo ad essere ancora poco in uso Vantaggi e svantaggi dei metodi di autenticazione Nelle tre metodologie viste sopra, ognuna ha dei particolari vantaggi e svantaggi, in termini di efficienza, sicurezza, garanzia, e costi di realizzazione.

29 2.3.1 Vantaggi e svantaggi dei metodi di autenticazione 29 La più semplice delle tre è l autenticazione tramite password. La sicurezza di questo metodo dipende molto anche dalla realtà in cui si deve operare. Se un username ed una password di un contatto in una chat vengono intercettati, il problema pur non essendo banale, non è relativamente grave. L intruso può impersonificare l utente mandando qualche messaggio o qualche mail, o scorrere la lista di contatti. Ben più grave situazione invece, se le credenziali di un conto bancario di un utente cadono in mani sbagliate. Questo metodo ha però anche altre problematiche sia per gli utenti, sia per i fornitori dei servizi richiesti. I servizi disponibili e richiesti dalla stragrande maggioranza degli utenti sono molteplici, è quindi necessario ricordarsi molte differenti password. Questo può portare ad avere sempre la medesima password per più servizi, o sceglierne di troppo semplici, il che facilità l intercettazione. Per alcuni, le continua richieste di autenticazione sono considerate scomode, ed un ostacolo alla navigazione. Gli utenti tendono anche a dimenticare le password, contattando l assistenza o se possibile procedendo direttamente alla creazione di un nuova identità. Questo comporta notevoli costi per gli i gestori degli applicativi. Inoltre vari servizi richiedono che la password venga cambiata dopo un determinato periodo, oltre il quale viene considerata scaduta. Questo per aumentare ulteriormente la sicurezza. Per questi motivi, talvolta l utente incarica terze parti per aiutarlo nel processo di autenticazione. Questi possono essere software locali o remoti. Localmente, la gestione delle password può essere demandata al browser web dell utente. Questi può ricordare tutte le varie password dei vari siti visitati, semplificando la vita all utente. Tuttavia non viene risolto il problema se l utente si collega ad internet da postazioni diverse, come una biblioteca o un internet café. In remoto, la gestione delle password può essere assegnata ad un proxy server su internet, eventualmente gestito dallo stesso internet provider o da un servizio di rete specifico. Il meccanismo è simile al precedente, solo che in questo caso l utente si autentica una sola volta al proxy, il quale dopo l autenticazione utente, si preoccupa di inserire automaticamente le password quando richieste. Questa tecnica è possibile, tuttavia di non semplice implementazione e uso su scala mondiale.

30 2.3.1 Vantaggi e svantaggi dei metodi di autenticazione 30 Un ulteriore soluzione consiste nell avere un unico servizio di autenticazione fidato per più applicazioni, che utilizza un particolare protocollo sicuro da lui scelto. Si crea quindi una sottorete di fiducia, dove i servizi sono direttamente collegati all unico dispositivo di autenticazione. Una volta che l utente si è autenticato, può accedere alle applicazioni di quella sottorete. Questa è l idea che sta alla base dell autenticazione centralizzata, e del server CAS. Ovviamente il dispositivo di autenticazione può anche essere configurato per autorizzare o meno un utente ad accedere ad un servizio, ma come già detto questo è un altro problema. Questa tecnica è una delle più adottate, nelle aziende ma soprattutto dalle Università, in quanto si vuole dare ai propri studenti la possibilità di un'unica autenticazione centrale, per poi poter eseguire varie operazioni, come l iscrizione agli esami, iscrizioni ai corsi, servizio mail ecc. Al crescere dell importanza di verificare con certezza l identità di un utente, username e password non offrono più un metodo sicuro. Un altro aspetto, per certi versi ancora più importante della sicurezza dell identità, è la sicurezza dell autenticità di un messaggio inviato. Quando si ha a che fare con documenti legali, ordini e transazioni aziendali e bancarie, si deve trovare un modo per poter verificare che il documento elettronico sia autentico, oltre che assicurarsi che sia stato spedito veramente dal mittente dichiarato. E ovvio che un autenticazione con semplice username e password e successivo invio del documento, non offre abbastanza sicurezza e autenticità richiesti per questo ambiente. Con la nascita dei certificati digitali, delle smart card, dei token USB, e dell idea di introdurre la firma digitale, entrambi i problemi possono essere risolti. Tuttavia la sicurezza e l autenticità non possono essere garantiti con assoluta certezza, perché se un utente smarrisce la propria smart card, e magari ha all interno il codice PIN 15 per utilizzarla, si è di nuovo al punto di partenza. Questa vulnerabilità però non è collegata ad una falla nella struttura informatica portante, ma solo ad un errore umano. L uso di certificati digitali e di smart card è in continua espansione, e probabilmente saranno il metodo di autenticazione predominante nei prossimi anni. 15 Codice numerico di quattro cifre.

31 2.3.1 Vantaggi e svantaggi dei metodi di autenticazione 31 Il terzo modo di autenticazione, ovvero quello per biometria, offre al giorno d oggi la maggior sicurezza possibile. I lettori di impronte digitali stanno uscendo di serie su molti modelli di computer portatili, e si può immaginare che in futuro non serviranno solo per il login locale del computer, ma anche per un autenticazione biometrica in rete. Tuttavia dato il costo ancora molto elevato di alcuni strumenti necessari al riconoscimento personale, basti pensare ad un apparecchio di scansione della retina, questa metodologia non è ancora del tutto diffusa, e riservata a pochi utenti. Le ultime due tecniche viste vengono chiamate tecniche di autenticazione forte. L autenticazione forte è divenuta fondamentale con la comparsa di attacchi alla rete e furti di dati sempre più sofisticati, la necessità di aprire le reti aziendali per includere fornitori, clienti e partner commerciali e l inasprimento e la capillarità delle normative. Nonostante ciò, le spese e la complessità delle soluzioni di autenticazione forte spesso ne scoraggiano l adozione. I problemi di sicurezza continuano a minare la fiducia nelle attività online. Uno dei più gravi e sentiti è il controllo dell identità. Se gli utenti e i dispositivi che accedono alla rete non vengono identificati adeguatamente, le imprese sono esposte al rischio di frodi, phishing, furto di identità, spoofing di IP. Il phishing è una nuova subdola forma di social engineering, nella quale i criminali si presentano come entità legittime per ottenere da ignari consumatori informazioni personali come numeri di carta di credito, password e numeri di previdenza sociale. Di norma, questi soggetti utilizzano siti Web fraudolenti o indirizzi di aziende ben note per inviare messaggi di spam che ingannano il destinatario e lo inducono a fornire dati confidenziali. Le informazioni personali così acquisite vengono poi usate per frodi con carte di credito, furti di identità e altri reati. La sicurezza dei metodi di autenticazione, si può quindi riassumere: Debolissima: Username/password trasferite in chiaro (da vietare) Debole: Username/password su canale criptato Media: Protocollo Challenge/response con Secure ID Forte: Certificati digitali/token USB/smartcard + PIN

32 2.4 Autenticazione centralizzata SSO Autenticazione centralizzata SSO L autenticazione centralizzata, single sign on (SSO) è un meccanismo che permette all utente di accedere a varie risorse informatiche, autenticandosi una sola volta ad un elemento centrale. Il SSO riduce gli errori umani, i fallimenti di sistema, ed è sempre una metodologia desiderabile, anche se non sempre facile da implementare. Una volta che l utente ha effettuato con successo l autenticazione al servizio centrale, non sarà più necessario inserire le proprie credenziali, perché sarà riconosciuto globalmente da tutti i servizi applicativi facenti parte di quel sistema. Queste non si preoccuperanno più di gestire autonomamente ogni autenticazione, ma solo verificare che l utente si sia effettivamente connesso al server centrale. In molti casi le diverse applicazioni hanno diversi meccanismi di autenticazione e usano protocolli differenti. L uso del SSO può unificare tutto ciò: il sistema di SSO deve tradurre internamente e memorizzare le diverse credenziali rispetto a ciò che viene utilizzato per l'autenticazione iniziale. Questo introducendo anche uno standard unico per quel relativo sottosistema, scegliendo un protocollo specifico a seconda del grado di sicurezza richiesto. In questo modo il livello di sicurezza globale del sistema aumenta notevolmente. I principali obiettivi del SSO sono quindi semplificare la gestione delle password, migliorare la gestione dell accesso ai vari servizi, e rendere univoca la definizione delle politiche di sicurezza delle varie applicazioni. L architettura di un sistema SSO può essere composta in tre diversi modi: centralizzata, federata e cooperativa. Nell architettura centralizzata il principio è quello di utilizzare una base di dati globale o un servizio di directory come un server LDAP 16, comune a tutti gli utenti. Questa è utile quando tutti gli utenti appartengo ad una stessa organizzazione, come un azienda o una singola università. Nell architettura federata, differenti organizzazioni cooperanti tra loro gestiscono i dati di uno stesso utente, creando una federazione. L autenticazione ad uno dei 16 Lightweight Directory Access Protocol.

33 2.4 Autenticazione centralizzata SSO 33 sistemi collegati, concede l accesso anche agli altri sistemi federati, ma ogni singolo ente può operare scelte differenti sulle politiche di sicurezza interne. Questa tecnica è ottima quando si hanno aziende dello stesso settore, che offrono servizi diversi, come per esempio un agenzia di viaggi convenzionata con l azienda dei trasporti pubblici e con una catena alberghiera, che offrono promozioni agli utenti abbonati. L architettura cooperativa è simile alla precedente, con la differenza che ogni singolo utente è associato ad un ben preciso ente del consorzio. Quando un utente cerca di avere accesso ad una delle risorse comune, l autenticazione viene effettuata dalla società che lo gestisce direttamente. Ovviamente la politica di sicurezza, e soprattutto quella di autorizzazione, è controllata da ogni singolo ente della comunità. Questa può essere un ottima scelta se si vuole creare un consorzio di università, che intendano lavorare e progredire scambiandosi informazioni e condividere i risultati ottenuti. Figura 2.8 Differenze tra autenticazione normale e centralizzata

34 2.4 Autenticazione centralizzata SSO 34 I vantaggi nell uso di un sistema di autenticazione centralizzato sono molteplici: Riduzione del numero di credenziali che l'utente deve utilizzare e ricordare Minor tempo di autenticazione passando da un sistema ad un altro. Miglio grado di sicurezza dei singoli servizi applicativi Uniformità locale delle interfacce e dei protocolli di autenticazione, e miglior gestione dei messaggi personali o di errori. Riduzione dei costi. Minor costo di infrastrutture e server dedicati, con eventuale investimento su un ulteriore aumento della sicurezza e aggiornamenti. Inoltre il minor numero di password riduce anche il costo di assistenza per il recupero di credenziali dimenticate o sottratte. Tuttavia, anche se i benefici sono tanti, non sempre è possibile implementare un SSO efficiente. Molte applicazioni proprietarie hanno un loro specifico protocollo di autenticazione, non adattabile completamente ad uno di tipo centralizzato. Lo svantaggio più grande rimane comunque quello relativo all intercettazione ed uso improprio delle credenziali proprietarie. Avendo accesso a molteplici servizi, l intruso può operare un danno molto maggiore rispetto in precedenza. Alcuni sistemi devono quindi attuare politiche di sicurezze con standard molto elevati, in alcuni casi integrando un sistema di autenticazione forte con smart card o di tipo biometrica, oltre alla normale autenticazione con password. Lo sforzo iniziale dell utente in fase di accesso, varrebbe un grado di sicurezza molto superiore. CAS è un buon esempio di autenticazione centralizzata con un buon grado di sicurezza, infatti è utilizzato da molte aziende e università, così come il protocollo Kerberos. Ultimamente sta prendendo molto campo l idea di avere una smart card personale, contenete oltre al proprio certificato digitale, anche informazioni sull utente e la gestione automatica delle password, il tutto crittografato e coperto da codice PIN. Durante il processo di autenticazione, viene richiesto all'utente di inserire la carta negli appositi lettori, e la sessione rimane valida finché la scheda rimane inserita.

35 Capitolo 3 L identità digitale Il numero dei servizi offerti in rete in modo automatizzato esiste da numerosi anni ed è sempre più sviluppato. Di questi, qualcuno può essere anonimo, altri necessitano di una registrazione direttamente on-line inserendo solamente un username 17 ed una password da utilizzare, altri ancora invece richiedono esplicitamente informazioni personali come nome, cognome, indirizzo ecc. Un utente che intende registrarsi ad una chat o ad un forum di discussione, può di norma decidere se inviare o meno i propri dati personali. Quando invece i servizi richiesti utilizzano dati sensibili, ovvero dove ci sono dei pagamenti, le informazioni personali, oltre ad essere obbligatorie, dovrebbero anche essere veritiere. L importanza di avere un identità elettronica in rete acquisisce quindi una notevole importanza, sia dalla parte dell utente in questo caso il consumatore, sia dalla parte del fornitore dei servizi, che può così avere una garanzia che il suo cliente sia veramente chi dice di essere. La rappresentazione dell identità digitale deve essere tanto più completa, quanto è complessa la transazione in cui è coinvolta. Infatti il grado di affidabilità e le quantità di informazioni richiesti 17

36 3 L identità digitale 36 possono variare molto a seconda del tipo di transazione. L identità digitale è importante anche all interno di una singola organizzazione. Queste talvolta utilizzano personale mobile, quindi una gestione corretta delle identità digitali diventa critica anche per gli affari e per la protezione del patrimonio aziendale. Le identità digitali vanno gestite in modo opportuno perché sono una parte integrante del business. L identità digitale però non è solo un username e una password. E anche un sistema complesso di gestione di identità, autenticazioni, autorizzazioni, profili e informazioni biometriche. Ad oggi è un architettura a parte nel mondo sempre più complesso dell ICT 18. Come si è visto, normalmente per accedere a una risorsa un soggetto deve usare delle credenziali. Tramite il concetto di identità digitale, le credenziali vengono presentate a un autorità di sicurezza o a un Policy Enforcement Point 19 che le valida o le rigetta. Nella maggior parte dei casi, queste si presentono sotto forma di username e password, certificati digitali di tipo X.509, una smart card con relativo PIN, o informazioni biometriche. Le metodologie che stanno prendendo maggiormente campo sono quelle dei certificati digitali e delle smart card. Inoltre utilizzando uno di questi concetti, l autenticazione è più sicura e più flessibile. Quando si hanno queste garanzie di appartenenza delle proprie credenziali proposte, si parla quindi di autenticazione forte. L identità digitale in Italia è regolamentata da particolari norme giuridiche. Queste sono comprese nel Codice dell'amministrazione Digitale, un decreto legislativo emanato nel 7 marzo 2005, n 82, con lo scopo di fissare regole per l uso dell informazione digitale per i singoli cittadini, le pubbliche amministrazioni e le aziende. Questo è stato rivisitato e corretto con il decreto legislativo del 4 aprile 2006, n 159, Disposizioni integrative e correttive al decreto legislativo 7 marzo 2005, n.82 recante codice dell amministrazione digitale. Questi due decreti, hanno anche lo scopo di regolamentare il concetto di firma elettronica digitale, operazione fondamentale per assicurare autenticità ad un documento in formato elettronico Policy Enforcement Point

37 3.1 Tipi di firme elettroniche Tipi di firme elettroniche Firma elettronica e firma digitale vengono spesso utilizzate nel linguaggio comune come sinonimi, ma vi è una differenza sostanziale nell usare l una o l altra per la sottoscrizione di un documento informatico. Il Codice dell'amministrazione digitale entrato in vigore nel gennaio 2006 (D.lgs 7 marzo 2005, n 82) ha individuato tre tipologie di firma elettronica: firma elettronica: l'insieme dei dati in forma elettronica, allegati oppure connessi tramite associazione logica ad altri dati elettronici, utilizzati come metodo di autenticazione informatica: per esempio nome utente e password. firma elettronica qualificata: una firma elettronica basata su una procedura che permette di identificare in modo univoco il titolare, attraverso mezzi di cui il firmatario detenga il controllo esclusivo, e la cui titolarità sia certificata da un soggetto terzo. firma digitale: un particolare tipo di firma elettronica qualificata, basata su un sistema di chiavi crittografiche, una pubblica e una privata, correlate tra loro, che consente al titolare tramite la chiave privata e al destinatario tramite la chiave pubblica, rispettivamente, di rendere manifesta e di verificare la provenienza e l integrità di un documento informatico o di un insieme di documenti informatici. 3.2 Firma digitale Talvolta per essere sicuri che nessuno intercetti i dati e le informazioni che due soggetti si stanno scambiando, è utile avere un mezzo per poter verificare che nessuno li abbia modificati durante la trasmissione. Il documento che è stato inviato dall identità digitale dichiarata, deve poter essere verificato e giudicato autentico in modo veloce, sicuro e garantito.

38 3.2 Firma digitale 38 L autenticità nei documenti legali o finanziari in formato cartaceo è garantita dalla presenza della firma autografa autorizzata originale. Fotocopie a tali documenti non sono ritenute valide a fini legali e giuridici. È quindi necessario disporre di un metodo analogo di firma certificata, anche per i documenti elettronici. Nasce quindi l idea di introdurre una firma digitale nei documenti elettronici che vengono scambiati con mezzi informatici. La firma digitale è il risultato di una sorta di validazione informatica che permette al sottoscrittore di provare l autenticità del documento informatico ed al destinatario di verificarne la provenienza e l integrità. Finora si è partito dal presupposto che solo un intruso esterno abbia l intenzione di modificare il contenuto di un documento. In realtà ci sono svariati motivi per i quali sia il destinatario, che il mittente, possano avere interesse nel modificare delle parti del messaggio. Si prenda come esempio un agente di borsa che opera con compravendita on-line di azioni. Questi invia alla propria banca l ordine di comprare un certo numero di azioni. Poco dopo le azioni crollano, e l agente cercando di imbrogliare la banca, dichiara di non aver mai compiuto l ordine. In questo caso il disonesto sarebbe l agente di borsa, ovvero il mittente. Continuando con l esempio precedente, si ipotizzi invece il caso in cui le azioni invece che crollare, fossero salite vertiginosamente. La banca potrebbe affermare che l agente di borsa avesse ordinato un numero molto inferiore di azioni rispetto a quello reale, e tenersi il resto del guadagno. In questo caso il disonesto sarebbe la banca, quindi il destinatario. In formato cartaceo, per ovviare a questo tipo di frodi, solitamente si tiene questa tipologia di documenti in duplice copia, ognuno debitamente firmato da entrambi. Invece nei documenti elettronici, la struttura e gli schemi della firma digitale assicurano ed implementano il principio del non ripudio: chi ha firmato il documento trasmesso non può negare di averlo inviato, ed il destinatario non può negare di averlo ricevuto. L informazione quindi non può essere disconosciuta. La garanzia che il documento informatico non possa essere stato modificato dopo la sua sottoscrizione, senza accorgersene, deriva dal fatto che una specifica procedura di verifica del contenuto del messaggio mostrerebbe subito le eventuali modifiche.

39 3.2 Firma digitale 39 La firma digitale solitamente è inserita all interno di una smart card o di un certificato digitale, che contiene informazioni del titolare, la sua chiave pubblica di firma, ed eventuali altri attributi. Perché queste informazioni siano qualificate, debbono essere validate da un ente certificatore, che ne controlla il rilascio e la pubblicazione su un apposito registro. La certezza che solo il titolare della firma possa aver sottoscritto il documento, deriva dal fatto che è l unico in possesso di essa e del dispositivo di firma associato, ed è anche l unico a conoscere il PIN segreto per utilizzare il dispositivo stesso. Inoltre l ente che ha certificato le informazioni ne garantisce la loro veridicità. Esempi tipici dell utilizzo della firma digitale possono essere tutti gli adempimenti da effettuare verso le amministrazioni: denunce, dichiarazioni di cambi di residenza, di domicilio, richieste di contributi, di esenzioni a pagamenti a causa del reddito o di altre condizioni particolari, ricorsi, ecc. Fra privati, può trovare impiego nella sottoscrizione di contratti, verbali di riunioni, ordini di acquisto, risposte a bandi di gara, ecc. La firma digitale trova già da tempo applicazione nel protocollo informatico, nella procedura di archiviazione documentale, nel mandato informatico di pagamento, nei servizi camerali, nelle procedure telematiche d acquisto, ecc. La firma digitale sta avendo sempre più successo su scala mondiale e nella comunità europea. Dopo varie analisi condotte dalla F.E.S.A. 20, il cui scopo è far incontrare i vari organismi di vigilanza in Europa per regolamentare la firma elettronica, si è riscontrato che la diffusione della firma digitale sta aumentando esponenzialmente anno dopo anno. In questo campo l Italia è al primo posto delle classifiche europee per numero di dispositivi di firma come smart card o certificati digitali: dall anno 2002, dove i certificati erano circa , si è passati a circa certificati nel 2009, cifre nettamente superiori agli altri stati europei. La firma digitale è uno strumento molto potente e come tale deve essere utilizzato nei modi e nei casi appropriati. Non è corretto il suo utilizzo solo come sistema di identificazione e autenticazione in rete, per il quale esistono strumenti quali la carta d identità elettronica e le carte di accesso ai servizi che meglio svolgono questo compito. 20 Forum of European Supervisor Authority

40 3.2.1 Creazione della firma digitale Creazione della firma digitale La creazione della firma digitale di un documento si basa sulla tecnica della crittografia a chiave pubblica e sull ausilio di una funzione hash 21. Una funzione hash monodirezionale prende in ingresso del testo in chiaro di lunghezza arbitraria, e calcola in uscita una stringa di bit di lunghezza prefissata, solitamente 160 bit. Questa stringa viene chiamata impronta digitale (message digest), e può essere considerata una sorta di riassunto speciale del messaggio. La funzione hash da utilizzare, deve avere queste quattro proprietà: Dato un qualsiasi messaggio, è facile e veloce calcolare la sua funzione hash. Dato un messaggio, la sua impronta digitale calcolata dalla funzione hash è sempre la stessa. Con la sola impronta digitale calcolata dalla funzione hash, è impossibile risalire al messaggio originale. Dato un messaggio, è impossibile trovarne un altro tale che le due impronte digitali calcolate siano uguali. Se nel messaggio viene fatta anche una sola modifica, la sua impronta digitale deve essere completamente diversa dalla precedente. Le funzioni hash maggiormente utilizzate sono MD5 22, e SHA Un soggetto che intende firmare un suo documento, per prima cosa ricava l impronta digitale di quel documento tramite una funzione hash da lui scelta. Successivamente cifra l impronta appena ottenuta con la sua chiave privata. Il risultato di questa cifratura è la firma digitale del documento. Questa è direttamente collegata sia al proprietario della chiave privata che l ha cifrata, sia al documento stesso. Dato che la sua dimensione è relativamente piccola, può essere allegata al messaggio originale e inviata sotto forma di un unico messaggio contenete la coppia documento-firma. Il destinatario dal canto suo può verificare velocemente sia l identità del mittente sia l integrità del documento. Per prima cosa ottiene la chiave pubblica del

41 3.2.1 Creazione della firma digitale 41 mittente, e con essa decifra la firma allegata al documento, ottenendo l impronta digitale inviatogli. Dopodiché calcola esso stesso la funzione hash del messaggio ricevuto, trovando la sua impronta digitale. Se le due impronte sono uguali, il messaggio è autentico ed inviato dal mittente, altrimenti qualcuno si è intromesso. In questa metodologia di creazione della firma digitale, si è ipotizzato di inviare il documento come testo in chiaro, cifrando solo la sua impronta ottenendo la firma. Ovviamente a volte è necessario cifrare anche il messaggio stesso. Questo però non è assolutamente un problema, in quanto dopo la creazione della coppia (documento-firma), questi essendo un normale messaggio, può essere cifrato con le tecniche viste, anche se in questo caso è più comune è utilizzare la cifratura a chiave pubblica, perché le rispettive chiavi pubbliche sono già state scambiate. Figura 3.1 Creazione di un documento firmato e cifrato

42 3.2.2 Il valore legale della firma digitale in Italia Il valore legale della firma digitale in Italia In Italia le controversie legali dovute ad un disconoscimento di firma autografa su documenti in formato cartaceo, vengono sottoposte a giudizio eventualmente in tribunale. La persona o l ente in questione deve solo disconoscere la firma apportata al documento. Dimostrare che la paternità della firma sia del soggetto che la sta disconoscendo, è compito della controparte o di una terza parte, solitamente attraverso perizie calligrafiche condotte da esperti. Ma nell ambito elettronico un esame di questo tipo non è ovviamente possibile, e si devono quindi escogitare altri metodi altrettanto validi per questo tipo di controversie. L Italia è all avanguardia nell uso legale della firma digitale, essendo stato il primo paese al mondo ad avere attribuito piena validità giuridica ai documenti elettronici (in presenza di determinate condizioni) con il DPR 513 del In questo decreto, ed in quello successivo inerente anch esso all argomento della firma elettronica, ovvero il decreto DPR 445/2000, si è cercato per la prima volta di fondare delle basi giuridiche per l uso della firma digitale: la firma digitale venne equiparata a quella autografa. Assolveva al requisito giuridico della forma scritta, e come la firma autografa, poteva essere disconosciuta dal firmatario. Dimostrare la paternità della firma ricadeva ad una terza parte, qualora fosse stata disconosciuta. Questa una parte di tale articolo: " gli atti, dati e documenti formati dalla Pubblica amministrazione e dai privati con strumenti informatici o telematici, i contratti stipulati nelle medesime forme, nonché la loro archiviazione e trasmissione con strumenti informatici, sono validi e rilevanti a tutti gli effetti di legge." Parte dell articolo 15 del DPR 513/97 Successivamente il Decreto legislativo 23 gennaio 2002, n. 10, modificava profondamente il valore giuridico della firma digitale, ribaltando l onere della prova di paternità: il presunto firmatario, per annullare gli effetti giuridici della

43 3.2.2 Il valore legale della firma digitale in Italia 43 firma digitale, doveva intentare una querela di falso 24, ovvero intentare una causa giudiziaria a tutti gli effetti con la presenza di un pubblico ministero. Nel 2006, il CAD (Codice dell Amministrazione Digitale D.Lgs 7 marzo 2005, n.82) la firma digitale torna ad avere gli effetti della firma autografa (ex art c.c.), ma vengono ridotti gli obblighi del presunto sottoscrittore per vedere disconosciuta una firma digitale con le sue credenziali ma non eseguita da lui. Non è più necessario ricorre ad una querela di falso con la relativa iter processuale, ma solamente provare che altri abbiano potuto utilizzare il dispositivo di firma al posto suo. Questa la sintesi saliente del decreto dove vengono ridotto gli obblighi del firmatario: Il documento informatico sottoscritto con firma digitale o con un altro tipo di firma elettronica qualificata, ha l efficacia prevista dall articolo 2702 del codice civile. L utilizzo del dispositivo di firma si presume riconducibile al titolare, salvo che sia data prova contraria. Parte dell articolo 21 comma 2 del D.Lgs 82/2005 Questa momentanea decisione fece molto scalpore, in quanto i dispositivi di firma non sono violabili, e i codici ad essi associati sono forniti in maniera sicura al legittimo titolare. Al momento della consegna del dispositivo, il titolare è tenuto ad osservare degli obblighi relativi alla conservazione di questi e dei relativi codici, che se venissero ignorati, non esenterebbe il titolare da colpe. L ultima modifica di legge in merito alla firma digitale, fu introdotta nel successivo decreto legge del 4 aprile 2006, n 159, e servì per togliere definitivamente la paradossale condizione che si era venuta a creare con il decreto dell anno precedente: ovvero che si sarebbe potuto dare prova che altri avessero usato il dispositivo di firma del titolare, il che era ed è vietato dalle norme vigenti, annullandone i relativi effetti giuridici, anche se il presunto firmatario avesse riconosciuto la paternità della propria firma e la volontà di firmare gli atti coinvolti. 24

44 3.2.2 Il valore legale della firma digitale in Italia 44 Questo decreto mise dunque fine a queste controversie: Il documento informatico sottoscritto con firma digitale o con un altro tipo di firma elettronica qualificata, ha l efficacia prevista dall articolo 2702 del codice civile. L utilizzo del dispositivo di firma si presume riconducibile al titolare, salvo che questi dia prova contraria. Parte dell articolo 21 comma 2 del D.Lgs 159/2006 La legge quindi dice ora che spetta al soggetto che vuole disconoscere la propria firma digitale, portare e presentare prove sufficienti al fine di provare un suo furto o un suo uso improprio da parte di altri. Esiste un altro aspetto del quale è necessario un ulteriore approfondimento, che riguarda sempre il valore probatorio della firma digitale. Il certificato del titolare (l elemento che consente di ricondurre le chiavi crittografiche usate ad una persona fisica) ha un periodo di validità, ma può anche essere revocato o sospeso prima della naturale scadenza. La revoca e sospensione del certificato hanno lo steso effetto giuridico: le firme digitali generate sulla base di un certificato scaduto, revocato o sospeso, non hanno alcun effetto giuridico. La revoca che è un procedimento irrevocabile, e la sospensione che invece può essere solo temporale, possono avvenire in diversi casi, quali la sottrazione o lo smarrimento del dispositivo di firma, o quando le informazioni contenute nel certificato non sono più corrette, per esempio il titolare ha cambiato azienda. È quindi evidente che potrebbero sorgere delle problematiche in termini temporali. Questi sarebbero legati al fatto di poter comunque disporre di un documento informatico sottoscritto con firma digitale in un periodo temporale molto posteriore, anche se in questo momento il relativo certificato potrebbe essere scaduto, revocato o sospeso. Per questo è quindi necessario riuscire a collocare nel tempo, l esistenza e la validità della firma del documento in questione, in modo da poter provare che la stessa è stata prodotta in un momento in cui il relativo certificato era ancora valido. Per far ciò si utilizza un servizio di marcatura temporale, grazie il quale si può associare ad un documento informatico una sorta di etichetta elettronica, allo scopo di dimostrare che tale documento contenente una data firma, esisteva in un

45 3.2.2 Il valore legale della firma digitale in Italia 45 ben preciso momento. Il riferimento temporale opponibile ai terzi può anche essere ottenuto attraverso l utilizzo della posta elettronica certificata, della segnatura di protocollo e attraverso la procedura di conservazione documentale. L utilizzo di tali modalità sono però ancora prerogativa esclusiva delle pubbliche amministrazioni (cfr. art. 39 del DPCM 13 gennaio 2004), e lo saranno almeno a tutto il mese di settembre Con l entrata in vigore del DPCM 30 marzo 2009, la segnatura di protocollo e la posta elettronica certificata potranno essere utilizzate da tutti. Nella prossima tabella verranno riassunte le principali differenze tra le due tecniche di firma: firma autografa e firma digitale. Firma autografa Firma digitale Creazione Apposizione Paternità Verifica Paternità Contraffabilità documento copia Manuale Sul documento La firma è una sua parte integrante e legata al supporto. Riconducibile al soggetto direttamente. Diretta e soggettiva, attraverso il confronto con una firma autentica. Agevolmente contraffabile, ma facilmente riconoscibile. Digitale, mediane apposito algoritmo Allegata al documento La coppia (documento-firma) costituisce il documento. Riconducibile al soggetto tramite l uso del suo PIN privato e segreto. Indiretta e oggettiva attraverso un algoritmo di verifica pubblico. Non contraffabile senza il PIN segreto, ma eventuale falso non riconoscibile. Validità temporale Illimitata Limitata Ripudiabilità Autentica per impedire il ripudio. Ripudio impossibile senza provare il contrario. Figura 3.2 Principali differenza tra firma autografa e firma digitale.

46 3.3 Gestione delle chiavi pubbliche Gestione delle chiavi pubbliche La crittografia a chiave pubblica consente la comunicazione sicura tra soggetti che non condividono una chiave comune, e permette la firma dei documenti senza la presenza costante di una terza parte fidata sempre on-line. Il problema sul quale sì è prestata poca attenzione è: come fanno due soggetti che non si conoscono, a procurarsi le rispettive chiavi pubbliche ed essere completamente sicuri che appartengano veramente a loro? Una possibile soluzione sarebbe quella di istituire un sito web per ogni soggetto, ed inserire all interno di esso la propria chiave pubblica. Ovviamente questa non può risultare una soluzione accettabile. Sarebbe molto semplice per un possibile intruso, intercettare la richiesta della home page da parte da parte del richiedente la chiave, e sostituirne una contraffatta. L ignaro utente credendo di dialogare con il soggetto richiesto, potrebbe passare informazioni preziose all intruso, il quale potrebbe anche facilmente modificare questi messaggi e ridirigerli al vero utente richiesto, con conseguenze disastrose. È quindi necessario avere un sistema sicuro per poter scambiare le chiavi pubbliche ed essere sicuri della loro provenienza. Un primo tentativo per distribuire le chiavi sarebbe quello di avere un centro di distribuzione chiavi aperto 24 ore su 24 che fornisca le chiavi pubbliche su richiesta. Questa idea non sarebbe del tutto errata, però l intero sistema diventerebbe presto un collo di bottiglia, pregiudicando la scalabilità. Inoltre se il centro fosse fuori uso per un guasto, la sicurezza di tutta la rete diventerebbe instabile e subirebbe un improvvisa battuta d arresto. Per questo motivo è stata sviluppata una soluzione differente: non è più necessaria la creazione di un centro sempre on-line, ma un centro che certifichi che le chiavi pubbliche siano associate alle persone o gli enti che le esibiscono. Un organizzazione che certifica l appartenenza delle chiavi pubbliche si chiama Certificate Autority, abbreviato CA, ovvero un autorità di certificazione. Il modo in cui la CA garantisce la veridicità dei soggetti associati, è attraverso il rilascio ad essi di un certificato digitale da lei debitamente firmato. Ovviamente prima di rilasciarlo, la CA deve essere sicura dell identità del soggetto richiedente.

47 3.3.1 Certificati digitali Certificati digitali Un Certificato digitale identifica univocamente un identità digitale. Il suo scopo principale solitamente è quello di legare una chiave pubblica ad uno specifico soggetto, che può essere un singolo utente, ma anche un intera organizzazione o un azienda. L utente potrà accedere ad ogni risorsa senza inserire nessuna password, e la sua identità sarà garantita dal certificato, così come l integrità dei dati dalla sua firma digitale. Un autenticazione con certificati è di tipo forte. I certificati non sono ne segreti ne protetti. Questo perché la loro costruzione garantisce che nessuno li possa modificare senza essere scoperti. L idea è la stessa che sta alla base della firma digitale, ovvero la crittografia a chiave pubblica. Per ottenere un certificato, un soggetto deve recarsi da una CA con la chiave pubblica da lui scelto, e un documento che garantisce la sua identità. La CA dopo opportune ricerche, può decidere o meno di rilasciare il certificato; in caso positivo emette il certificato, ne calcola l impronta e lo firma con la sua chiave privata. Dopodiché consegna al richiedente il certificato debitamente firmato. Il certificato al contrario di una normale chiave pubblica, può essere tranquillamente messo nella propria home page. Chiunque voglia dialogare con lui, può scaricare il certificato dal sito ed ottenere la relativa chiave pubblica. Come conferma, calcola l impronta digitale del certificato, e decifra la firma del certificato con la chiave pubblica della CA. Se le due impronte ottenute sono uguali, il certificato è autentico, altrimenti è stato modificato. Come per la firma digitale, anche i certificati hanno un periodo di validità temporale, e possono essere revocati. Quindi oltre al controllo precedente, si deve controllare anche che non sia scaduto o revocato. Questo può essere fatto controllando una particolare lista pubblica aggiornata costantemente, contenente i certificati revocati. Questo protocollo non è attaccabile da parte di un intruso, perciò non è necessario che i certificati siano segreti o crittografati. Un certificato può essere anche usato per associare una chiave pubblica ad un particolare attributo, per esempio la raggiunta maggiore età da parte del soggetto, così da consentirgli accesso a servizi specifici per maggiorenni.

48 3.3.1 Certificati digitali 48 Si distinguono differenti tipi di certificati secondo il livello di firma : I certificati auto-firmati sono dei certificati ad uso interno, firmati da un server locale. Questo tipo di certificati permettono di garantire la confidenzialità degli scambi all'interno di un'organizzazione, ad esempio per i bisogni di un'intranet, come una rete interna di una università. E' quindi possibile effettuare l autentificazione degli utenti, grazie ai certificati autofirmati, rimanendo all interno della intranet. I certificati firmati da un organismo di certificazione sono necessari quando si tratta di assicurare la sicurezza degli scambi con degli utenti anonimi, ad esempio nel caso di un sito web accessibile al pubblico. Il certificatore terzo permette di assicurare all'utente che il certificato appartiene effettivamente all'organizzazione alla quale dichiara di appartenere. I certificati servono principalmente in tre tipi di contesti : Il certificato cliente, immagazzinato nelle risorse del computer dell'utente oppure contenuto in un contenitore come una smartcard, che permette di identificare un utente e di associargli dei diritti. Nella maggioranza delle situazioni, esso è trasmesso ai server al momento di una connessione, che attribuisce dei diritti, in funzione dell'accreditamento dell'utente. Si tratta di una vera carta d'identità digitale che utilizza un paio di chiavi asimmetriche di una lunghezza che va da 512 a 1024 bit. Il certificato server installato su un server web permette di assicurare il collegamento tra il server e il proprietario del servizio. Nel caso di un sito web, permette di garantire che l'url e in particolare il dominio della pagina web appartengano effettivamente a questa o quell'azienda. Inoltre permette di mettere in sicurezza le transazioni con gli utenti grazie al protocollo SSL 25. Il certificato VPN 26 è un tipo di certificato installato nelle apparecchiature di rete che permette di codificare i flussi di comunicazione pezzo per pezzo fra 25 Secure Sockets Layer. Protocollo comunemente utilizzato per la gestione della sicurezza di una trasmissione dei messaggi su Internet 26 Virtual Private Network. Rete che utilizza una infrastruttura pubblica di telecomunicazioni, per fornire gli uffici remoti o singoli utenti un accesso sicuro alla rete della propria organizzazione.

49 3.3.2 Certificati X due punti (ad esempio due siti di un'azienda). In questo tipo di situazione gli utenti possiedono un certificato client, i server usano un certificato server e le apparecchiature di comunicazione uno privato Certificati X.509 Se tutti i soggetti interessati ad aver un certificato si presentassero alla CA di competenza, con una differente richiesta di struttura interna, sarebbe impossibile arrivare ad una corretta gestione di essi. Per questo sono stati sviluppati vari standard. Lo standard approvato e più in uso attualmente su internet è X.509, di cui ne sono state sviluppate varie versioni, ma in questo momento è in uso la terza versione. X.509è stato influenzato pesantemente dal mondo OSI 27, portandosi dietro però anche qualcuna delle sue caratteristiche non migliori, come la nomenclatura e la codifica. Però la IETF 28, una comunità aperta di tecnici, ricercatori e sviluppatori che ha l intento di standardizzare le tecnologie di internet, ha approvato X.509 ignorando qualche volta il protocollo OSI, come i nomi delle macchine dei protocolli di trasporto o gli indirizzi . Questa versione approvata da IETF è descritta in RCF Lo standard X509, creato dalla ITU 30, fece il suo debutto nella sua prima versione nel 1988, parallelamente allo standard X500 utilizzato per i servizi di directory 31. Assunse fin dal principio un sistema gerarchico di autorità di certificazione per il rilascio dei certificati, totalmente in contrasto con il modello della rete di fiducia, web of trust, utilizzato da PGP 32, dove chiunque poteva firmare e quindi certificare la validità delle chiavi altrui Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, IETF, April International Telecommunication Union Un servizio di directory consente di dare dei nomi a degli oggetti e di associare a tali oggetti degli attributi 32

50 3.3.2 Certificati X Nel 1993 uscì una seconda versione di X509. Fu migliorata la versione precedente con l'aggiunta di altri due campi, il sostegno e la directory di controllo di accesso. La terza versione, quella utilizzata tuttora, ha aggiunto una certa compatibilità con altre topologie di reti e filtri, come maglie e ponti, la possibilità di essere utilizzato in peer-to-peer 33, compatibilità con PGP in una rete di fiducia, e altro ancora. È stato introdotto anche un ulteriore campo opzionale: l estensione del file contenente il certificato. Le estensioni comuni più utilizzate sono.cer,.pem, e.der. La funzione principale dello standard X.509 quindi è quella di descrivere i certificati, e questo include una definizione del certificato ed i suoi relativi campi. Ogni certificato segue questa definizione, e in pratica è l unica tipologia di certificato usata e garantita nell ambito del commercio elettronico on-line. X.509 include anche gli standard per le implementazioni delle liste di revoca dei certificati (certificate revocation list,crl). L immagine mostra la struttura dello standard X509: Figura 3.3 Struttura dello standard X509 per i certificati digitali 33 Rete di computer dove non esiste l architettura client-server, ma molteplici nodi equivalenti che fungono sia da client che da server.

51 3.3.2 Certificati X I campi di ogni singolo certificato, permettono di rilevare le informazioni in esso contenute e di distinguerlo univocamente: Version (Versione): identifica la versione di quale standard X509 alla quale il certificato corrisponde. Certificate Serial Number (Numero Seriale): è un identificatore unico diverso per ogni certificato. Certificate Algorithm Identifier: L identificatore dell algoritmo utilizzato per firmare il certificato. Issuer (Ente emettitore): il nome (DN, per Distinguished Name) dell'autorità di certificazione emettente il certificato. Questo campo identifica anche chi è responsabile della verifica dell identità del soggetto. Validity Period: il periodo di validità del certificato, contenente la data di rilascio e quella di scadenza. Subject (Soggetto): il nome del computer, utente, dispositivo di rete o servizio al quale viene rilasciato il certificato. Subject public key information: informazioni sulla chiave pubblica del soggetto, precisamente. Algorithm Identifier: algoritmo per l utilizzo della chiave pubblica. Public key value: chiave pubblica del soggetto. Issuer Unique Identifier : codice identificativo univoco dell'emittente, usato per identificare l autorità che ha rilascio del certificato (opzionale). Subject Unique Identifier: codice identificativo univoco del soggetto, usato per identificare l utente del certificato (opzionale). Extension (Estensione): utilizzata per fornire ulteriori funzionalità e caratteristiche al certificato(opzionale). Certification Autority s Digital Signature: firma digitale del certificato posta dalla Certification Autority. I campi Issuer e Subject, rispettivamente ente emittente e soggetto, talvolta non contengono un solo attributo specificante il relativo nome ma una struttura tipo X500.

52 3.3.2 Certificati X I campi di un nome X500 maggiormente utilizzati nei certificati digitali sono: CN : Nome comune, o Common name O : Organizzazione OU : Dipartimento all'interno dell organizzazione C : Sigla del paese (nazione) ST : Regione o provincia L : Località E : ufficiale Con l'uso dei certificati X509 v3 e del protocollo SSL (Secure Socket Layer), sviluppato inizialmente da Netscape ma che nella versione 3.0 è stato standardizzato dalla IETF e ha preso il nome di TLS 1.0 (Transport Layer Security), è possibile creare dei tunnel di connessione sicuro. SSL é un protocollo al livello applicazione che fornisce un canale sicuro di comunicazione tra parti, ed é basato su meccanismi crittografici a chiave pubblica e su certificati X.509. Esempi di protocolli di sessione incapsulati in tunnel SSL sono: https (secure http), imaps (secure IMAP), telnets (secure telnet), smtps (secure SMTP), ldaps (secure LDAP), pop3s (secure pop3) e nntps (secure USENET transport protocol). Il protocollo TLS/SSL non si limita a criptare i dati che passano nel tunnel, ma, quando richiesto, garantisce anche l'autenticità del client e del server (mutua autenticazione). Notare che gli algoritmi asimmetrici hanno una complessità computazionale molto maggiore di quelli simmetrici, e per questo motivo nel protocollo SSL, grazie a un primo scambio di dati crittografati asimmetricamente, client e server si accordano su un algoritmo simmetrico e sulla relativa chiave di sessione con cui criptare simmetricamente il resto della conversazione.

53 3.3.3 Smart card e Token USB Smart card e Token USB La smart card è un dispositivo hardware, evoluzione della normale tessera magnetica. Contiene un microchip, nel quale sono integrati vari componenti, come un microprocessore a 8 bit, un coprocessore crittografico, e varie memorie per l archiviazione dei dati. La costruzione del microchip porta all inattaccabilità esterna delle memorie e dei dai al loro interno, a meno di una riprogrammazione completa della stessa. Grazie alle caratteristiche di protezione dei dati del microchip e alla presenza del coprocessore crittografico, sulle smart card è quindi possibile inserire in tutta sicurezza un certificato digitale X509. Di norma le smart card sono protette da un codice per poter essere attivate. Questo è il codice PIN, solitamente una stringa di quattro cifre. Per poter essere lette, le smart card necessitano di un apposito lettore hardware esterno, il che alle volte non è sempre presente in un normale personal computer. Per questo motivo, i dispositivi token USB si stanno espandendo sempre più frequentemente. Un token USB svolge le stesse funzioni di una smart card, il tutto integrato in una semplice chiavetta collegabile al computer tramite la porta USB, presente oramai dovunque. L autenticazione con smart card o token USB garantisce molta più sicurezza rispetto ai metodi tradizionali, in quanto oltre a possedere il dispositivo stesso, l utente deve anche conoscere la password o il codice di attivazione. La possibilità di avere una smart card o un token USB per l autenticazione inoltre fornisce anche molta flessibilità e portabilità, in quanto può essere usata dovunque vi sia il dispositivo di lettura o la porta USB, non rilegando quindi l utente ad utilizzare il proprio certificato X509 solo sul proprio PC locale. Figura 3.4 Esempi di Smart Card, lettori e token USB

54 3.3.4 Carta nazionale dei servizi Carta nazionale dei servizi Lo sviluppo del piano di e-government prevede la disponibilità estesa di uno strumento nazionale di autenticazione in rete. Per tale motivo il processo di diffusione di tale strumento viene accelerato affiancando al progetto della Carta di Identità Elettronica (CIE) quello della Carta Nazionale dei Servizi (CNS). La carta CNS, si configura come l infrastruttura per l accesso ai servizi in Rete (sanità, trasporti, biglietti) e la gestione personalizzata delle informazioni, semplificando i processi di identificazione e autenticazione certa, a costi contenuti e riducendo gli iter burocratici. Le caratteristiche tecniche ed organizzative della CNS sono definite dallo stesso gruppo di lavoro interministeriale, istituito dal Ministero dell interno, che cura gli aspetti tecnico-organizzativi. La carta può contenere eventuali informazioni di carattere individuale generale, ha validità determinata dall'amministrazione emittente, comunque non superiore a sei anni. Al Cnipa 34 è attribuito il compito di definire le iniziative atte a migliorare il sistema dei servizi, accessibile in rete delle pubbliche amministrazioni, ed effettuare controlli di qualità sulle procedure e sui dati utilizzati per l'emissione delle CNS. Il quadro normativo vigente ora in Italia, pone regole abbastanza rigide sull uso della carta nazionale dei servizi nelle pubbliche amministrazioni. Precisamente l articolo 66 comma 3, del D.Lgs. 82/2005 recita: è fissata la data, comunque non successiva al 31 dicembre 2007, a decorrere dalla quale non è più consentito l accesso ai servizi erogati in rete dalle pubbliche amministrazioni, con strumenti diversi dalla carta d identità elettronica e dalla carta nazionale dei servizi. Parte dell articolo 66 comma 3 del D.Lgs 82/2005 Figura 3.5 Esempio di Carta Nazionale dei Servizi fornita dalla Cnipa. 34 Centro Nazionale per l informatica nella pubblica amministrazione

55 3.4 Infrastruttura a chiave pubblica Infrastruttura a chiave pubblica Il problema della gestione delle chiavi pubbliche non è stato risolto completamente, è solo stato rimandato ad un livello più alto, ovvero la CA. Affidarsi ad una sola CA in tutto il mondo, o una specifica per ogni stato o nazione non è un idea funzionante. Lì collasserebbe tutto il carico di lavoro, e potrebbe essere un dannoso punto di rottura del sistema. Una soluzione possibile sarebbe quella di avere varie CA, tutte gestite dalla medesima organizzazione, tutte aventi la stessa chiave privata di firma usata per firmare i certificati. Qui verrebbero risolti i due problemi sovrascritti, ma se ne introdurrebbe un ulteriore, ovvero l importanza della segretezza dell unica chiave privata. Se venisse scoperta, l intera struttura crollerebbe in poco tempo. Un ulteriore problematica sarebbe la scelta su chi affidare la CA. I candidati più logici sarebbero il governo, le banche, i contabili o gli avvocati. Sfortunatamente nessuno di essi suscita un senso di sicurezza totale per tutti i cittadini, quindi è necessario non avere una singola autorità fidata. Per questi motivi è stato trovato un metodo differente per certificare le chiavi pubbliche le firme digitali, e viene comunemente chiamato PKI (public key infrastructure), infrastruttura a chiave pubblica. Una infrastruttura a chiave pubblica PKI è una installazione informatica costituita da applicazioni che utilizzano tecniche crittografiche con chiavi asimmetriche. Una PKI ha diversi componenti, quali gli utenti, le diverse CA, i certificati e le directory. La funzione della PKI è quella di fornire la struttura necessaria ad inserire ed integrare tutte queste componenti, e definire gli standard da utilizzare per i diversi tipi di documenti e di protocolli. Una PKI è composta di regola da entità distinte: Una Registration Authority, RA, incaricata delle formalità amministrative. Qui è dove formalmente gli utenti si rivolgono per le loro richieste. La RA è anche incaricata di verificare le credenziali del richiedente, prima di rilasciare il certificato.

56 3.4 Infrastruttura a chiave pubblica 56 Una Certificate Authority, CA, incaricata dei compiti tecnici di creazione, validazione e verifica dei certificati digitali. L'autorità di certificazione è anche incaricata della firma delle richieste di certificato da parte di utenti che hanno già la propria chiave pubblica (sigla CSR per Certificate Signing Request 35 ). Ha inoltre per missione la firma delle liste di revoca (CRL per Certificate Revocation List). Un Repository Autority, ovvero l autorità di stoccaggio, la cui missione è quella di conservare in sicurezza i certificati. Una Certificate Management System, il cui compito è quello di garantire l intera struttura e il sistema di gestione dei certificati. Il ruolo dell'infrastruttura di chiavi pubbliche è multiplo e copre soprattutto i seguenti campi : Registrare le richieste di chiavi verificando l'identità dei richiedenti. Generare le coppie di chiavi (chiave privata / chiave pubblica) da utilizzare per una nuova identità digitale richiesta. Garantire la confidenzialità delle chiavi private corrispondenti alle chiavi pubbliche. Certificare l'associazione tra ogni utente e la sua chiave pubblica. Generazione di transazioni informatiche riservate. Emissione e pubblicazione di certificati. Gestione dei registri dei certificati emessi, e delle liste di sospensione e revoca. Revocare le chiavi pubbliche, in caso di perdita da parte del proprietario, di scadenza della data di validità o di compromissione. Gestione di sistemi di autorizzazione, autenticazione e identificazione Altri servizi, come la marcatura temporale dei certificati. 35 Un CSR è fondamentalmente una chiave pubblica che viene generata dall utente sul proprio server, che contiene le informazioni specifiche del proprio sito e della propria organizzazione, ed inviata alla CA.per la registrazione e certificazione

57 3.4.1 Strutturazione delle PKI Strutturazione delle PKI Le diverse PKI esistenti non sono organizzate tutte allo stesso modo al loro interno. Per quanto riguarda le PKI a livello di impresa, la maggior parte di esse sono organizzate in maniera gerarchica, creando una catena di certificati che stabiliscono l identità delle parti coinvolte. La CA di livello più elevato, denominata CA root o radice, certifica le CA di secondo livello, denominate anche Regional Autority, che possano coprire certe determinate regioni geografiche come uno stato o una regione. Queste a loro volta certificano le vere e proprie CA che emettono i certificati X509 alle organizzazioni o ai privati. Si crea quindi una struttura piramidale o ad albero, alla quale tutte le CA coinvolte devono rispettare il proprio livello assegnato. I livelli dell albero non sono per forza tre come in questo caso, ma possono averne anche di più o di meno, in quanto non è stato stabilito uno standard che stabilisce i vari livelli dell albero. Quando la CA radice autorizza una nuova CA regionale, genera un certificato X509 che ne sancisce l avvenuta approvazione. Questo include la sua nuova chiave pubblica da utilizzare, e la firma ufficiale della CA radice. Analogamente quando un autorità regionale approva una nuova CA, produce e firma un certificato che riporta l avvenuta approvazione, contenente la nuova chiave pubblica per essa. Grazie a questa gerarchia di certificazione, si può alleggerire il lavoro delle CA radice che si suppongono fidate, demandando il lavoro ai livelli più bassi dell albero. Un utente o un organizzazione che non fosse pienamente sicuro della veridicità della CA locale, potrebbe risalire la catena di certificati firmati, fino ad arrivare alla CA root, la quale garantirebbe per tutta la struttura, creando una catena di fiducia o percorso di certificazione. I browser moderni contengono al loro interno le chiavi pubbliche di oltre un centinaio di CA radice, le quali vengono chiamate ancore fiduciarie (trust anchors). In questo modo si evita di avere una singola autorità radice unica per tutto il mondo. La scelta su quali ancore affidarsi è quindi lasciata al produttore del browser, però agli utenti è ovviamente concesso di cancellare dalla lista le CA che crede siano sospette.

58 3.4.2 Servizi di directory 58 La struttura gerarchica delle CA non è la sola con la quale vengono organizzate le PKI. Una struttura alternativa è quella della creazione della già citata rete di fiducia, utilizzata dove non è necessaria una garanzia estrema come la struttura gerarchica. Questa organizzazione è basata sull uso di certificati emessi dalle parti stesse e garantiti da terze parti. Questi schemi sono conosciuti come GPG (GNU Privacy Guard) e PGP (Pretty Good Privacy). Una nuova tipologia di PKI che si sta velocemente sviluppando è la Simple Public Key Infrastructure (SPKI), nata per passare la rigidità dello standard X509 e la non perfetta organizzazione della rete di fiducia PGP. La SPKI viene utilizzata per collegare soggetti direttamente alle chiavi, utilizzando un modello locale di fiducia, integrando però anche un sistema di autorizzazione ai servizi Servizi di directory Un altra decisione riguardanti le varie PKI è dove memorizzare i certificati rilasciati, e delle loro catene di fiducia fino ad un ancora fiduciaria. Una possibilità è quella di far memorizzare ad ogni singolo utente il proprio certificato. Questo metodo è sicuro, in quanto gli utenti non possono modificare il certificato data la presenza della firma della CA, però in certe situazioni può non essere il massimo della comodità ed efficienza di prestazioni. Una proposta alternativa sarebbe quella di usare un server DNS 36, cioè il server preposto ad organizzare i computer in domini ed abbinare i nomi degli utenti o host in indirizzi IP, utilizzandolo anche come directory dei certificati. Questa proposta nacque dal fatto che quando un host deve contattarne un altro, deve cercare il suo indirizzo IP usando un DNS; quindi il DNS potrebbe comunicare al richiedente, sia l indirizzo IP del destinatario sia il suo eventuale certificato. Questa idea in teoria sarebbe molto giusta, ma in pratica non del tutto attuabile, perché in questo modo si appesantirebbe non poco il lavoro dei DNS. Alcune PKI quindi sono strutturate con uno specifico directory server dedicato alla gestione dei certificati X509. Soprattutto le PKI a livello di impresa sono 36 Domain Name Server

59 3.4.3 Liste dei certificati revocati 59 spesso strettamente legate ai servizi di directory dell'azienda che offrono servizi di ricerca, in cui la chiave pubblica incorporata in un certificato di ogni dipendente, può essere memorizzata assieme ad altri dettagli personali, come numero di telefono, indirizzo , dipartimento. Oggi la principale tecnologia per i sistemi di directory è un server LDAP, e infatti lo standard X.509 nasce con il predecessore di LDAP, ovvero lo standard X Liste dei certificati revocati Il problema della revoca dei documenti personali di identità esiste come nel mondo reale anche in quello digitale. L autorità che ha emesso un certificato digitale può decidere di revocarlo, se il proprietario ne ha abusato in qualche modo, se è stata persa o intercettata la chiave privata associata, o per altri motivi di primaria importanza. Per fare ciò, ogni CA emette periodicamente una lista contenente i numeri seriali dei certificati revocati, la CRL (Certificate Revocation List). Il metodo più comune utilizzato dalle varie CA per operare con le CRL, consiste nel pubblicare occasionalmente una lista principale dei certificati revocati, ed aggiornare questa molto frequentemente. Questa tecnica permette di ridurre il carico di banda necessario a distribuire le CRL. Le applicazioni invece non possono adottare la stessa tecnica, ovvero scaricare periodicamente la lista di tutti i certificati revocati, perché il traffico sulla rete diventerebbe presto insostenibile. Per questo viene introdotto lo specifico protocollo OCSP (Online Certificate Status Protocol), secondo il quale in tempo reale, un applicazione al momento della verifica del certificato emesso da una CA nota, chiede alla stessa se il numero seriale di quel certificato è stato revocato o no. L introduzione delle CRL porta vantaggi riscontrabili in termini di sicurezza, ma causa quindi anche una serie di svantaggi in termine di comodità. Un altra complicazione deriva dal fatto che un certificato potrebbe anche essere reintegrato nella rete. La gestione della revoca con le CRL toglie in parte una delle migliori proprietà dei certificati, ovvero la possibilità di essere utilizzati senza contattare le CA, però la loro introduzione è indispensabile per un buon livello di sicurezza.

60

61 Capitolo 4 Il servizio di autenticazione centralizzata : CAS Il servizio di autenticazione centralizzata, Central Authentication Service CAS, permette di realizzare un sistema di autenticazione unica, Single Sign On (SSO), tra applicazioni basate su interfaccia web o mail server, per mezzo di ticket di autenticazione. Le applicazioni demandano il problema dell autenticazione al server centrale CAS, senza più preoccuparsi dei vari problemi di identificazione dell utente. L'utente dovrà autenticarsi una sola volta, ad esempio con username e password, o con l invio di un certificato digitale, e da quel momento in poi potrà utilizzare tutte le applicazioni fornite del sistema, senza doversi autenticare nuovamente, finché la sessione è valida. I motivi che portano alla scelta di un architettura di questo tipo sono la sicurezza e la convenienza, in quanto gli utenti devono fare

62 4 Il servizio di autenticazione centralizzata: CAS 62 molto meno perdendo anche meno tempo, e le applicazioni sono protette dal server centrale fidato. CAS fu creato inizialmente come progetto open source dal gruppo Information Tecnology Services (ITS) della Yale Universities 37, e successivamente nel dicembre 2004 divenne un progetto JA-SIG, sempre in cooperazione con Yale e con la Reutgers Universities. È utilizzato da molte università americane ed europee integrando i sistemi di autenticazione preesistenti basati su LDAP o Kerberos. Il sistema CAS è multipiattaforma, dato che il server è implementato su servlet java 38, e può essere eseguito su di un servlet engine, seguendo le specifiche JSP 39 versione 1.2. Le librerie per il server applicativo sono inoltre disponibili per vari linguaggi di sviluppo o anche di scripting, come JAVA, JSP, Perl, PHP, ASP, PL/SQL, Python. Figura 4.1 Esempio di autenticazione distribuita prima e dopo l introduzione di CAS Una servlet è un piccolo programma scritto in linguaggio Java, eseguito in un server web. Operano all'interno di un applicazione server e potenziano le sue funzionalità JavaServer Pages, è una tecnologia Java per lo sviluppo di applicazioni Web che forniscono contenuti dinamici in formato HTML o XML.

63 4.1 Strutturazione del sistema CAS Strutturazione del sistema CAS Il sistema CAS nella sua forma più generale è composto principalmente da tre diverse componenti: Il server CAS centrale Un server applicativo che fornisce un servizio Un cliente utente, che intende accedere al servizio applicativo, solitamente tramite un browser web. Alle volte a queste tre componenti se ne può aggiungere una quarta, negli specifici casi in cui un ulteriore applicazione deve autenticarsi impersonificando l utente vero e proprio. Questa modalità di funzionamento è detta modalità proxy. Il server CAS centrale è il componente preposto all identificazione dell utente, nonché il software che deve gestire una corretta e soprattutto sicura autenticazione. Il software e tutte le sue librerie server vengono installate e configurate su di un web server come Apache Tomcat 40, che utilizzi il protocollo HTTP 41 e HTTPS 42. Il server applicativo invece è una qualsiasi risorsa o servizio web-based, o una qualsiasi interfaccia web, che utilizzi anch essa i protocolli HTTP o HTTPS, sul quale devono essere installate specifiche librerie CAS, apposite per le applicazioni. Queste applicazioni che utilizzano il meccanismo di autenticazione proprio del CAS, vengono chiamate CAS-ifyed. Il client utente o semplicemente l utente, è il soggetto che intende accedere ai servizi del server applicativo, solitamente tramite un browser web. Per una configurazione ottimale, il browser dell utente dovrebbe aver abilitato i cookie 43 e i redirect Javascript 44, anche se questa configurazione non è strettamente necessaria per un corretto funzionamento del sistema CAS L'Hypertext Transfer Protocol (HTTP) è il protocollo di trasferimento per un ipertesto usato come principale sistema per la trasmissione di informazioni sul web L'Hypertext Transfer Protocol over Secure Socket Layer (HTTPS) è il risultato dell'applicazione di un protocollo di crittografia asimmetrica al protocollo di trasferimento di ipertesti HTTP. 43 Un cookie HTTP è un piccolo file creato da un server web visitato, e viene utilizzato per memorizzare informazioni all'interno del proprio computer. dei cookie 44 Attraverso il redirect è possibile inoltrare le visite di un sito web verso un altro sito web senza che l'utente se ne accorga. Questi vengono scritti in Javascript ed eseguiti automaticamente nei browser web.

64 4.2 Caratteristiche di CAS Caratteristiche di CAS Il CAS fornisce un sistema in SSO basato su di un protocollo aperto e ben documentato. È dotato di un componente server Java open source e dispone di una buona documentazione e soprattutto di una vasta comunità di sviluppatori. Gli scopi principali del server CAS sono: Facilitare l autenticazione centralizzata SSO per più applicazioni comuni. Semplificare la procedura stessa di autenticazione Consentire un autenticazione sicura agli utenti, senza che questi debbano rivelare le proprie credenziali ai servizi e agli applicativi ogni volta. Le caratteristiche migliori del sistema CAS sono sicurezza, affidabilità, flessibilità. La sicurezza dell intero sistema risulta notevolmente rafforzata, utilizzando i meccanismi di CAS. Infatti per l intero ciclo di autenticazione, le credenziali dell utente viaggiano solo una volta tra il browser dell utente ed il server, e su di un canale protetto e crittografato SSL. Durante l autenticazione, il server CAS cerca di salvare nel browser dell utente uno speciale cookie privato: il Ticket Granting Cookie, TGS. Questo non contiene nessun tipo di dato confidenziale, per questo viene denominato opaco, ma contiene solamente un identificativo di sessione noto al CAS. Transita sulla rete in chiaro senza protezione, ma solo il CAS può leggerlo o scriverlo. Il ticket ha comunque un tempo di vita relativamente breve, e viene cancellato definitivamente alla chiusura del browser da parte dell utente. Questo speciale ticket, serve come garanzia di già avvenuta autenticazione, qualora l utente intenda accedere ad un'altra applicazione del sistema. In questo modo l utente in tutta trasparenza non deve re autenticarsi ogni volta che cambia il servizio applicativo richiesto. Le applicazioni invece non comunicano attraverso il ticket TGT, ma attraverso altri ticket appositi, detti Service Ticket, ST. Anch essi sono opachi, non contenendo informazioni personali, e possono essere utilizzati solo una volta (one time ticket). Il ST viene emesso dal server CAS verso l utente, il quale in modo automatico lo passa al servizio applicativo. Questi lo ridirige di nuovo verso il CAS per confermare l identità dell utente, chiudendo il ciclo di autenticazione.

65 4.2 Caratteristiche di CAS 65 Per quanto riguarda la flessibilità, nel pacchetto software che costituisce il server CAS sono comprese tutte le funzionalità per la una corretta gestione del suo protocollo. Invece la procedura che verifica l identità dell utente è lasciata completamente allo sviluppatore, garantendogli una notevole libertà di scelta su come adattare il server ai propri meccanismi di autenticazione locale, tramite plugin 45 per un Database relazionale, un server LDAP, certificati X509, semplici file di testo protetti da password, o anche una combinazione di questi impostando una scala di priorità da seguire. Inoltre i plugin possono essere estesi per gestire meccanismi già esistenti come Kerberos o Active Directory 46 (AD). Per questo sono disponibili varie librerie di sistema, con le quali lo sviluppatore può interfacciare il server CAS con il metodo di autenticazione da lui preferito. Figura 4.2 Esempi di plugin di autenticazione per CAS 45 Software che interagisce con un altro software per ampliarne le funzioni Active Directory è un insieme di servizi di rete che implementano un servizio di directory.

66 4.2 Caratteristiche di CAS 66 Anche l affidabilità del servizio offerto dal CAS è molto alta. È possibile configurare anche il server applicativo sul quale è installato CAS, per garantire un affidabilità ancora più elevata. Per questo le librerie client e server sono in continua crescita, per ridurre i difetti ed ottimizzare il codice su ogni piattaforma. Un'altra peculiarità del CAS è il suo possibile uso in modalità Proxy. Un proxy è un servizio, che a sua volta deve impersonare un utente autenticandosi su altri Servizi. Questa modalità è stata introdotta con la seconda versione di CAS, perché in generale in un sistema SSO non si dovrebbe limitare solamente ad un autenticazione diretta tra un client ed un server, ma a volte coinvolgendo una terza parte. Per esempio un servizio interpellato da un utente potrebbe dover contattare un altro servizio back-end 47, o utilizzando un portale 48, l utente autenticato avrebbe la necessità di interrogare un applicazione esterna. Questi sistemi terzi quindi devono a loro volta poter identificare l utente, e non sarebbe ovviamente ne saggio ne comodo reinviare a questi le credenziali personali dell utente per identificarlo. Per questo il server CAS permette l utilizzo di speciali ticket per questa modalità, chiamati Proxy Garantig Ticket, PGT. Questi permettono un autenticazione sicura su applicazioni terze, garantendo a queste l identità dell utente. Rispetto ad un normale sistema SSO, il CAS ha inoltre delle caratteristiche specifiche. Le comunicazioni tra client e server, e tra server centrale e applicativo, viaggiano tutte sul protocollo protetto HTTPS, e vengono utilizzati solamente i certificati digitali generati e gestiti dalla CA specificata all interno della configurazione del server CAS centrale. Questi due aspetti contribuiscono a una doppia sicurezza: le comunicazioni sono crittografate e riservate, e l identità dei soggetti è garantita. Gestendo i certificati digitali in modo centralizzato, è quindi possibile creare un infrastruttura a chiave pubblica interna e locale. 47 Service che accetta credenziali proxied ossia autenticazione da un proxy. 48 Un portale è un sito web che costituisce il punto di ingresso a un insieme di risorse o servizi. È una porta privilegiata che un utente attraversa per entrare in una comunità: un azienda, un'università, una rete sociale.

67 4.3 Schemi di funzionamento di CAS Schemi di funzionamento di CAS Il server CAS può essere utilizzato in due modalità: Modalità diretta Modalità Proxy La modalità diretta è quella nata e pensata fin dalla prima versione del CAS, dove vi è un tentativo di autenticazione diretta da parte dell utente verso il CAS. La modalità proxy fu introdotta nella seconda versione del sistema CAS, e permette l autenticazione su più livelli, ovvero tramite proxy. Questa funzionalità permette di accedere ad una applicazione remota utilizzando le stesse credenziali presentate dall utente al sistema di autenticazione, agendo come client per conto dello stesso Funzionamento di CAS in modalità diretta Questo schema di funzionamento non prevede terze parti nel sistema, e viene attivata nel momento in cui un utente tramite browser, cerca di accedere ad un servizio applicativo la cui autenticazione è gestita dal CAS. Questa è la richiesta iniziale [1a]. Il server applicativo rimanda l utente alla pagina di login del server CAS, [1b], tramite connessione sicura HTTPS, passando come parametro aggiuntivo l URL dell applicazione richiesta. Il CAS chiede all utente che gli vengano fornite le sue credenziali, tramite la relativa form di autenticazione o tramite l invio automatico del certificato digitale utente, se disponibile. Queste vengono controllate e verificate nel passo [2], con il servizio di autenticazione scelto, LDAP in questo caso. Tutte le comunicazioni tra utente e server CAS passano attraverso un canale SSL sicuro e crittografato. Se l autenticazione non ha avuto successo verrà visualizzato un opportuno messaggio contenente l errore ottenuto, come nome utente o password incorretti, e l utente non avrà accesso al servizio. In caso invece di autenticazione avvenuta, l utente viene ridiretto automaticamente all applicazione richiesta [3], appendendo però

68 4.3.1 Funzionamento di CAS in modalità diretta 68 all'url di redirezione un ticket, chiamato service ticket (ST), sotto forma di una lunga stringa alfanumerica. Questo ticket serve per indicare che l utente ha eseguito correttamente l autenticazione, e richiesto quella specifica applicazione. Infatti il server CAS nel momento in cui verifica le credenziali dell utente, prende anche nota del servizio da lui richiesto, così da associare al ticket stesso, il nome dell utente e il servizio richiesto. Il service ticket è utilizzabile una sola volta, ed invalidato non appena utilizzato. Inoltre il CAS cerca di salvare nel browser dell utente un cookie, il Ticket Granting Cookie (TGC) valido per la sessione globale, ed eliminato automaticamente dopo un intervallo di tempo o dopo la chiusura del browser stesso. Questo meccanismo permette di identificare l utente senza doversi riautenticare, nel caso in cui questi richiedesse di accedere ad un'altra applicazione del sistema, implementando quindi la tecnica del SSO. A questo punto l'applicazione richiamata dall'utente, verifica se il service ticket passatogli dal browser utente sia corretto, tramite una comunicazione protetta HTTPS con il server CAS (passo [4]). Il server CAS controlla che il ticket inviatogli dall applicazione sia valido e associato allo stesso servizio richiesto, dopodiché se la validazione ha successo, viene restituito al chiamante il nome utente. A questo punto l applicazione è sicura dell identità dichiarata dell utente, e può procedere nella propria comunicazione con esso, chiudendo di fatto il ciclo di autenticazione. L annullamento della sessione globale può essere eseguita semplicemente accedendo alla pagina di logout del server CAS. Questa non farà altro che eliminare il cookie TGC. Altrimenti questo viene annullato automaticamente alla chiusura del briose da parte dell utente, oppure dopo un intervallo temporale di circa un ora. Utilizzando una metodologia di autenticazione come questa, l utente ha un grado di sicurezza molto elevato, infatti le proprie credenziali hanno viaggiato sulla rete solo una volta in tutto il ciclo di autenticazione, peraltro su un canale sicuro. Inoltre le applicazioni sono completamente trasparenti, infatti l identificazione ad esse è basata su ticket opachi non contenenti ne le credenziali utente ne informazioni riservate. Oltre a ciò anche le reautenticazioni seguenti vengono affrontate in maniera efficace, se l utente aveva precedentemente accettato il cookie TGC: al momento di

69 4.3.1 Funzionamento di CAS in modalità diretta 69 una richiesta di un nuovo servizio applicativo, non vedendo un ticket ST valido, rimanderà l utente al server CAS. Questi leggendo il cookie TGC riconoscerà automaticamente l utente e la sua sessione attiva, quindi creerà per esso un nuovo ticket ST specifico per il nuovo servizio, il tutto in modo completamente trasparente all utente. La figura 4.3 mostra uno schema di autenticazione per questa modalità. Figura 4.3 Schema di autenticazione CAS in modalità diretta.

70 4.3.2 Funzionamento di CAS in modalità proxy Funzionamento di CAS in modalità proxy Gli sviluppatori di CAS a Yale hanno pensato di introdurre nella versione 2.0 alcune nuove caratteristiche tra le quali la possibilità di sviluppare una applicativo proxy e su più livelli detta anche multitier 49, restando però compatibile con la versione precedente. Questa modalità, detta anche di tipo CAS-proxy, è necessaria quando un'applicazione deve fare le veci di qualcun'altro (un utente o un'altra applicazione) nell'autenticazione, cioè essa stessa deve autenticarsi su di un'altra applicazione impersonificando un utente. Un tipico esempio nel quale è necessario un meccanismo di questo tipo è un applicazione webmail in un sistema in SSO. L'utente si autenticherà tramite CAS, e accederà poi a webmail essendosi già autenticato. Questa applicazione però dovrà collegarsi al server IMAP 50 della posta per poterla leggere, facendo quindi le veci dell'utente. Per un corretto funzionamenti di questa modalità è necessario introdurre tre ulteriori tipologie di ticket, oltre ai già noti ticket TGC e ST: Proxy-granting ticket (PGT): è un ticket mandato dal Server CAS ad una applicazione in possesso di un ticket ST valido, associato al singolo utente e a quella determinata applicazione. Conferisce a questa il permesso di richiedere dei proxy-ticket (PT), diventando di fatto un Proxy. Proxy-granting ticket IOU (PGTIOU): è un ticket mandato dal Server CAS durante il processo di validazione tra CAS e Proxy, insieme a un PGT. Il proxy ha il compito di gestire una tabella che correli i ticket PGTIOU e PGT. Proxy ticket (PT): è un ticket utilizzabile da un proxy per accedere ad una applicazione esterna impersonando l utente. Un ticket PT identifica il proxy o la catena di Proxy che hanno richiesto l'autenticazione al servizio esterno, infatti, dato che questo è un meccanismo riproducibile a catena, un PT può essere utilizzato da altri proxy per ottenere a sua volta un PGT. Viene inoltre conservata una traccia della catena di proxy, cioè del percorso di autenticazione, tra l'utente e applicazione esterna finale Un server IMAP e il server a cui un client di posta elettronica si collega per scaricare la posta.

71 4.3.2 Funzionamento di CAS in modalità proxy 71 Il funzionamento di CAS in versione proxy, è analogo alla modalità diretto fino al passo [4]. Su richiesta dell applicazione, il server CAS fornisce un elemento aggiuntivo nella comunicazione in formato XML [5], un ticket PGTIOU. Questo è un valore identificativo con cui è indicizzato il corrispondente PGT, il Proxy Granting Ticket, che viene creato dal server CAS. Il PGT viene quindi trasmesso [5] al server proxy, insieme al corrispondente PGTIOU. Questa comunicazione è protetta tramite un canale SSL, utilizzando i certificati digitali dei due server, che devono essere opportunamente installati, per garantire la segretezza del PGT. Questo tipo di comunicazione è necessaria anche per garantire a ciascuna delle due controparti, CAS server e proxy server, l'identità dell'altra, realizzando una mutua autenticazione, in un modo semplice e funzionale. Il PGT viene memorizzato autonomamente, e mappato al PGTIOU dal servizio proxy per usarlo successivamente. Il PGT permette infatti al proxy di richiedere, anche più volte, dei Proxy Ticket PT, tramite i quali può impersonificare l utente alla specifica applicazione web richiesta. Infatti un ticket PGT è legato ad un utente, ad un proxy e a più servizi applicativi, mentre un ticket PT è legato ad un utente, ad un proxy e ad un servizio applicativo specifico, e può essere utilizzato una sola volta. A questo punto quindi il proxy ha bisogno del ticket PT associato all applicazione web nella quale deve impersonificare l utente: questo viene richiesto al server CAS nel passo [6a] attraverso una comunicazione HTTPS, passando come parametro il ticket PGT ed il servizio di destinazione. Il server CAS vede questa richiesta, verifica la validità del PGT, genera il PT richiesto, e lo spedisce al proxy ([6b]). Il server proxy può ora quindi comunicare questo PT all applicazione che intende utilizzare [7], nelle stesse modalità in cui il browser dell'utente si collega con un servizio applicativo nel funzionamento diretto. A sua volta il servizio verifica il PT comunicando in HTTPS con il server CAS [8a], mandando come argomenti il suo ID di servizio e il PT, ottenendo come risposta [8b] l'username dell'utente autenticato e la traccia della catena dei proxy coinvolti, se ovviamente il PT è valido. Il Target può inoltre decidere, alla luce di questi dati, come e se dare accesso al Proxy, e procedere come più opportuno.

72 4.3.2 Funzionamento di CAS in modalità proxy 72 Figura 4.4 Schema di autenticazione CAS in modalità proxy Questo meccanismo di autenticazione può ripetere il ciclo più volte secondo le necessità, concedendo alle stesse applicazioni web il potere di autenticarsi come l'utente comunicando con altre applicazioni, in una catena di proxy. Figura 4.5 Catena di autenticazione tramite proxy

73 4.4.1 Limitazioni di CAS nelle versioni 1 e La versione 3 del server CAS La terza versione del server CAS non introduce una nuova metodologia di autenticazione o una nuova modalità di funzionamento, bensì è stata sviluppata per superare alcune limitazioni delle precedenti versioni risolvendo anche alcuni dei loro bug, integrare nuove specifiche funzionalità per rimanere al passo coi tempi, cercando quindi di restare un sistema di autenticazione centralizzata all avanguardia, ed ovviamente rimanere comunque compatibile all indietro con le due precedenti versioni Limitazioni di CAS nelle versioni 1 e 2 La più grande limitazione del sistema CAS fino all introduzione della terza versione è quella di non fornire alle applicazioni informazioni sull'utente riguardanti l'autorizzazione. Infatti fu progettato per realizzare solo un sistema di autenticazione e l'unico dato disponibile è il nome univoco dell utente. Per alcune applicazioni è indispensabile avere a disposizione i dati degli utenti, ad esempio nome, cognome, numero di matricola per gli studenti o codice identificativo per i dipendenti, facoltà, o altri dati anagrafici, quindi in questi casi né la versione 1 né la 2 di CAS sembrano la scelta più appropriata. Un altro limite nella seconda versione del server CAS sta nella gestione dei server che si autenticano in modalità proxy. La configurazione avviene a livello di rete (firewall) e a livello di Certification Authority, ma una volta generati e configurati i certificati per i server coinvolti, il sistema CAS non ha un controllo diretto su quali server possono accedere alla catena di autenticazione, in che modalità, o revocare l'autorizzazione a operare. Un ulteriore difficoltà nello sviluppo del server CAS 2, sta nell organizzazione e strutturazione del codice sorgente: questo è intessuto dentro le servlet, e non è perfettamente organizzato secondo un modello di dominio chiaro e ben strutturato. Tutto questo porta ad avere difficoltà tra i vari sviluppatori al momento di

74 4.4.2 CAS 3 74 apportare modifiche al codice, problema non da poco quando si parla dello sviluppo di un software per la sicurezza come questo. Inoltre l'interfaccia del server CAS nelle versioni 1 e 2 non sono multilingua, e per personalizzarle è necessario intervenire direttamente sul codice JSP. Infine il server CAS non è predisposto per il controllo della scadenza della password. Non viene né mostrato alcun avvertimento in tal senso, né bloccato l'ingresso all'utente. Purtroppo questa funzionalità non è ancora stata introdotta nella terza versione del CAS, e sarà uno degli argomenti principali nella descrizione delle attività svolte in questo progetto di tesi CAS 3 Gli obbiettivi del CAS 3 furono quindi superare i limiti intrinsechi dei precedenti sistemi, definire un ben preciso modello di dominio sfruttando le tecniche dell ingegneria del software, implementare un architettura software moderna, di facile modifica e sviluppo, personalizzabile dall utente senza stravolgere l intero sistema, ed ovviamente compatibile con i suoi due predecessori. Con l introduzione della nuova terza versione di CAS, alcuni limiti delle precedenti versioni sono stati superati. Innanzitutto il sistema può ora fornire alle applicazioni informazioni sull'utente, permettendo a queste di poter gestire direttamente e autonomamente i vari permessi utente di autorizzazione. È migliorato quindi il controllo sull'autorizzazione delle applicazioni e reso più granulare, ad esempio quali servizi possono contattare CAS, quali funzionalità possono sfruttare, e quali attributi dell'utente possono essere visti. Vengono supportate inoltre nuove metodologie di autenticazione, come SAML per l'integrazione con Google Accounts 52, e per Shibboleth. Quest ultimo è un progetto inter-universitario volto a sviluppare una soluzione open source che 51 Security Assertion Markup Language (SAML) è uno standard informatico per lo scambio di dati di autenticazione e autorizzazione tra domini di sicurezza distinti. 52

75 4.5 Valutazioni sull uso di CAS 75 consenta alle organizzazioni lo scambio di informazioni sui propri utenti, in modo sicuro e rispettoso della privacy, basandosi sul protocollo SAML. L interfaccia web è stata notevolmente migliorata soprattutto graficamente e nella gestione degli eventuali errori, rendendola inoltre multilingua. Infine il codice dell'applicazione CAS è stato riscritto basandosi sull'architettura Spring 53, un framework opensource per lo sviluppo di applicazioni su piattaforma Java che è stato largamente riconosciuto all'interno della comunità Java quale valida alternativa al modello basato su Enterprise JavaBeans 54 (EJB). Rispetto a quest'ultimo, il framework Spring lascia una maggiore libertà al programmatore fornendo allo stesso tempo un'ampia e ben documentata gamma di soluzioni semplici adatte alle problematiche più comuni. 4.5 Valutazioni sull uso di CAS Il sistema CAS è un buon sistema di autenticazione, mentre per quanto riguarda le politiche di autorizzazione ancora non si è raggiunto un livello di qualità eccezionale. In effetti, è prassi utilizzare CAS in combinazione con un directory server in cui sono censite sia le identità degli utenti che i ruoli assegnati, tuttavia è responsabilità di ogni singola applicazione connettersi alla directory per accedere al profilo dell utente e quindi applicare le dovute policy. Per quanto riguarda l autenticazione invece il sistema affronta il problema con standard di qualità molto elevati. Infatti Le password passano solo attraverso il browser e il server CAS attraverso un canale dati sicuro e cifrato, e le identificazioni successive avvengono per mezzo di ticket opachi inviati in chiaro. L applicazione non entra mai in contatto con la password in transito sulla rete, e questo è probabilmente il più grande vantaggio usando il sistema CAS. Notare inoltre che non è strettamente necessario implementare meccanismi di crittografia sul transito in rete dei ticket, in quanto questi ultimi hanno validità per

76 4.5 Valutazioni sull uso di CAS 76 un solo tentativo e comunque dei limiti temporali di validità. È invece importante che il servizio Web validi il ticket presentandolo al CAS server utilizzando il protocollo cifrato HTTPS: se qualcuno fosse in grado di fare un attacco di tipo Man In The Middle, potrebbe banalmente fingere risposte valide indipendentemente dal ticket presentato dal servizio Web, o per contro fornire risposte non positive a fronte di ticket validi, creando di fatto un disservizio. Inoltre se l'utente avesse necessità di autenticarsi su un altro applicativo Web, quello che succederebbe è ancora un redirect verso il CAS server che, in virtù del proprio cookie, lo riconosce immediatamente e non gli chiede username e password. Di fatto, l'utente viene rediretto al secondo applicativo Web con un nuovo ticket temporaneo, che verrà validato come nello schema descritto. Un ulteriore qualità di questo protocollo risiede nella possibilità di utilizzare qualsiasi datasource per la gestione degli utenti. Può essere usato un DBMS, Active Directory, un servizio LDAP, un file XML. Il controllo può essere anche effettuato su più datasource ordinati per priorità: ad esempio è possibile controllare le credenziali dell utente prima sulla base di dati, e in caso questi non sia presente, controllare sul server LDAP.

77 Capitolo 5 Integrazione del sistema CAS nell Università di Parma Come la maggior parte delle organizzazioni, anche l'università di Parma ha un sistema centralizzato di autenticazione di utenti e gruppi, tramite il quale controlla gli accessi alle risorse e alle applicazioni web. L università di Parma offre numerosi servizi via Web agli utenti, la maggior parte gestiti dal S.I.T.I., Settore Innovazione tecnologie informatiche, ex centro di calcolo elettronico. Buona parte di essi sono protetti, e per potervi accedere, è indispensabile eseguire correttamente un autenticazione al server dell Università. Il sistema CAS quindi è perfetto per un uso di questo tipo: sicurezza delle transazioni, affidabilità, open source e di libero sviluppo, e soprattutto centralizzazione del servizio di autenticazione, così da permettere a tutti gli utenti tutti i vantaggi di un sistema SSO.

78 5 Integrazione del sistema CAS nell Università di Parma 78 Attualmente il server CAS è correttamente installato e configurato come server principale di autenticazione dell Università, ma l unica metodologia attiva finora di autenticazione e invio delle credenziali è quella tramite username e password. Figura 5.1 Finestra di autenticazione CAS dell Università di Parma Essendo l autenticazione basata sul protocollo CAS, questa può essere considerata sicura ed efficiente, però rimane l unica metodologia disponibile per accedere ai servizi offerti dall Università. Il sistema attuale quindi non è predisposto per accettare un certificato digitale come metodo di identificazione e autenticazione. Inoltre non è ancora disponibile un servizio di gestione automatico della scadenza password per gli account utente, e delle relative problematiche associate, sistema che garantirebbe un ulteriore passo in avanti nella sicurezza.

79 5.1 Strutturazione del servizio CAS nell Università di Parma Strutturazione del servizio CAS nell Università di Parma L Università di Parma ha scelto di affidarsi al sistema CAS come servizio di autenticazione centrale, che come già citato affronta il problema in maniera efficiente e quasi ottimale. Essendo il sistema CAS basato su servlet java, necessita di un servlet engine per poter funzionare correttamente. Il server Apache Tomcat versione 6 è il servizio preposto a questo scopo: Apache Tomcat è un web servlet container, cioè un server su cui far girare Servlet e pagine JSP, open source e sviluppato dalla Apache Software Fondation. Implementa le specifiche JSP e Servlet di Sun Microsystems 55, fornendo una piattaforma per l'esecuzione di applicazioni web sviluppate nel linguaggio java. Per procedere all installazione del Jasig-CAS è quindi necessario avere installato e configurato correttamente: Una Java Virtual Machine compatibile con Java 6 Java 2 Platform Standard Edition 1.5 per gestire la JVM Apache Tomcat 6.0.X Il software Maven2 56 Un sistema per la gestione utenti o servizio di directory (Database,LDAP, ecc) Le prime tre componenti specificate sono necessarie per una installazione e configurazione di base senza modifiche al codice sorgente del software CAS. La quarta componente è strettamente necessaria in fase di compilazione dell intero pacchetto software Java, a fronte di cambiamenti al codice sorgente o

80 5.1 Strutturazione del servizio CAS nell Università di Parma 80 dei file di configurazione del server CAS. Infatti Maven2 è un software per la gestione e compilazione dei progetti Java. Una Java Virtual Machine compatibile con Java 6 è necessaria per il funzionamento dell intero sistema. Infatti le versioni precedenti di Java non supportano adeguatamente tutte le funzionalità dell intera infrastruttura necessaria al funzionamento del protocollo CAS. La quinta componente può essere invece considerata come una parte integrante del sistema CAS. Come già discusso, CAS lascia libero spazio alla parte di autenticazione detta locale, ovvero, come le credenziali passate dall utente vengono verificate sul sistema di gestione interno degli utenti. Il sistema adottato dall Università di Parma è un server LDAP (Lightweight Directory Access Protocol), standard molto diffuso soprattutto in ambito universitario. Infatti il plugin ufficiale del server CAS che utilizza LDAP come sua parte integrante, oltre ad essere supportato ufficialmente dal sistema, è anche uno dei metodi più adottati e consigliati dagli sviluppatori stessi, con numerosi esempi di configurazione, data la sua versatilità, efficienza, e diffusione su scala mondiale. Per quanto riguarda le politiche di autorizzazione, anch esse sono gestite dal server LDAP. Infatti il sistema CAS installato gestisce solamente la parte relativa all identificazione e autenticazione utente. Quali servizi sono concessi all utente autenticato vengono gestiti direttamente dall applicazione e da LDAP, attraverso una serie di attribuiti specifici opportunamente settati. Per esempio ad un docente verrà concesso il permesso di inserire documenti o eliminarli su Campus Net, invece ad uno studente verrà concesso solamente il permesso di leggerli.

81 5.2 Il server LDAP: Lightweight Directory Access Protocol Il server LDAP: Lightweight Directory Access Protocol Il servizio LDAP è un insieme di protocolli standard per l'interrogazione e la modifica dei servizi di directory. Un servizio di directory consente di dare dei nomi a degli oggetti e di associare agli oggetti degli attributi. È basato su standard X.500 per la condivisione della directory, ma è meno complesso e richiede meno risorse. L'informazione all'interno di una directory LDAP è organizzata in elementi chiamati entry. Nella struttura ad albero, a ogni livello esiste un Relative distinguished name (RDN) che lo identifica (ad esempio ou=studente). L'unione di tutti i RDN, presi in successione dal nodo foglia fino alla radice, costituisce il Distinguished Name (DN), una stringa che rappresenta univocamente una entry nella directory. Ciascuna entry ha una serie di attributi, costituiti dall'associazione attributo valore: ognuno degli attributi dell'elemento è definito come membro di una classe di oggetti, raggruppati in uno schema. Ogni elemento nella directory è associato a una o più classi di oggetti, che definiscono se un attributo sia opzionale o meno e che tipo di informazioni questo contenga. LDAP può essere utilizzato come server di autenticazione locale, nonché come supporto per il processo di autorizzazione dell utenza. La possibilità di definire attributi quali username, password, certificati, risorse, ecc. in una struttura dati gerarchica e di facile accesso offre diverse alternative di implementazione. Può essere ovviamente usato per accedere a informazioni condivise in rete, attraverso un modello client-server offrendo le opportune funzionalità attraverso specifiche funzioni: Connessione -> open(), bind(), unbind() Ricerca di oggetti -> search() Confronto di attributi -> compare() Modifica degli oggetti -> add(), modify(), delete() Operazioni sui nomi -> modifydn()

82 5.3 Integrazione di LDAP nel sistema CAS Integrazione di LDAP nel sistema CAS Il servizio di autenticazione centralizzata CAS si integra alla perfezione con il repository LDAP, il quale gestisce tutti gli utenti dell intero ateneo e contiene tutte le informazioni relative ad essi. In questo paragrafo si entra quindi nel dettaglio per quanto riguarda il passo [2], relativo alle metodologie di autenticazione di un server CAS sia in modalità diretta che tramite proxy. Il processo di ricerca e verifica delle credenziali utente interno tra i due sistemi, viene effettuato attraverso vari passi, dopodiché il protocollo continuerà in base alla risposta ottenuta, secondo le modalità già affrontate. Il metodo generale di autenticazione via web tramite username e password ad un server CAS integrato con un servizio LDAP, lavora in questo modo: 1. L utente tramite browser richiede un servizio per il quale è necessaria l autenticazione, gestita da CAS 2. Il servizio ridirige l utente alla pagina principale del CAS contenente la form di autenticazione tramite username e password. 3. L utente riempie i campi della form, ed invia la richiesta. 4. Il server CAS ora è in possesso delle credenziali utente. Si connette quindi al server LDAP, e successivamente fa una ricerca su di esso, verificando se il campo username introdotto fa riferimento ad uno degli account esistenti. 5. Nel caso in cui la entry relativa venga trovata, CAS cerca di fare un binding, ovvero un collegamento, tra la password del relativo account trovata sul server LDAP, e la password specificata dall utente nella form precedente. 6. Nel caso in cui il binding del passo 5 sia andato a buon fine, le credenziali utente proposte sono corrette, quindi l autenticazione può procedere secondo il protocollo di CAS, con l invio degli appositi ticket. Invece se il binding del passo 5 non è andato a buon fine, il processo di autenticazione si arresta, e viene riproposta all utente la form di autenticazione e un messaggio relativo all errore ottenuto.

83 Capitolo 6 Problematiche affrontate: miglioramento del servizio di Autenticazione. Il servizio attuale di autenticazione dell Università di Parma attraverso CAS può essere considerato efficiente e relativamente sicuro, tuttavia può essere migliorato. Gli scenari dei vari miglioramenti possibili possono riguardare sia la fase di autenticazione, ma anche altri campi come per esempio le politiche di autorizzazione. Questi due concetti sono differenti, ma possono essere legati tra loro. Infatti l Ateneo si sta programmando per introdurre il sistema di autenticazione e autorizzazione tramite Shibboleth. Shibboleth è una iniziativa inter-universitaria che si pone come obbiettivo quello di sviluppare una soluzione che consenta alle organizzazioni lo scambio di informazioni dei propri utenti in modo sicuro. Cerca infatti di semplificare il problema dell'accesso ai contenuti didattici riservati fra più campus universitari,

84 6 Problematiche affrontate: miglioramento del servizio di Autenticazione 84 ciascuno dei quali avente una differente metodologia di autenticazione, permettendo quindi lo scambio di informazioni per determinare le politiche di autorizzazione relative alle diverse tipologie degli utenti associati. Visto che il sistema Shibboleth, supporta pienamente CAS come tecnologia di autenticazione, l integrazione di questi due sistemi può portare ad un netto miglioramento dell intera infrastruttura web universitaria, tuttavia possono essere studiati approfonditamente anche in maniera separata. Il progetto affrontato in questo lavoro di tesi quindi si è posto come obbiettivo quello di studiare approfonditamente le differenti tecniche di autenticazione e delle relative problematiche associate, valutando i principali vantaggi e svantaggi di ogni tecnica, ponendo come presupposto principale il tema della sicurezza, e cercando di sfruttare queste conoscenze per migliorare il sistema di autenticazione CAS dell Università di Parma Attualmente l unica metodologia di autenticazione offerta dall Ateneo di Parma ai propri utenti, è tramite l invio delle credenziali sotto forma di username e password. Anche se il protocollo CAS è sicuro, per i temi qui sviluppati, questa forma di autenticazione non è la migliore per quanto riguarda l aspetto della sicurezza. Verranno quindi proposti due miglioramenti al servizio di autenticazione CAS. Il primo avrà lo scopo di integrare un sistema per la gestione della scadenza password degli account locali dell Ateneo salvati su LDAP, configurando il server CAS per verificare oltre al normale controllo delle credenziali utente tramite username e password, che quest ultima non sia scaduta o in fase di scadenza, oppure che l intero account utente non sia stato bloccato dall amministratore del sistema. Con l introduzione di un servizio che imponga un cambio password periodico, si avrà una maggiore sicurezza per quanto riguarda gli account, perché le password più vecchie sono in generale le più insicure. Il secondo miglioramento invece può essere considerato di maggiore innovazione, in quanto dato il continuo sviluppo della tecnologia dei certificati digitali, il servizio CAS verrà configurato per l accettazione dei certificati digitali tipo X509 in fase di autenticazione, portando quindi alla creazione di un infrastruttura a chiave pubblica gestita dall Università di Parma.

85 6.1 Scelte Progettuali Scelte progettuali Il servizio verrà configurato per permettere l autenticazione tramite certificati digitali solamente gli utenti registrati all Ateneo sul server LDAP. Questo fatto potrebbe andare in controtendenza con l idea che sta alla base dei certificati digitali, ovvero autenticare qualsiasi soggetto che presenti un certificato valido rilasciato da una Certification Autority fidata. Qui però entrano in gioco ulteriori scenari, relativi non più alla singola fase di autenticazione, ma anche alle politiche di autorizzazione. Infatti decidere se autenticare o meno un utente esterno considerato fidato, è totalmente differente rispetto alla decisione di cosa permettergli di fare. Però dato che l obbiettivo principale di questo progetto è stato quello di migliorare la sicurezza di autenticazione locale degli utenti dell Università di Parma, si è scelto di configurare il CAS per accettare solamente gli utenti dell Ateneo che avranno registrato appositamente il proprio certificato digitale sul server LDAP. Questa scelta può essere considerata più o meno discutibile, ma per gli obbiettivi di sicurezza prefissati è stata valutata come la politica migliore. Tuttavia questo scenario non è assolutamente una costrizione. Infatti il sistema CAS può essere perfettamente configurato per considerare un utente come autenticato senza che questi debba per forza possedere un account sul sistema di gestione locale come in questo caso. Come già riportato infatti CAS demanda i permessi di autorizzazione relativi all utente autenticato a qualcun altro. Quindi integrando questo tipo di servizio con il sistema Shibboleth sarà perciò possibile decidere di autenticare tramite il protocollo CAS, utenti appartenenti ad altre organizzazioni come per esempio docenti di altre Università, a patto ovviamente che questi presentino un certificato digitale valido rilasciato da un CA ritenuta fidata. Il servizio Shibboleth invece si preoccuperà di gestire i vari permessi che questi utenti esterni potranno avere.

86 6.2 Installazione componenti Installazione componenti Questo paragrafo descrive le specifiche di installazione e configurazione per l innesto di un servizio CAS in un contesto universitario. Il sistema installato è il CAS versione 3.3.2, e configurato su una macchina linux con kernel Ubuntu distribuzione 8.0.4, Apache Tomcat versione , e una Java Virtual Machine JVM compatibile con Java 6. Infatti alcune utility di Java 5 necessarie per una corretta gestione dei certificati X509 non sono compatibili né con questa distribuzione Ubuntu né col server Apache Tomcat qui utilizzati. Prima di procedere all installazione e configurazione del server CAS è necessario avere sulla macchina alcune componenti fondamentali. La prima di queste è la Java Virtual Machine con Java 6. Per installarla è sufficiente eseguire da shell il comando: sudo apt-get install sun-java6-jdk Successivamente viene settata la variabile di ambiente globale JAVA_HOME, digitando da terminale il comando: sudo gedit ~/etc/profile ed editando il file profile appena aperto, aggiungendo due linee che dichiareranno la variabile di ambiente da esportare: JAVA_HOME=/usr/lib/jvm/java-6-sun export JAVA_HOME Questo settaggio globale è necessario così da specificare al sistema quale JVM utilizzare, e non dover ogni volta digitare il percorso relativo alla cartella di installazione della JVM, nonché fondamentale per il server Apache Tomcat. La seconda componente è il server Apache Tomcat, installato nella versione La sua istallazione è molto semplice e veloce, scaricando il pacchetto contenente il software direttamente dal sito ufficiale, procedendo poi con l estrazione dell archivio nella cartella desiderata. La sua configurazione invece varia da sistema a sistema, in quanto le porte e le relative connessioni che devono essere aperte e settate dipendono dalle modalità in

87 6.2 Installazione componenti 87 cui il server CAS viene utilizzato. Tuttavia per un uso del server CAS con la sola modalità di autenticazione tramite username e password, la configurazione di default base di Apache Tomcat è sufficiente, settando opportunamente la porta HTTPS. Invece la configurazione necessaria per una corretta gestione della modalità di autenticazione con certificati digitali dovrà essere fatta ad hoc, e verrà descritta in maniera più approfondita in seguito. Il server LDAP di ateneo, essendo già il server di autenticazione locale utilizzato in precedenza dall Università, è già perfettamente installato e configurato per accettare connessioni con il sistema CAS. Il software necessario alla compilazione del pacchetto software Java è Maven2 versione 2.1.0, disponibile gratuitamente all indirizzo Per installarlo è sufficiente scaricare il pacchetto dal sito ed estrarlo nella directory /usr/local/apache-maven/. Successivamente vengono esportate due variabili di ambiente globali che consentono l esecuzione dell applicazione: Da terminale si aggiungono le variabili di ambiente M2_HOME M2 tramite i comandi: export M2_HOME=/usr/local/apache-maven/apache-maven export PATH=$M2:$PATH A questo punto è possibile installare il server CAS. Qui è stata usata la versione Final, scaricandola gratuitamente dal sito ufficiale all indirizzo: La sua configurazione è stata più volte modificata, per poter prima di tutto introducendo il sistema di gestione della scadenza della password, ed infine l integrazione dei certificati digitali. Per questo motivo verranno via via presentate le diverse configurazioni relative ad ogni passo di installazione del server CAS, a fronte dell integrazione delle nuove funzionalità introdotte.

88 6.3 Primo problema affrontato: Gestione della scadenza password Primo problema affrontato: Gestione della scadenza password Uno dei maggiori problemi nell utilizzo in fase di autenticazione di username e password, sta nel fatto che quest ultima può essere intercettata. Il sistema di autenticazione CAS fa viaggiare la password su un canale protetto e sicuro, ma dato che la sicurezza non è mai troppa, se questa viene cambiata periodicamente dall utente i rischi di un uso improprio dell account calano in modo semplice ed efficace. Infatti una password che non viene cambiata da troppo tempo può essere insicura. Di norma gli utenti non sono molto ben predisposti a cambiarsi periodicamente la password, perché può essere considerato una perdita di tempo ed inoltre diventa obbligatorio ricordarsene più di una. Imponendo però all utente un cambio password periodico, si ha maggiore controllo su di essa e la sicurezza del sistema risulta rafforzata. Il server CAS nella sua versione originale, non è predisposto per effettuare un controllo di questo tipo, e gestire le varie situazioni che si possono presentare. Ma data la sua vasta folta di sviluppatori associati, sono state rilasciate alcune patch che integrano la funzionalità di gestione della scadenza della password nel protocollo CAS. Di queste ne esistono più di una, ognuna con le proprie peculiarità e caratteristiche. Ma data la non totale ufficialità di quest ultime, per la loro installazione solitamente è necessario modificare alcune parti del codice sorgente, anche perché il numero e il tipo di parametri da ricercare nel sottosistema di autenticazione locale, sono a discrezione dell installatore e amministratore. Le nuove funzionalità introdotte, controllano, oltre alla classica autenticazione username-password, che l account dell utente non sia stato bloccato dall amministratore, o che la password non sia scaduta, in quanto non è stata cambiata da troppo tempo, e gestiscono correttamente queste molteplici situazioni. Sul server LDAP di ateneo le date vengono gestite come numeri interi crescenti, partendo come giorno base dal 1/01/1970. Si è quindi scelto di concedere un periodo di validità per le password di 180 giorni aggiungendo una serie di attributi per ogni account sul server LDAP :

89 6.3 Primo problema affrontato: Gestione della scadenza password 89 istituzionale: è il parametro che identifica univocamente un account sul server LDAP. È nella forma per gli studenti, e nome.cognome@unipr.it per il personale strutturato e i docenti. ShadowExpire : contiene un numero intero che specifica il giorno di scadenza dell account utente, e viene settato dall amministratore. ShadowLastChange : contiene un numero intero che specifica il giorno dal 1/1/1970, nel quale l utente ha cambiato la password l ultima volta. ShadowWarning : contiene un numero intero che specifica il periodo di giorni nel quale l utente verrà informato della scadenza della propria password, e viene settato a 20 giorni. ShadowInactive : contiene il numero di giorni dopo la scadenza password oltre il quale l account sarà considerato scaduto, settato a 20 giorni. ShadowMax : contiene un numero intero che specifica l effettivo periodo di validità della password, e settato a 180 giorni. L utente avrà quindi la propria password valida per un periodo di 180 giorni. Inoltre verrà informato venti giorni prima della sua naturale scadenza, e venti giorni dopo, riportando nella pagina di avviso uno speciale link dal quale è possibile cambiare la password, permettendo quindi un periodo totale di 40 giorni nel quale l utente sarà abilitato ad accedere ai servizi desiderati, ma verrà invitato a cambiare la propria password. Scaduti gli ulteriori venti giorni di avviso dopo la scadenza della stessa, l account verrà considerato disabilitato ed il sistema CAS impedirà l accesso ai servizi fino alla sua riabilitazione, che a questo punto dovrà essere fatta direttamente dal personale tecnico dell Università Modifiche al protocollo di autenticazione L integrazione tra il server CAS ed il server LDAP durante un tentativo di autenticazione non segue più lo schema spiegato in precedenza nel paragrafo 5.3 del capitolo precedente.

90 6.3.1 Modifiche al protocollo di autenticazione 90 Il protocollo ora non considera più l utente come identificato correttamente allo step 5 dopo aver passato con successo il binding username-password, ma verrà effettuata un ulteriore ricerca sul server LDAP degli attributi speciali inseriti per la gestione della scadenza password. Per questo motivi sono quindi necessari ulteriori step: 6. Nel caso in cui il binding del passo 5 sia andato a buon fine, viene effettuata un ulteriore ricerca su nuovi attributi aggiunti sul server Ldap. 7. Il sistema CAS effettua vari controlli, per gestire al meglio le molteplici situazioni che possono verificarsi. 8. In base ai controlli del passo precedente, il processo di autenticazione può: procedere normalmente secondo il protocollo CAS con l invio dei ticket se la password dell utente sta per scadere, segnalarlo all utente invitandolo a cambiarla, ma concedere comunque l accesso ai servizi riattivando il normale protocollo CAS se la password è scaduta o l account è stato bloccato, segnarlo all utente con un relativo messaggio di errore e arrestare il protocollo di autenticazione Tecniche risolutive adottate Il primo tentativo di risoluzione del problema, è stato quello di sfruttare una patch in aggiunta al software principale rilasciata dagli stessi sviluppatori del CAS: cas-server-support-ldap-pwd-expiration-3.3.2b Questa all apparenza poteva sembrare non troppo difficile da implementare e configurare, in quanto le specifiche di configurazione aggiunte sembravano combaciare perfettamente con le richieste volute. Questa soluzione però non ha portato al risultato voluto, in quanto il programma controllava solo i codici di errore di LDAP, quindi veniva lasciato al server LDAP stesso i calcoli sulla scadenza della password, funzionalità però non supportata dal server OpenLdap di Ateneo. Si è quindi dovuto optare per una differente soluzione.

91 6.3.2 Tecniche risolutive adottate 91 Il secondo tentativo di risoluzione del problema consiste nell integrazione di alcuni specifici file nel sistema CAS, sviluppati dalla comunità aderente al sistema Jasig-CAS. Non essendo ancora una patch ufficiale, questa soluzione rispetto alla precedente ha richiesto ingenti modifiche ai file Java originali di CAS. Inoltre il processo di integrazione o sostituzione dei vecchi file non essendo ben documentato, ha reso necessaria un attenta analisi della precisa installazione dei nuovi file 57 nelle giuste directory, ma porterà alla fine al risultato desiderato: I file : AbstractAccountStatusGetter.java AccountStatusGetter.java ExtendedLdapAccountStatusGetter.java Sono stati inseriti con successo nella cartella: /cas-server-core/src/main/java/org/jasig/cas/web/support I file : AccountStatusAction.java AuthenticationViaFormAction.java ChooseChangepwdViaFormAction.java Sono stati inseriti con successo nella cartella: /cas-server-core/src/main/java/org/jasig/cas/web/flow Il file : RemoteCentralAuthenticationService È stato inserito con successo nella cartella: /cas-server-core/src/main/java/org/jasig/cas/remoting/server I file : CentralAuthenticationService.java CentralAuthenticationServiceImpl.java Sono stati inseriti con successo nella cartella: /cas-server-core/src/main/java/org/jasig/cas Il file : login-webflow.xml È stato inserito con successo nella cartella: /cas-server-webapp/src/main/webapp/web-inf L installazione procede con varie modifiche a questi file e ai file di configurazione del server CAS. 57 Tutti i file relativi a questa configurazione specifica di CAS sono disponibili all indirizzo:

92 6.3.3 Modifiche ai file sorgenti Java di CAS Modifiche ai file sorgenti Java di CAS Tutte le modifiche effettuate sono necessarie per poter integrare le nuove funzionalità nel sistema CAS dell Università. Il file Java più soggetto a modifiche è stato il ExtendedLdapAccountStatusGetter.java. La configurazione originale, prevedeva solamente la ricerca di un solo attributo dal server LDAP: statusattributename. Questo attributo serve a specificare il giorno di scadenza dell account utente, e sul server LDAP è l equivalente dell attributo ShadowExpire. Questo però non è sufficiente agli scopi desiderati, in quanto su LDAP è necessario ricercare anche l attributo ShadowLastChange. Si è quindi dichiarato un nuovo attributo lastchangeattributename, e modificato internamente alcune funzioni della classe. Una di queste è la funzione pubblica: public []String resolvefromldap(string lookupattributevalue) Questa funzione prende come parametro di ingresso una stringa contenente il nome dell utente, ed è stata modificata internamente per avere come valore di ritorno un array di stringhe contenente gli attributi speciali ricercati sul server LDAP. Inizialmente dagli sviluppatori questa funzione era stata pensata per aver come valore di ritorno un solo parametro stringa, ma questo non era sufficiente in quanto i parametri da ricercare sul server LPAD sono più di uno. Questa la definizione completa della funzione suddetta: private String[] resolvefromldap(final String lookupattributevalue) { // Modifiche effettuate: Valore di ritorno da String a String[] final String searchfilter = LdapUtils.getFilterWithValues(this.filter,lookupAttributeValue); if (this.logger.isdebugenabled()) { this.logger.info("ldap: starting search for value='" + lookupattributevalue + "'" + "with searchfilter '" + searchfilter + "'"); } try { // searching the directory AttributesMapper mapper = new AttributesMapper(){ public Object mapfromattributes(final Attributes attrs) throws NamingException { ExtendedLdapAccountStatusGetter.this.logger.debug("LDAP: trying to map attribute '" + ExtendedLdapAccountStatusGetter.this.statusAttributeName+

93 6.3.3 Modifiche ai file sorgenti Java di CAS 93 "' and '" + ExtendedLdapAccountStatusGetter.this.lastchangeAttributeName+ "' from result."); int attributessize = attrs.size(); ExtendedLdapAccountStatusGetter.this.logger.debug("LDAP: found "+ attributessize +" attributes as result, starting to resolve..."); final Attribute attribute = attrs.get(extendedldapaccountstatusgetter.this.statusattributen ame); // Modifiche effettuate : Aggiunta parametro attribute1 final Attribute attribute1 = attrs.get(extendedldapaccountstatusgetter.this.lastchangeattributen ame); if (attribute == null) { ExtendedLdapAccountStatusGetter.this.logger.debug("LDAP: attribute was null in result."); return null; } // Modifiche effettuate : Aggiunto eventuale debug per il parametro // attribute1 if (attribute1 == null) { ExtendedLdapAccountStatusGetter.this.logger.debug("LDAP: attribute1 was null in result."); return null; } if (ExtendedLdapAccountStatusGetter.this.logger.isDebugEnabled()) { ExtendedLdapAccountStatusGetter.this.logger.debug("LDAP: found attribute in result, value='" + attribute.get() + "'"); // Modifiche effettuate : Aggiunto debug per il parametro attribute1 ExtendedLdapAccountStatusGetter.this.logger.debug("LDAP: found attribute1 in result, value='" + attribute1.get() + "'"); } // Modifiche effettuate : Modificato Il valore di ritorno del nuovo // oggetto mapper: Da stringa ad array di due stringhe String[] attributi = {(String) attribute.get(), (String) attribute1.get()}; return attributi; } // Fine if }; // Fine definizione oggetto mapper // Chiamata effettiva della search() al server Ldap final List resultlist = this.ldaptemplate.search( this.searchbase, searchfilter, getsearchcontrols(), mapper); if (resultlist.isempty()) { this.logger.warn("no result was found for: " + lookupattributevalue); return null; } if (resultlist.size() > 1) { this.logger.error("ldap: search returned multiple results" + " for value='" + lookupattributevalue + "'" + " which is not allowed."); return null; } // Modificato il valore di ritorno per la funzione resolvefromldap() : // Array di stringhe contenente i due parametri ritornati da Ldap al // posto di un unica stringa return (String[]) resultlist.get(0);

94 6.3.3 Modifiche ai file sorgenti Java di CAS 94 } } } // Fine blocco try catch (Exception e) { this.logger.error(e, e); return null; Un'altra funzione pubblica sempre della medesima classe, modificata molto ingentemente è la funzione: public int getstatus(string userid). Questa funzione prende come parametro di ingresso la stringa contenente il nome utente in fase di autenticazione, e ritorna un numero intero codificante lo stato attuale dell account utente. Può quindi essere considerata una delle funzioni di maggior rilevanza di tutto il pacchetto software integrato, perché appunto in essa avvengono la maggior parte dei controlli relativi alle decisioni da prendere. Dopo aver risolto la ricerca su LDAP avvalendosi della funzione descritta precedentemente, utilizza i due 58 attributi speciali ritornatigli, in modo da gestire correttamente tutti i casi che si possono presentare. Questa è la parte di codice sorgente Java relativa a questa funzione: public int getstatus(string userid) { this.logger.debug("lookup for userid='" + userid + "'"); // Modifica effettaute: ldapresult da String a String[] String[] ldapresult=resolvefromldap(userid); this.logger.debug("ldapresult='" + ldapresult[0] + "' and '" + ldapresult[1] + "'"); // Modifiche effettaute: inizializzazione delle variabili shadowexpire e // shadowlastchange necessarie per i calcoli int shadowexpire = Integer.parseInt (ldapresult[0]); int shadowlastchange = Integer.parseInt (ldapresult[1]); // Modifiche effettuate: Calcolo del currentday int currentday = (int)math.round(system.currenttimemillis()/ ); // Stampa delle info dei risultati ottenuti this.logger.info("currentday -> "+ currentday ); this.logger.info("shadowexpire -> "+ ldapresult[0] ); 58 In realtà gli attributi da ricercare sarebbero cinque; però, per gli attributi ShadowWarning, Shadow- Inactive e ShadowMax del server Ldap, essendo gli stessi per ogni account, rispettivamente 20, 20 e 180, si è optato per il settaggio diretto all interno del file deployerconfigcontext.xml, invece di ricercarli ogni volta sul server Ldap

95 6.3.3 Modifiche ai file sorgenti Java di CAS 95 this.logger.info("shadowlastchange -> "+ ldapresult[1] ); this.logger.info("shadowlastchange + DaysTillLocked -> "+ (shadowlastchange + daystilllocked) ); this.logger.info("shadowlastchange + DaysTillLocked + WarningDays-> "+ (shadowlastchange + daystilllocked + warningdays) ); // Switch della variabile shadowexpire per il calcolo dello stato account // dell'utente switch (shadowexpire) { case -2: return STATUS_BLOCKED; case -1: return STATUS_ACTIVATE; case 65536: return STATUS_ACTIVE; default: if (shadowexpire < currentday) { return STATUS_LOCKED; // L'account è scaduto } else { if (shadowlastchange + daystilllocked + warningdays < currentday) { return STATUS_LOCKED; // L'account è scaduto Non è stata cambiata la password da troppo tempo } else if (shadowlastchange + daystilllocked - warningdays < currentday) { return STATUS_CHANGEPWD; // L'account è nel periodo di 40 gg nel quale è possibile cambiare la // password } else { return STATUS_ACTIVE; // L'account è attivo } } // Fine Switch } Le modifiche apportate a questa funzione sono state necessarie per gestire correttamente le varie situazioni che potevano presentarsi. Dopo aver risolto la ricerca sul server LDAP grazie alla chiamata alla funzione resolvefromldap( ) dei due attributi citati, viene calcolato il giorno corrente, ed effettuato uno switch della variabile shadowexpire corrispondente alla variabile statusattributename della classe stessa, settata direttamente dall amministratore del sistema. Questo switch controlla inizialmente che l amministratore non abbia deciso di bloccare l account utente o che vi sia stata data validità illimitata. Questo viene fatto direttamente sul server LDAP settando opportunamente i parametri relativi all attributo ShadowExpire.

96 6.3.4 Modifiche ai file di configurazione di CAS 96 Altrimenti se questo parametro non trova la giusta corrispondenza nello switch, si entra nel caso di default, dove viene effettuata una serie di if-else per il controllo del secondo parametro shadowlastchange corrispondente alla variabile della classe lastchangeattributename. Questo viene opportunamente combinato con gli altri due parametri daystilllocked e warningdays settati da file, e confrontato con il giorno corrente. In ogni caso si avrà come valore di ritorno di questa funzione un numero intero specificante l attuale stato dell account utente. Ne risulta che questo potrà essere scaduto, oppure che sia nel periodo di 40 giorni nel quale viene ricordato di cambiare la password, oppure semplicemente che sia attivo. Vale la pena notare che le variazioni qui introdotte nei file sorgenti Java, non intaccano assolutamente il protocollo di autenticazione CAS e le specifiche di connessione sicura con l utente, ma solamente lo step di autenticazione locale interna tra CAS ed il server LDAP di ateneo. Infatti il protocollo CAS generale proseguirà solamente a fronte di: Credenziali utente valide Validità dello stesso account e della relativa password Modifiche ai file di configurazione di CAS Per una corretta configurazione del server CAS è necessario configurare il file deployerconfigcontext.xml situato nella cartella /cas-server-webapp/src/main/webapp/web-inf/. È un file di configurazione molto importante, in quanto contiene le specifiche interne di connessione al server LDAP 59, e setta il valore di alcune variabili interne, necessarie in fase di compilazione ed esecuzione del programma. 59 I campi relativi alla connessione al server LDAP di ateneo e relativa password sono contrassegnati da asterischi, per ovvi motivi di sicurezza.

97 6.3.4 Modifiche ai file di configurazione di CAS 97 Inoltre questo è il file da modificare per poter introdurre le nuove funzionalità di gestione della scadenza password, in quanto è da questo punto in poi che il nuovo progetto debitamente compilato, vedrà i nuovi file e le nuove opzioni introdotte. Questa la parte di codice XML relativa alle specifiche di configurazione:... <!-- <bean class="org.jasig.cas.authentication.handler.support. SimpleTestUsernamePass wordauthenticationhandler" /> --> // Commentato il semplice test di prova // Definizione del bind di autenticazione al server Ldap <bean class="org.jasig.cas.adaptors.ldap.bindldapauthenticationhandler"> <property name="filter" value="mail=%u" /> <property name="searchbase" value="ou=people,dc=unipr,dc=it" /> <property name="contextsource" ref="contextsource" /> </bean> <bean id="accountstatusgetter" class="org.jasig.cas.web.support.extendedldapaccountstatusgetter" p:filter="mail=%u" p:statusattributename="shadowexpire" p:lastchangeattributename="shadowlastchange" p:searchbase="ou=people,dc=unipr,dc=it" p:contextsource-ref="contextsource" p:daystilllocked="180" p:warningdays="20" /> <bean id="contextsource" class="org.springframework.ldap.core.support.ldapcontextsource"> <property name="pooled" value="true" /> <property name="urls"> <list> <value>ldap://ldap*********:***</value> </list> </property> <property name="userdn" value="cn=***,dc=ldap,ou=***,ou=***,dc=unipr,dc=it" /> <property name="password" value="***" /> <property name="baseenvironmentproperties"> <map> <entry key="com.sun.jndi.ldap.connect.timeout" value="10"/> <entry key="java.naming.security.authentication" value="simple"/> </map> </property> </bean> <bean id="choosechangepwdviaformaction" class="org.jasig.cas.web.flow.choosechangepwdviaformaction" />...

98 6.3.4 Modifiche ai file di configurazione di CAS 98 Per poter comunicare esternamente all utente le eventuali comunicazioni relative al proprio account, sono state introdotte alcune nuove pagine jsp e configurate per gestire le varie situazioni riguardanti lo stato dell account utente: Stato Account: Cambio Password -> caschangepwdview.jsp Stato Account: Scaduto -> caslockedview.jsp Stato Account: Bloccato -> casblockedview.jsp È stato inoltre modificato il file default_views.properties, che contiene le specifiche indicanti al server, quali sono le pagine jsp da aprire ed il relativo percorso, in base ai calcoli effettuati sullo stato dell account utente e sulla validità della password. Queste le modifiche apportate a tale file:... ### Locked caslockedview.(class)=org.springframework.web.servlet.view.jstlview caslockedview.url=/web-inf/view/jsp/default/ui/caslockedview.jsp ### Blocked casblockedview.(class)=org.springframework.web.servlet.view.jstlview casblockedview.url=/web-inf/view/jsp/default/ui/casblockedview.jsp ### Activate casactivateview.(class)=org.springframework.web.servlet.view.jstlview casactivateview.url=/web-inf/view/jsp/default/ui/casactivateview.jsp ### Changepwd caschangepwdview.(class)=org.springframework.web.servlet.view.jstlview caschangepwdview.url=/web-inf/view/jsp/default/ui/caschangepwdview.jsp

99 6.3.4 Modifiche ai file di configurazione di CAS 99 Essendo le pagine jsp in questione molto simili tra loro, verrà riportato solo un esempio relativo al file: caschangepwdview.jsp. Questo il codice jsp di tale file: page contenttype="text/html; charset=utf-8" %> <jsp:directive.include file="includes/top.jsp" /> <div id="msg" class="success"> <h2><spring:message code="screen.success.header" /></h2> <p><spring:message code="screen.success.success" /></p> <p><spring:message code="screen.success.security" /></p> </div> <div class="info"> <p><spring:message code="screen.service.error.messagechangepwd"/> </p> <p><spring:message code="screen.confirmation.message" arguments="${fn:escapexml(param.service)}${fn:indexof(param.service, '?') eq -1? '?' : '&'}ticket=${serviceticketid}" /></p> </div> <div id="sidebar"> <p><spring:message code="screen.welcome.security" /></p> <div id="list-languages"> <%final String querystring = request.getquerystring() == null? "" : request.getquerystring().replaceall("&locale=([a-zaz][a-za-z]_)?[a-za-z][a-za-z] ^locale=([a-za-z][a-zaz]_)?[a-za-z][a-za-z]", "");%> <c:set var='query' value='<%=querystring%>' /> <c:set var="loginurl" value="login?${query}${not empty query? '&' : ''}locale=" /> <h3>languages:</h3> <ul> <li class="first"><a href="login?${query} ${not empty query? '&' : ''}locale=en">english</a></li> <li><a href="${loginurl}es">spanish</a></li> <li><a href="${loginurl}fr">french</a></li> <li><a href="${loginurl}ru">russian</a></li> <li><a href="${loginurl}nl">nederlands</a></li> <li><a href="${loginurl}sv">svenskt</a></li> <li><a href="${loginurl}it">italiano</a></li> <li><a href="${loginurl}ur">urdu</a></li> <li><a href="${loginurl}zh_cn">chinese</a></li> <li><a href="${loginurl}de">deutsch</a></li> <li><a href="${loginurl}ja">japanese</a></li> <li><a href="${loginurl}hr">croatian</a></li> <li><a href="${loginurl}cs">czech</a></li> <li><a href="${loginurl}sl">slovenian</a></li > <li><a href="${loginurl}pl">polish</a></li> <li class="last"><a href="${loginurl}tr">turkish</a></li> </ul> </div> </div> <jsp:directive.include file="includes/bottom.jsp" />

100 6.3.5 Compilazione e installazione pacchetto CAS Compilazione e installazione pacchetto CAS Operate tutte le modifiche ai file sorgenti Java di installazione ed ai vari file di configurazione, è possibile ricompilare l intero pacchetto CAS grazie a Maven2. Dalla shell ci si sposta nella directory principale del CAS e si esegue il comando: mvn -Dmaven.test.skip=true package install Il precedente comando ricompila l intero pacchetto CAS con le relative modifiche e crea uno speciale file con estensione.war 60, pronto per essere copiato nella cartella principale di Apache Tomcat. Infatti procedendo alla copia di questo file nella cartella webapp del server Tomcat e all avvio del server stesso, questi procederà automaticamente alla creazione della directory contenente l intera applicazione web funzionante. Questo processo viene chiamato comunemente deploy. Questo un esempio di autenticazione al server CAS con un account nel quale la password è in fase di scadenza. Verrà consentito l accesso al servizio richiesto, non prima però di avere avvertito l utente della scadenza della propria password. Figura 6.1 Pagina di conferma di avvenuta autenticazione riportante l avviso di scadenza password 60 I file con estensione.war sono denominati Web Archives e rappresentano dei componenti utilizzati in fase di messa in opera di un'applicazione(deployment). Un file.war, al suo interno, contiene i componenti Web che fanno parte di una applicazione J2EE (come, ad esempio pagine JSP, file HTML, file.class e file XML).

101 6.4 Secondo problema affrontato: Gestione dei Certificati X Secondo problema affrontato: Gestione dei certificati X509 La crescita, lo sviluppo e la sicurezza dei certificati digitali come metodo di autenticazione, ha fatto crescere la necessità di fornire anche l Università di Parma di una metodologia di autenticazione tramite l uso di certificati X509 per i propri studenti, docenti, tecnici, e tutto il personale annesso. Per questo il secondo problema affrontato durante il periodo di tirocinio è stato quello di configurare il server CAS di Ateneo, permettendo l accettazione di certificati digitali tipo X509 in fase di autenticazione utente. Come già specificato, il server CAS è già predisposto per un uso di questo tipo. Quindi rispetto al problema precedente di gestione delle password dove sono state necessarie pesanti modifiche al codice sorgente java, per risolvere questa problematica è stata necessaria un attenta configurazione delle varie entità coinvolte. Infatti in primo luogo si è configurato il server Apache Tomcat sul quale è installato il sistema CAS, per identificare se stesso agli utenti esterni, ed accettare certificati digitali in fase di autenticazione. Successivamente è stato scelto il modo in cui il CAS identifica il possessore del certificato, e configurata la relativa metodologia di autenticazione. Infatti CAS lascia libera scelta allo sviluppatore del modo in cui le credenziali fornite nel certificato e l autorità che le ha rilasciate verranno gestite. Quindi la possibilità di accettare certificati rilasciati direttamente dall Università, porterà alla creazione di un infrastruttura a chiave pubblica locale per l Ateneo di Parma. Inoltre nel caso in cui un utente abbia già un suo personale certificato non rilasciato per forza dalla CA dell Università, potrà richiedere attraverso un apposito servizio, che questo venga registrato all interno del sistema, ed utilizzato per le future autenticazioni.

102 6.4.1 Configurazione di Apache Tomcat per il supporto dei certificati X Configurazione di Apache Tomcat per il supporto dei certificati X509 Il sistema CAS opera in modo sicuro solamente quando il client si connette attraverso una connessione TLS/SSL. È quindi necessario configurare Tomcat consentendo una connessione HTTPS, definendo una specifica porta di ascolto sicura per queste richieste. Inoltre le connessioni che supportano SSL vengono configurate con due file che rappresentano una collezione di certificati X509, chiamati keystorefile e truststorefile. Il keystorefile è un certificato X509 che il server Tomcat userà per identificare se stesso al browser utente. Questo certificato contiene inoltre il nome del DNS sul quale Tomcat è in esecuzione. Il truststorefile invece è una collezione di certificati X509 che rappresenta le Certificate Authority dalle quali Tomcat è disposto ad accettare i certificati utente. Quando un browser utente si connette al server Tomcat sul quale è installato il sistema CAS tramite canale HTTPS, questi deve identificare se stesso inviando il proprio certificato. È stato quindi necessario generare il certificato che Tomcat presenterà alla richiesta di identificazione, e questo può essere fatto tramite l utility Java keytool, presente nella versione Java 6 installata. Infatti con questo tool è possibile creare dei certificati dalla shell di Unix, eseguendo il comando: keytool -genkey -alias tomcat -keyalg RSA -keystore /var/lib/tomcat6/webapps/keystore.jks Questo comando genera il file keystore.jks nel percorso specificato, contenente appunto il certificato identificate il server Tomcat. Per esportare il certificato appena creato in un formato leggibile si esegue il comando: keytool -export -alias tomcat -keystore /var/lib/tomcat6/webapps/keystore.jks -file /tmp/cert.pem Questo comando creerà il certificato in formato Base64 con estensione.pem nel percorso specificato.

103 6.4.1 Configurazione di Apache Tomcat per il supporto dei certificati X Successivamente è stato creato il truststorefile. Si è scelto come configurazione iniziale di accettare certificati rilasciati direttamente dalla CA dell Università di Parma 61, quindi è stato fatto il download del seguente certificato, e salvato sotto il nome di ca.pem : Figura 6.2 Certificato Digitale dell Università di Parma in formato PEM La utility Java keytool non è abilitata per importare certificati in questa estensione, quindi è stato necessario modificare il formato del certificato portandolo ad uno di tipo binario, con estensione.der. Questa trasformazione è stata fatta da terminale eseguendo il comando: openssl x509 -in /tmp/ca.pem -out /tmp/ca.der -outform der Il certificato è ora pronto per essere importato nel file truststore.jks, attraverso il comando: keytool -import -alias cacce -file /tmp/ca.der -keystore /var/lib/tomcat6/webapps/truststore.jks 61

104 6.4.1 Configurazione di Apache Tomcat per il supporto dei certificati X Con la stessa tecnica qui adottata è quindi possibile importare più di una tipologia di certificati accettati da diverse Certification Autority, così da permettere ad utenti aventi già il proprio certificato digitale rilasciato da un CA fidata, di autenticarsi al sistema. Per poter attuare la strategia della doppia modalità di autenticazione, ovvero sia tramite l invio di un certificato digitale X509 sia tramite username/password, è consigliato di configurare il server Apache Tomcat in modo da accettare connessioni su due differenti porte. È stato quindi modificato il file server.xml nella cartella principale di Tomcat, relativo alla propria configurazione, aggiungendo questo codice XML: <Connector protocol="org.apache.coyot.http11.http11protocol" port="8443" maxhttpheadersize="8192" maxthreads="150" minsparethreads="25" maxsparethreads="75" enablelookups="false" disableuploadtimeout="true" acceptcount="100" scheme="https" secure="true" clientauth="want" sslprotocol="tls" SSLEnabled="true" keystorefile="/usr/share/tomcat6/webapps/keystore.jks" keystorepass="***" truststorefile="/usr/share/tomcat6/webapps/truststore.jks" truststorepass="***" /> Questa aggiunta permette di configurare una connessione HTTPS sulla porta 8443 specificando l uso del protocollo TLS, e settando i percorsi relativi ai due file keystorefile e truststorefile. Il campo clientauth="want" precisa al server Tomcat di richiedere al browser utente di fornirgli un certificato digitale, solo se questo è disponibile. In caso contrario verrà mostrata automaticamente la form di autenticazione tramite username e password.

105 6.4.2 Configurazione di CAS per il supporto dei certificati X Configurazione di CAS per il supporto dei certificati X509 Le modifiche da effettuare per integrare il sistema CAS con l uso dei certificati digitali X509 sono prettamente ai file di configurazione del server. Il primo file modificato è il file pom.xml nella cartella /cas-server-webapp/. A questo file è stato aggiunto il seguente codice XML: <dependency> <groupid>${project.groupid}</groupid> <artifactid>cas-server-support-x509</artifactid> <version>${project.version}</version> </dependency> Questa nuova dipendenza specifica al server CAS di utilizzare il plugin aggiuntivo di supporto per l uso dei certificati X509. Un altro file di configurazione molto importante di CAS è il loginwebflow.xml locato nella cartella /cas-server-webapp/src/main/webapp/web-inf/. Questo file consiste in una sequenza XML di direttive per il server CAS, infatti qui vengono specificate quali operazione eseguire durante il protocollo di autenticazione. È stato quindi configurato in modo da richiedere come primo metodo di autenticazione un certificato X509. Se questo non è presente o se non valido, l utente viene ridiretto automaticamente alla form di login tramite username e password. In caso di autenticazione eseguita correttamente, vengono inviati i vari ticket secondo il protocollo CAS e concesso all utente il servizio richiesto, in caso contrario viene riproposta la form di autenticazione e segnalato l errore avvenuto. Questo il codice XML di tale file: <?xml version="1.0" encoding="utf-8"?> <flow...>... <start-state idref="initialflowsetup"/> <action-state id="initialflowsetup"> <action bean="initialflowsetupaction" /> <transition on="success" to="ticketgrantingticketexistscheck" /> </action-state>

106 6.4.2 Configurazione di CAS per il supporto dei certificati X <decision-state id="ticketgrantingticketexistscheck"> <if test="${flowscope.ticketgrantingticketid!= null}" then="hasservicecheck" else="gatewayrequestcheck" /> </decision-state> <decision-state id="gatewayrequestcheck"> <if test="${externalcontext.requestparametermap['gateway']!= '' && externalcontext.requestparametermap['gateway']!= null && flowscope.service!= null}" then="redirect" else="startauthenticate" /> </decision-state> <decision-state id="hasservicecheck"> <if test="${flowscope.service!= null}" then="renewrequestcheck" else="viewgenericloginsuccess" /> </decision-state> <decision-state id="renewrequestcheck"> <if test="${externalcontext.requestparametermap['renew']!= '' && externalcontext.requestparametermap['renew']!= null}" then="startauthenticate" else="generateserviceticket" /> </decision-state> <decision-state id="warn"> <if test="${flowscope.warncookievalue}" then="showwarningview" else="redirect" /> </decision-state> <action-state id="startauthenticate"> <action bean="x509check" /> <transition on="success" to="sendticketgrantingticket" /> <transition on="error" to="viewloginform" /> </action-state> <view-state id="viewloginform" view="casloginview"> <render-actions> <action bean="authenticationviaformaction" method="setupform"/> <action bean="authenticationviaformaction"method="referencedata"/> </render-actions> <transition on="submit" to="bindandvalidate" /> </view-state> <action-state id="bindandvalidate"> <action bean="authenticationviaformaction" /> <transition on="success" to="submit" /> <transition on="error" to="viewloginform" /> </action-state> <action-state id="submit"> <action bean="authenticationviaformaction" method="submit" /> <transition on="warn" to="warn" /> <transition on="success" to="sendticketgrantingticket" /> <transition on="error" to="viewloginform" /> </action-state>

107 6.4.2 Configurazione di CAS per il supporto dei certificati X <action-state id="sendticketgrantingticket"> <action bean="sendticketgrantingticketaction" /> <transition on="success" to="servicecheck" /> </action-state> <decision-state id="servicecheck"> <if test="${flowscope.service!= null}" then="generateserviceticket" else="viewgenericloginsuccess" /> </decision-state> <action-state id="generateserviceticket"> <action bean="generateserviceticketaction" /> <transition on="success" to ="warn" /> <transition on="error" to="viewloginform" /> <transition on="gateway" to="redirect" /> </action-state> <end-state id="viewgenericloginsuccess" view="caslogingenericsuccessview" /> <end-state id="showwarningview" view="casloginconfirmview" /> <end-state id="redirect" view="bean:dynamicredirectviewselector" /> <end-state id="viewserviceerrorview" view="viewserviceerrorview" /> <end-state id="viewservicessoerrorview" view="viewservicessoerrorview" /> </flow> A questo punto è necessario configurare come il server CAS esamini il certificato X509 presentatogli dal browser utente verificando che sia stato rilasciato da una CA fidata, e che estrapoli nei campi del certificato l identificatore da ricercare sul server LDAP per proseguire nell identificazione dell utente. Da qui sono entrate in gioco le scelte effettuate in base agli obbiettivi prefissati, ovvero concentrarsi sulla sicurezza degli utenti locali dell Università. Possedere quindi un account sul server LDAP di Ateneo è un requisito fondamentale per proseguire nell autenticazione e identificazione utente. Due sono state le strategie adottate: la prima consiste nell identificare l utente tramite il campo CN del certificato, contenente l indirizzo dell Università che funge da identificatore unico sul server LDAP. La relativa configurazione del file deployerconfigcontext.xml avviene fatta aggiungendo uno speciale bean nella lista delle proprietà credentialstoprincipalresolvers, specificando quale campo ricercare nel certificato e come ricercarlo sul server LDAP attraverso la configurazione della proprietà authenticationhandlers.

108 6.4.2 Configurazione di CAS per il supporto dei certificati X Questa la sezione di codice XML relativa a tale parte:... <bean id="authenticationmanager"... <property name="credentialstoprincipalresolvers"> <list> <bean class="org.jasig.cas.adaptors.x509.authentication.principal.x509- CertificateCredentialsToIdentifierPrincipalResolver"> <property name="identifier" value="$cn" /> </bean> </list> </property>... <property name="authenticationhandlers"> <list> <bean class="org.jasig.cas.adaptors.ldap.bindldapauthenticationhandler"> <property name="filter" value="mail=%u"/> <property name="searchbase" value="dc=unipr,dc=it"/> <property name="contextsource" ref="contextsource"/> </bean>... Tuttavia questa scelta non è del tutto efficiente, in quanto obbliga l utente a possedere un certificato digitale contenente obbligatoriamente il campo CN correttamente settato al relativo valore della sua . Una restrizione di questo tipo non può essere considerata una buona metodologia nell uso dei certificati digitali, perché imporrebbe a questi di rispettare una specifica struttura. Questo ovviamente non è quello che si vuole dal momento che si desidera introdurre un sistema di autenticazione attraverso certificati digitale che possono essere rilasciati da CA differenti e aventi differenti strutture interne. La seconda strategia invece è più elegante e consiste nella ulteriore ricerca di uno speciale attributo inserito opportunamente sul server LDAP di Ateneo, composto da una stringa alfanumerica contenente: Il numero seriale del certificato. L autorità certificante (Issuer DN) che lo ha rilasciato In questo modo quando l utente presenta il proprio certificato, e il server CAS opportunamente configurato estrapola automaticamente i due precedenti campi creando una stringa comprendente l unione dei due. Si connette quindi al server LDAP ricercando su di esso la stringa appena creata. Nel caso in cui questa

109 6.4.2 Configurazione di CAS per il supporto dei certificati X corrisponda ad una delle sue entry, l utente sarà univocamente identificato e verrà ritornato come parametro il relativo attributo contenente il valore della , così successivamente l'utente verrà riconosciuto come tale dall intero sistema. In caso contrario verrà riproposta all utente la normale form di login tramite username e password. Questa modalità viene fatta attraverso una precisa configurazione del file deployerconfigcontext.xml, specificando alcuni bean di connessione al server LDAP ed introducendone altri, precisando al sistema CAS quale metodologia di identificazione utente affrontare. Questo codice XML relativo a tale file: <?xml version="1.0" encoding="utf-8"?>... <bean id="authenticationmanager" class="org.jasig.cas.authentication.authenticationmanagerimpl">... <property name="credentialstoprincipalresolvers"> <list>... <bean class="org.jasig.cas.authentication.principal. CredentialsToLDAPAttributePrincipalResolver" > <property name="credentialstoprincipalresolver"> <!-- This resolver this will create a unique ID of form: SERIALNUMBER=<certificate_serial_number>, <certificate_issuerdn> eg: SERIALNUMBER= SERIALNUMBER=200301, CN=Citizen CA, C=BE --> <bean class="org.jasig.cas.adaptors.x509.authentication. principal.x509certificatecredentialstoserialnumberand IssuerDNPrincipalResolver" /> </property> <!-- attribute that needs to be matched to in LDAP: --> <property name="filter" value="storicoserver=%u" /> <!-- to be retrieved from LDAP as the new principal for CAS: --> <property name="principalattributename" value="mail" /> <property name="searchbase" value="ou=people,dc=unipr,dc=it" /> <!-- reference to LDAP server configuration: --> <property name="contextsource" ref="contextsource" /> </bean> </list> </property>... <property name="authenticationhandlers"> <list>... <bean class="org.jasig.cas.adaptors.x509.authentication.handler. support.x509credentialsauthenticationhandler"> <property name="trustedissuerdnpattern" value=" address=ca_cce@unipr.it, CN= OU=Centro di Calcolo Elettronico, O=Universita degli Studi di Parma, L=Parma, ST=Parma, C=IT" /> </bean>

110 6.4.2 Configurazione di CAS per il supporto dei certificati X <bean class="org.jasig.cas.adaptors.ldap. BindLdapAuthenticationHandler"> <property name="filter" value="mail=%u"/> <property name="searchbase" value="dc=unipr,dc=it"/> <property name="contextsource" ref="contextsource"/> </bean> </list> </property> </bean>... <bean id="contextsource" class="org.springframework.ldap.core.support.ldapcontextsource"> <property name="userdn"value="cn=***,dc=ldap,ou=cce, ou=strutture,dc=unipr,dc=it"/> <property name="password" value="***"/> <property name="urls"> <list> <value>***</value> </list> </property> <property name="baseenvironmentproperties"> <map> <entry> <key> <value>java.naming.security.authentication</value> </key> <value>simple</value> </entry> </map> </property> </bean> Adottando questa strategia è possibile quindi accettare qualsiasi tipo di certificato digitale che sia stato rilasciato da una delle CA ritenute fidate. L unico contro è che l utente deve aver registrato correttamente il proprio certificato sul server LDAP di Ateneo. Questo passo può essere effettuato attraverso un apposito servizio web dell Università, al quale verrà richiesto di controllare il certificato presentatogli e sottoporre a giudizio la sua effettiva registrazione, dove verrà mappata opportunamente la stringa contenente il numero seriale e l autorità certificante sul server LDAP, legando quindi il certificato stesso all identità digitale del soggetto relativa a questa infrastruttura. In questo modo avrà anche un maggiore controllo iniziale sull identità dell utente che richiederà di utilizzare il proprio certificato digitale per le autenticazioni future. Questa specifica configurazione, che impone come requisito di autenticazione quello di avere un account utente locale, può essere modificata proprio in questo

111 6.4.3 Compilazione e installazione del pacchetto CAS con certificati X punto. Infatti inserendo un differente bean nella lista relativa alla proprietà credentialstoprincipalresolver, è possibile configurare il CAS per accettare certificati digitali di utenti che non abbiano obbligatoriamente un account locale, identificandoli semplicemente con il relativo campo Distinguished Name DN comune a tutti i certificati digitali. In questo modo sarebbe possibile autenticare soggetti esterni all Ateneo, ad esempio docenti o personale di altre Università, che presentino un certificato digitale valido rilasciato da una delle CA considerate fidate impostate nel truststorefile del server Tomcat. Una di queste potrebbe essere la comunità GARR 62 : il consorzio ideatore e gestore della rete telematica nazionale dell'università e della ricerca. La sua missione consiste nell'implementazione, gestione ed ampliamento della rete telematica nazionale ad altissima velocità, interconnessa con tutte le reti della ricerca europee e mondiali. Il lavoro del GARR rappresenta un contributo significativo per l'attività della comunità scientifica ed accademica italiana e per il progresso tecnologico ed industriale del nostro Paese. Infatti uno dei suoi servizi è proprio quello di rilasciare certificati digitali X509 ai membri della propria comunità. Configurare il server Tomcat per accettare i certificati emessi dalla GARR Certification Authority sarebbe un ottima scelta, e permetterebbe un miglior scambio di informazioni con docenti e ricercatori esterni all Ateneo. Così facendo gli utenti aderenti a questa comunità sarebbero effettivamente autenticati ed identificati, lasciando poi ad un altro servizio come Shibboleth la facoltà di decidere le relative politiche di autorizzazione Compilazione e installazione pacchetto CAS con certificati X509 La configurazione del server CAS è ora conclusa. Si può procedere alla sua completa installazione come già specificato nel paragrafo 6.3.5, compilando l intero pacchetto software CAS e procedendo al successivo deploy sul server Tomcat. 62

112 6.4.3 Compilazione e installazione del pacchetto CAS con certificati X Richiedendo ora un servizio web dell Università per il quale è necessaria l autenticazione, questi rimanderà l utente alla pagina web del CAS, che si presenterà inviando il proprio certificato. Se l utente avrà installato sul proprio browser uno o più certificati digitali, verrà richiesto in automatico di inviarne uno tra quelli disponibili, altrimenti verrà presentata la form di login attraverso username e password. In caso l autenticazione abbia successo, l utente verrà riconosciuto dall intera infrastruttura tramite il valore della sua dell Università. Figura 6.3 Esempio di autenticazione CAS tramite invio di un certificato digitale. Vale la pena notare che nel caso in cui l utente abbia un solo certificato digitale installato sul proprio browser, o che lo abbia settato per fare in modo di inviarne uno automaticamente, l utente sarà totalmente trasparente alla fase di autenticazione. Infatti se questa avrà successo, non verrà nemmeno mostrata la pagina di conferma, ma l utente verrà direttamente reinviato al servizio richiesto.