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: Relatore:

Matteo Sironi Chiar.mo Prof Roberto Alfieri

Correlatore:

Dott.Ing Marco Panella

Anno Accademico 2008/2009

Ai miei genitori

Ai miei nonni

Alla mia Maider

Indice

1 Introduzione 9 1.1 Contributo della tesi ..............................................................................................11

1.2 Aspetti sviluppati ...................................................................................................12

2 Autenticazione distribuita 13 2.1 Introduzione alla crittografia ................................................................................14

2.1.1 Chiavi e algoritmi ..............................................................................................15

2.1.2 Due principi fondamentali della crittografia .......................................................16

2.1.3 Algoritmi a chiave simmetrica ...........................................................................17

2.1.4 Algoritmi a chiave pubblica ...............................................................................18

2.2 Protocolli di autenticazione ..................................................................................20

2.2.1 Autenticazione basata su segreto condiviso ........................................................21

2.2.2 Autenticazione con KDC ...................................................................................22

2.2.3 Autenticazione con Kerberos..............................................................................24

2.2.4 Autenticazione con crittografia a chiave pubblica...............................................27

2.3 Metodi di autenticazione........................................................................................28

2.3.1 Vantaggi e svantaggi dei metodi di autenticazione .............................................28

2.4 Autenticazione centralizzata SSO .........................................................................32

Indice 6

3 L’Identità digitale 35 3.1 Tipi di firme elettroniche.......................................................................................37

3.2 Firma digitale.........................................................................................................37

3.2.1 Creazione della firma digitale.............................................................................40

3.2.2 Il valore legale della firma digitale in Italia ........................................................42

3.3 Gestione delle chiavi pubbliche .............................................................................46

3.3.1 Certificati digitali ...............................................................................................47

3.3.2 Certificati X509 .................................................................................................49

3.3.3 Smart card e Token USB....................................................................................53

3.3.4 Carta Nazionale dei Servizi ................................................................................54

3.4 Infrastruttura a chiave pubblica ...........................................................................55

3.4.1 Strutturazione delle PKI .....................................................................................57

3.4.2 I servizi di directory ...........................................................................................58

3.4.3 Liste dei certificati revocati ................................................................................59

4 Il servizio di autenticazione centralizzata: CAS 61

4.1 Strutturazione del sistema CAS ............................................................................63

4.2 Caratteristiche di CAS...........................................................................................64

4.3 Schemi di funzionamento del sistema CAS...........................................................67

4.3.1 Funzionamento di CAS in modalità diretta.........................................................67

4.3.2 Funzionamento di CAS in modalità proxy..........................................................70

4.4 La versione 3 del server CAS ................................................................................73

4.4.1 Limitazioni di CAS nelle versioni 1 e 2..............................................................73

4.4.2 CAS 3 ................................................................................................................74

4.5 Valutazioni sull’uso di CAS...................................................................................75

5 Integrazione del sistema CAS nell’Università di Parma 77

5.1 Strutturazione del servizio CAS nell’Università di Parma ..................................79

5.2 Il server LDAP: Lightweight Directory Access Protocol .....................................81

5.3 Integrazione di LDAP nel sistema CAS ................................................................82

1 Indice

7

6 Problematiche affrontate:

miglioramento del servizio di Autenticazione 83

6.1 Scelte progettuali ...................................................................................................85

6.2 Installazione componenti ......................................................................................86

6.3 Primo problema affrontato: gestione della scadenza password ...........................88

6.3.1 Modifiche al protocollo di autenticazione locale.................................................89

6.3.2 Tecniche risolutive adottate................................................................................90

6.3.3 Modifiche ai file sorgenti Java di CAS...............................................................92

6.3.4 Modifiche ai file di configurazione di CAS ........................................................96

6.3.5 Compilazione e installazione del pacchetto CAS..............................................100

6.4 Secondo problema affrontato: gestione dei certificati X509 ..............................101

6.4.1 Configurazione di Apache Tomcat per il supporto dei certificati X509.............102

6.4.1 Configurazione di CAS per il supporto dei certificati X509..............................105

6.4.3 Compilazione e installazione del pacchetto CAS con certificati X509 ..............111

6.4.4 Problemi con le Certification Revocation List ..................................................113

7 Conclusioni 115

7.1 Risultati ottenuti .................................................................................................115

7.2 Utilizzo dei nuovi servizi .....................................................................................116

7.3 Sviluppi futuri .....................................................................................................117

Bibliografia 119

Ringraziamenti 123

Indice delle figure 8

Indice delle figure

2.1 Modello generale di comunicazione cifrata tra A e B , con possibilità di intrusione...15

2.2 Modello di crittografia simmetrica ............................................................................17

2.3 Modello di crittografia asimmetrica ..........................................................................19

2.4 Autenticazione a due vie con protocollo challenge-response .....................................22

2.5 Autenticazione con centro di distribuzione chiavi KDC ............................................23

2.6 Protocollo di autenticazione Kerberos.......................................................................25

2.7 Mutua autenticazione con crittografia a chiave pubblica ...........................................27

2.8 Differenze tra autenticazione normale e centralizzata................................................33

3.1 Creazione di un documento firmato e cifrato.............................................................41

3.2 Principali differenza tra firma autografa e firma digitale ...........................................45

3.3 Struttura dello standard X509 per i certificati digitali ................................................50

3.4 Esempi di Smart Card, lettori e token USB ...............................................................53

3.5 Esempio di Carta Nazionale dei Servizi fornita dalla Cnipa ......................................54

4.1 Esempio di autenticazione distribuita prima e dopo l’introduzione di CAS ...............62

4.2 Esempi di plug-in di autenticazione per CAS ............................................................65

4.3 Schema di autenticazione CAS in modalità diretta ....................................................69

4.4 Schema di autenticazione CAS in modalità proxy.....................................................72

4.5 Catena di autenticazione tramite proxy .....................................................................72

5.1 Finestra di autenticazione CAS dell’Università di Parma ..........................................78

6.1 Pagina di conferma di avvenuta autenticazione riportante l’avviso di scadenza password ............................................................... 100

6.2 Certificato Digitale dell’Università di Parma in formato PEM ............................... 103

6.3 Esempio di autenticazione CAS tramite invio di un certificato digitale .................. 112

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.

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ù

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.

1.2 Aspetti sviluppati 12

1.2 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.

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

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.

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

2.1.1 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.

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 2128 ≈ 3 x 10 38 chiavi.

2.1.2 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.

2.1.3 Algoritmi a chiave simmetrica 17

2.1.3 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 DES1 (in disuso), triple DES (obsoleto, ma

ancora in uso), AES2, IDEA3.

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

1 http://it.wikipedia.org/wiki/Data_Encryption_Standard 2 http://it.wikipedia.org/wiki/Advanced_Encryption_Standard 3 http://it.wikipedia.org/wiki/International_Data_Encryption_Algorithm

2.1.4 Algoritmi a chiave pubblica 18

2.1.4 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 modo4:

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.

2.1.4 Algoritmi a chiave pubblica

19

Tra gli algoritmi più famosi possono citare RSA5, DSS6 e lo scambio di chiavi

Diffie-Hellman7.

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. http://it.wikipedia.org/wiki/RSA 6 http://it.wikipedia.org/wiki/Digital_Signature_Standard 7 http://it.wikipedia.org/wiki/Scambio_di_chiavi_Diffie-Hellman

2.2 Protocolli di autenticazione 20

2.2 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 KDC8.

Si susseguono vari scambi di messaggi nelle due direzioni, i quali possono

anche essere intercettati o modificati dall’intruso Trudy9.

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.

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.

2.2.1 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 nonce10 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. http://it.wikipedia.org/wiki/Nonce

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.

2.2.2 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.

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-Schroeder11

su cui si basa l’autenticazione con Kerberos, possono portare ad una soluzione.

Figura 2.5 Autenticazione con centro di distribuzione chiavi KDC

11 http://it.wikipedia.org/wiki/Protocollo_di_Needham-Schroeder

2.2.3 Autenticazione con Kerberos 24

2.2.3 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 MIT12, 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 accounting13, 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 ticket14 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

12 http://it.wikipedia.org/wiki/Massachusetts_Institute_of_Technology 13 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à.

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.

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.

2.2.4 Autenticazione con crittografia a chiave pubblica 27

2.2.4 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

2.3 Metodi di autenticazione

28

2.3 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.

2.3.1 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.

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.

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. http://it.wikipedia.org/wiki/Codice_PIN

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 e-mail 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

2.4 Autenticazione centralizzata SSO

32

2.4 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 LDAP16, 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.

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

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.

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

username17 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 http://it.wikipedia.org/wiki/Nome_utente

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’ICT18.

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 Point19 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.

18 http://it.wikipedia.org/wiki/Information_and_Communication_Technology 19 Policy Enforcement Point

3.1 Tipi di firme elettroniche 37

3.1 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.

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.

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 500.000, si è passati a circa

3.200.000 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

3.2.1 Creazione della firma digitale 40

3.2.1 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 hash21.

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 MD522 , e SHA-123.

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

21 http://it.wikipedia.org/wiki/Hash 22 http://it.wikipedia.org/wiki/MD5 23 http://it.wikipedia.org/wiki/Secure_Hash_Algorithm

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

3.2.2 Il valore legale della firma digitale in Italia 42

3.2.2 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 1997.

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

3.2.2 Il valore legale della firma digitale in Italia

43

firma digitale, doveva intentare una querela di falso24, 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. 2702

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 http://it.wikipedia.org/wiki/Querela_di_falso

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

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 2009. 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 Manuale Digitale, mediane apposito algoritmo

Apposizione Sul documento La firma è una sua parte integrante

e legata al supporto.

Allegata al documento La coppia (documento-firma) costituisce il documento.

Paternità Riconducibile al soggetto direttamente.

Riconducibile al soggetto tramite l’uso del suo PIN

privato e segreto.

Verifica Paternità Diretta e soggettiva,

attraverso il confronto con una firma autentica.

Indiretta e oggettiva attraverso un algoritmo di

verifica pubblico.

Contraffabilità documento copia

Agevolmente contraffabile, ma

facilmente riconoscibile.

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.

3.3 Gestione delle chiavi pubbliche 46

3.3 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.

3.3.1 Certificati digitali 47

3.3.1 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.

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 auto-

firmati, 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

SSL25.

Il certificato VPN26 è 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.

3.3.2 Certificati X.509 49

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.

3.3.2 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 OSI27, portandosi dietro però

anche qualcuna delle sue caratteristiche non migliori, come la nomenclatura e la

codifica. Però la IETF28, 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 e-mail. Questa versione approvata da IETF è

descritta in RCF328029.

Lo standard X509, creato dalla ITU30, fece il suo debutto nella sua prima versione

nel 1988, parallelamente allo standard X500 utilizzato per i servizi di directory31.

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 PGP32, dove chiunque poteva firmare e quindi certificare

la validità delle chiavi altrui.

27 http://it.wikipedia.org/wiki/Open_Systems_Interconnection 28 http://en.wikipedia.org/wiki/IETF 29 “Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile”, IETF, April 2002 30 International Telecommunication Union. http://www.itu.int 31 Un servizio di directory consente di dare dei nomi a degli oggetti e di associare a tali oggetti degli attributi 32 http://it.wikipedia.org/wiki/Pretty_Good_Privacy

3.3.2 Certificati X509

50

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-peer33, 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. http://it.wikipedia.org/wiki/Peer-to-peer

3.3.2 Certificati X.509

51

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.

3.3.2 Certificati X509

52

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 : e-mail 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.

3.3.3 Smart card e Token USB 53

3.3.3 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

3.3.4 Carta nazionale dei servizi 54

3.3.4 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 Cnipa34 è

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

3.4 Infrastruttura a chiave pubblica 55

3.4 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.

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

Request35). 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

3.4.1 Strutturazione delle PKI 57

3.4.1 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.

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.

3.4.2 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 DNS36, 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

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 e-mail, 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.500.

3.4.3 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.

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

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

java38, e può essere eseguito su di un servlet engine, seguendo le specifiche JSP39

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

37 http://www.yale.edu/ 38 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à. http://java.sun.com/products/servlet/ 39 JavaServer Pages, è una tecnologia Java per lo sviluppo di applicazioni Web che forniscono contenuti dinamici in formato HTML o XML.

4.1 Strutturazione del sistema CAS

63

4.1 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 Tomcat40, che utilizzi il protocollo HTTP41 e HTTPS42.

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 cookie43 e i

redirect Javascript44, anche se questa configurazione non è strettamente

necessaria per un corretto funzionamento del sistema CAS.

40 http://tomcat.apache.org/ 41 L'Hypertext Transfer Protocol (HTTP) è il protocollo di trasferimento per un ipertesto usato come principale sistema per la trasmissione di informazioni sul web. http://it.wikipedia.org/wiki/Hypertext_Transfer_Protocol 42 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. http://support.mozilla.com/it/kb/Gestione 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.

4.2 Caratteristiche di CAS

64

4.2 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.

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

plugin45 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 Directory46 (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. http://it.wikipedia.org/wiki/Plugin_(informatica) 46 Active Directory è un insieme di servizi di rete che implementano un servizio di directory. http://it.wikipedia.org/wiki/Directory_service

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-end47, o utilizzando un portale48, 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.

4.3 Schemi di funzionamento di CAS

67

4.3 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.

4.3.1 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ò

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

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.

4.3.2 Funzionamento di CAS in modalità proxy

70

4.3.2 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 multitier49, 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 IMAP50 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.

49 http://en.wikipedia.org/wiki/Multitier_architecture 50 Un server IMAP e il server a cui un client di posta elettronica si collega per scaricare la posta.

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.

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

4.4.1 Limitazioni di CAS nelle versioni 1 e 2 73

4.4 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.

4.4.1 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

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.

4.4.2 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 SAML51 2.0

per l'integrazione con Google Accounts52, 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 http://www.ja-sig.org/wiki/display/CASUM/SAML+2.0+(Google+Accounts+Integration)

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

Spring53, 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 JavaBeans54 (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

53 http://www.springsource.org/ 54 http://it.wikipedia.org/wiki/Enterprise_JavaBeans

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.

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.

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.

5.1 Strutturazione del servizio CAS nell’Università di Parma 79

5.1 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 Microsystems55,

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

55 http://java.sun.com/ 56 http://maven.apache.org/

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.

5.2 Il server LDAP: Lightweight Directory Access Protocol 81

5.2 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()

5.3 Integrazione di LDAP nel sistema CAS 82

5.3 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.

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,

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.

6.1 Scelte Progettuali 85

6.1 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.

6.2 Installazione componenti 86

6.2 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 6.0.18, 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

6.0.18. 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

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 “http://maven.apache.org/”.

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-2.1.0

export PATH=$M2:$PATH

A questo punto è possibile installare il server CAS. Qui è stata usata la versione

3.3.2 Final, scaricandola gratuitamente dal sito ufficiale all’indirizzo:

http://www.jasig.org/cas/download/cas-server-332-final

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.

6.3 Primo problema affrontato: Gestione della scadenza password 88

6.3 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 :

6.3 Primo problema affrontato: Gestione della scadenza password

89

E-mail istituzionale: è il parametro che identifica univocamente un account

sul server LDAP. È nella forma nome.cognome@studenti.unipr.it 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à.

6.3.1 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.

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.

6.3.2 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.

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 file57 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: http://www.ja-sig.org/wiki/spaces/listattachmentsforspace.action?key=CAS&fileExtension=&sortBy=date

6.3.3 Modifiche ai file sorgenti Java di CAS 92

6.3.3 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+

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);

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 due58 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()/86400000); // 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

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.

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

6.3.4 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 LDAP59, 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.

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" /> ...

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

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-Za- z][A-Za-z]_)?[A-Za-z][A-Za-z]|^locale=([A-Za-z][A-Za- z]_)?[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" />

6.3.5 Compilazione e installazione pacchetto CAS 100

6.3.5 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 .war60, 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).

6.4 Secondo problema affrontato: Gestione dei Certificati X509 101

6.4 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.

6.4.1 Configurazione di Apache Tomcat per il supporto dei certificati X509 102

6.4.1 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.

6.4.1 Configurazione di Apache Tomcat per il supporto dei certificati X509

103

Successivamente è stato creato il truststoreFile. Si è scelto come configurazione

iniziale di accettare certificati rilasciati direttamente dalla CA dell’Università di

Parma61, 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 http://www.cce.unipr.it/CA/

6.4.1 Configurazione di Apache Tomcat per il supporto dei certificati X509 104

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.

6.4.2 Configurazione di CAS per il supporto dei certificati X509 105

6.4.2 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>

6.4.2 Configurazione di CAS per il supporto dei certificati X509

106

<decision-state id="ticketGrantingTicketExistsCheck"> <if test="${flowScope.ticketGrantingTicketId != null}" then="hasServiceCheck" else="gatewayRequestCheck" /> </decision-state> <decision-state id="gatewayRequestCheck"> <if test="${externalContext.requestParameterMap['gateway'] != '' &amp;&amp; externalContext.requestParameterMap['gateway'] != null &amp;&amp; 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'] != '' &amp;&amp; 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>

6.4.2 Configurazione di CAS per il supporto dei certificati X509

107

<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 e-mail 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’.

6.4.2 Configurazione di CAS per il supporto dei certificati X509

108

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 e-mail. 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

6.4.2 Configurazione di CAS per il supporto dei certificati X509

109

corrisponda ad una delle sue entry, l’utente sarà univocamente identificato e verrà

ritornato come parametro il relativo attributo contenente il valore della e-mail, 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=25263647932548882251489395556682941778 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="EMAILADDRESS=ca_cce@unipr.it, CN=www.cce.unipr.it/CA, OU=Centro di Calcolo Elettronico, O=Universita degli Studi di Parma, L=Parma, ST=Parma, C=IT" /> </bean>

6.4.2 Configurazione di CAS per il supporto dei certificati X509

110

<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

6.4.3 Compilazione e installazione del pacchetto CAS con certificati X509 111

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à GARR62: 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.

6.4.3 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 http://www.garr.it/

6.4.3 Compilazione e installazione del pacchetto CAS con certificati X509

112

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 e-mail 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.

6.4.4 Problemi con le Certification Revocation List 113

6.4.4 Problemi con le Certification Revocation List Purtroppo il sistema qui presentato non ha ancora implementato un servizio per

la gestione delle liste di revoca dei certificati, quindi come controllare che un

certificato al momento della sua presentazione, non sia stato revocato. Questo

deriva dal fatto che attualmente non sono state fatte scelte relative a quale strategia

utilizzare: la strategia sincrona o quella asincrona.

Nella prima strategia si può pensare di configurare l’intero sistema affinché

questi controlli nello stesso istante dell’autenticazione, che il certificato

presentatogli dall’utente non sia nelle liste di revoca della CA associata,

connettendosi ad essa attraverso lo specifico protocollo OCSP, quindi in modo

sincrono rispetto all’autenticazione.

Utilizzando invece la seconda strategia, ovvero quella asincrona, si può pensare di

programmare il sistema affinché scarichi quotidianamente le liste di revoche dalla

CA e le memorizzi ad esempio su LDAP. Durante l’autenticazione utente il server

LDAP dovrebbe solamente effettuare una veloce ricerca, ricercando nella propria

lista se il certificato presentato dall’utente sia stato revocato.

Queste due strategie hanno entrambe vantaggi e svantaggi. La prima ha come

grande vantaggio una migliore sicurezza, infatti il sistema riconosce

immediatamente se il certificato è stato revocato o sospeso. Per contro si ha che

l’intero protocollo di autenticazione risulta notevolmente appesantito, tanto è vero

che si deve attendere la risposta della CA prima di proseguire, ed inoltre il traffico

in rete aumenta considerevolmente.

La seconda strategia invece ha come maggior pregio la leggerezza del protocollo

ed il minor traffico in rete. Difatti il sistema si connette alla CA solo in momenti

prefissati per aggiornare i dati sulle liste di revoca, e la successiva ricerca locale sul

server LDAP è molto snella e veloce. A sfavore invece si può notare un rilevante

calo della sicurezza del sistema. Precisamente il possibile intruso potrebbe

attaccare nel periodo di tempo che intercorre l’aggiornamento della lista locale.

Riducendo questo lasso di tempo, i rischi di un possibile attacco diminuirebbero,

però si appesantirebbe nuovamente il traffico in viaggio sulla rete. È quindi

necessaria un attenta riflessione e decidere quale di queste due strategie utilizzare.

Capitolo 7

Conclusioni

7.1 Risultati ottenuti

Al termine dello studio degli argomenti trattati e della loro possibile applicazione

in uno scenario concreto come quello di una struttura universitaria si può

affermare che gli obbiettivi preposti all’inizio sono stati raggiunti.

I miglioramenti proposti infatti affrontano il problema della sicurezza in maniera

ottimale, sia per quanto riguarda la modalità di autenticazione tramite username e

password, che per quella più innovativa ovvero tramite i certificati digitali.

Tanto è vero che l’integrazione del sistema attuale col servizio di gestione per la

scadenza della password porta notevoli vantaggi in termini di affidabilità e

protezione degli account dell’Ateneo, a scapito di una perdita di tempo non

superiore ai tre minuti da parte degli utenti per cambiarsi la password in media

ogni 180 giorni.

Anche l’introduzione della nuova modalità di autenticazione tramite certificati

digitali porterà grandi benefici in merito a comodità e soprattutto efficienza del

sistema. Per quanto riguarda la sicurezza, la strutturazione del servizio qui

7.2 Utilizzo dei nuovi servizi

116

proposta non potrebbe essere migliore, anche se come già riportato solo i soggetti

aderenti a questa Università possono servirsene.

Inoltre un aspetto da non sottovalutare, è la possibilità per l’utente che intenda

usufruire delle applicazioni offerte, di avere una totale trasparenza durante il

protocollo di autenticazione, se questi avrà semplicemente settato il browser per

inviare automaticamente il proprio certificato digitale.

7.2 Utilizzo dei nuovi servizi

Il sistema qui presentato è stato testato all’Interno del S.I.T.I con buoni risultati

per quanto riguarda entrambi i miglioramenti proposti. In particolare il servizio di

gestione della scadenza password potrebbe essere inserito nell’attuale modalità di

autenticazione già da quest’anno, portando i benefici già trattati.

Anche il secondo miglioramento presentato potrebbe essere attivato a breve,

anche perché l’Università già dispone di una CA per la richiesta ed il rilascio dei

certificati digitali.

Un possibile scenario d’uso di quest’ultima modalità, sarebbe quella di fornire

agli utenti che lo richiedessero, una smart card o un token USB contenente il

proprio certificato digitale. Lo studente, il docente, o qualsiasi persona del

personale strutturato, potrebbero accedere a qualsiasi computer sparso tra i vari

dipartimenti in maniera veloce, comoda e soprattutto affidabile, e allo stesso modo

potrebbero anche autenticarsi dal PC di casa o quello di un internet café, sempre in

totale sicurezza e garanzia di protezione dei propri dati e informazioni personali.

Inoltre i cambiamenti da effettuare alle varie configurazioni per supportare

anche utenti estranei all’Ateneo per esempio appartenenti alla comunità GARR,

sarebbero minimi, anche se si dovrebbe però integrare il servizio CAS con il

sistema Shibboleth, progetto per il quale l’Università si sta peraltro attrezzando.

7.3 Sviluppi futuri

117

7.3 Sviluppi futuri

Gli scenari riguardanti le possibili evoluzioni di questo progetto riguardano senza

ombra di dubbio la modalità di autenticazione tramite certificati digitali.

Difatti l’ormai collaudata metodologia di accesso tramite username e password

integrata al servizio della relativa scadenza qui proposto, difficilmente potrà essere

nuovamente migliorata, a meno di un cambio generale del protocollo e dell’intero

sistema di autenticazione stesso.

Invece la continua espansione dei certificati X509 renderà questa tipologia di

accesso ai servizi dell’Università sempre più importante, sia per la sicurezza locale

qui ampiamente affrontata, ma anche per la possibilità di interagire con soggetti ed

enti esterni all’Ateneo. Ma come quasi sempre accade, l’ampliamento di un servizio

porta all’introduzione di ulteriori problematiche annesse. Si dovrà quindi

pianificare accuratamente lo scenario al quale si vorrà arrivare, tenendo anche

conto dei costi e soprattutto dei rischi che questi miglioramenti porteranno.

Una ulteriore tematica che potrebbe essere analizzata sarebbe quella relativa alle

già citate liste di revoca dei certificati. Ma per quello appena detto, varrebbe la

pena di affrontare questo problema nello stesso momento in cui si deciderà di

“aprire le porte” al mondo esterno.

Bibliografia [1] Reti di Calcolatori, A Tanenbaum.

[2] Internet e reti di calcolatori, J Kurose W Ross.

[3] Sun Microsystems,

http://java.sun.com/.

[4] Apache Tomcat,

http://tomcat.apache.org/.

[5] Community developed LDAP software,

http://www.openldap.org/.

[6] Apache Maven Project,

http://maven.apache.org/.

[7] Central Authentication Service,

http://www.ja-sig.org/.

http://www.ja-sig.org/wiki/display/CASUM/Home/.

http://dsg.ce.unipr.it/.

[8] Informazioni generali,

http://it.wikipedia.org/.

http://whatis.techtarget.com/.

Bibliografia

120

[9] Protocollo Kerberos,

http://www.kerberos.org/.

http://www.amagri.it/sicurezza_ms_windows/metodi_autenticazione/-

kerberos/kerberos.html/.

http://www.zeroshell.net/kerberos/.

[10] Identità e firma digitale,

http://www.cnipa.gov.it/.

http://www.twt.it/newsletter/html/firme.asp/

http://www.interlex.it/testi/dlg05_82.htm/.

[11] Manca G L’identità digitale per l’accesso ai servizi ed alle informazioni

in rete.

http://www2.cnipa.gov.it/site/_contentfiles/_L’identità digitale per-

l’accesso ai servizi ed alle informazioni in rete.pdf

[12] Centro nazionale per l’informatica nella pubblica amministrazione (CNIPA)

Guida alla Firma Digitale.

http://www.cnipa.gov.it/html/docs/GuidaFirmaDigitale2009_a.pdf

[13] Carta Nazionale dei Servizi,

http://www.cnipa.gov.it/site/it-it/Attività/Firma_digitale/-

Certificatori_accreditati/Carta_Nazionale_dei_Servizi/.

[14] Certificati digitali,

http://it.kioskea.net/contents/crypto/certificat.php3/.

http://en.tech-faq.com/x.509.shtml/.

http://www.zeroshell.net/x509details/.

http://www.cce.unipr.it/CA/.

[15] Infrastruttura a chiave pubblica PKI,

http://it.kioskea.net/contents/crypto/pki.php3/.

Bibliografia

121

[16] Sun Microsystems Java Servlet,

http://java.sun.com/products/servlet/.

[27] Sun Microsystems, Java Web Start Technology,

http://java.sun.com/products/javawebstart/.

[18] Howes, T.A. The Lightweight Directory Access Protocol: X.500 Lite,

CITI Technical Report 95-8, July 1995.

http://www.openldap.org/pub/umich/ldap.pdf.

[19] Lo biondo G. Gestione centralizzata delle utenze tramite LDAP

http://security.fi.infn.it/conferenze/fi00/ldap.pdf

[20] Apache Software Foundation Apache Maven Current version User Guide

http://maven.apache.org/apache-maven.pdf

[21] Internet2 - Home,

http://www.internet2.edu/.

[22] Comunità GARR,

http://www.garr.it/.

[23] Progetto Shibboleth,

http://shibboleth.internet2.edu/.

[24] IETF Internet Engineering Task Force,

http://www.ietf.org/.

[25] International Telecommunication Union,

http://www.itu.int/.

Ringraziamenti

Il ringraziamento più grande non può che andare ai miei genitori e ai miei nonni

per avermi concesso questi anni di studio, sostegno e appoggio morale, senza i

quali non avrei potuto intraprendere questa carriera universitaria.

Un particolare grazie a mia nonna sempre presente, che non si è mai arresa e mi

ha appoggiato e incitato costantemente, soprattutto nei momenti più bui di questo

percorso.

Un más sincero agradecimiento a mi novia Maider, por ser venido en Italia y

haberme estado siempre cerca, y tambien a su padres que le han permitido de irse

aqui conmigo.

Un grazie anche al professor Roberto Alfieri mio relatore e Marco Panella mio

correlatore, che mi hanno aiutato in questo lavoro di Tesi e sono stati sempre molto

disponibili.

Ringrazio anche tutti i miei amici, compagni di Università e di casa qui a Parma,

con i quali ho passato dei bellissimi momenti durante il periodo di studi.

Matteo Sironi