UNIVERSITÀ DI PISA
Facoltà di Ingegneria
Corso di Laurea Magistrale in Ingegneria Informatica
Gestione efficiente delle identità e degli
accessi mediante SSO ed OpenAM
Relatori:
Prof. Gianluca Dini
Prof. Francesco Marcelloni
Candidato:
Stefano Cinardi
“Alla mia famiglia, che mi ha sostenuto e che ha creduto in me”
Indice
I Introduzione
1
1 Autenticazione e autorizzazione 1
1.1 Autenticazione . . . 2
1.1.1 Sistemi SYK (Something you know) . . . 3
1.1.2 Sistemi SYH ( Something You Have) . . . 4
1.1.3 Sistemy SYA (Something You Are) . . . 5
1.2 Autorizzazione . . . 6
1.3 Basic Authentication VS Strong Authentication . . . 7
2 Il lavoro svolto 8 3 Aspetti sviluppati 9 4 Strumenti Utilizzati 9
II Stato dell’arte
10
III SSO
12
1 Le sfide del Single Sign-On 12 2 Perchè investire sul SSO 13 3 Protocolli Single Sign-On 14 3.1 Kerberos . . . 143.1.1 Obiettivi . . . 14
3.1.2 Definizioni . . . 15
3.1.3 Funzionamento . . . 18
3.2 SAML 2.0 . . . 21 3.2.1 Definizioni . . . 22 3.2.2 Architettura generale . . . 25 3.2.3 Vantaggi . . . 28 3.3 OAuth 2.0 . . . 28 3.3.1 Client-Server vs OAuth . . . 29 3.3.2 Terminologia . . . 29 3.3.3 Funzionamento . . . 31 3.4 Policy Agent . . . 35
IV Forgerock & OpenAM
37
1 Un pò di storia 37 2 SSO in OpenAM 37 3 Installazione OpenAM 38 3.1 Predisposizione del software necessario . . . 393.1.1 JDK 6 . . . 39
3.1.2 Apache Tomcat 7 . . . 40
3.1.3 OpenAM 10.1.0 . . . 43
3.2 Configurazione OpenAM . . . 43
4 Creazione ed installazione modulo di autenticazione personalizzato IambOOTP 44 4.1 IambOOTP . . . 44
4.1.1 Vantaggi . . . 44
4.1.2 Semplicità . . . 44
4.1.3 Sicurezza . . . 45
4.2 Riconoscimento codice attivazione mediante QRCode . . . 45
5 DataStore 50
5.1 LDAP . . . 50
5.2 Database Relazionali . . . 51
V Demo aziendale
52
1 Configurazione Ambiente di Lavoro 52 1.1 Installazione Windows Server 2008 RC . . . 521.2 Creazione dominio Active Directory . . . 52
1.3 Inserimento computer aziendali all’interno del dominio . . . 52
1.4 Configurazione moduli di autenticazione in OpenAM . . . 53
1.4.1 Windows Desktop SSO . . . 53
1.4.2 Creazione Data Store Active Directory in OpenAM . . . 54
1.4.3 Integrazione Kerberos, Active Directory e OpenAM . . . 54
2 Integrazione SugarCRM 59 2.1 Prerequisiti . . . 60 2.1.1 Apache2 . . . 60 2.1.2 PHP5 . . . 60 2.2 SugarCRM . . . 60 2.3 SimpleSamlPhp . . . 61 2.3.1 Installazione . . . 62 2.4 Configurazione OpenAM . . . 63
2.4.1 Impostazione OpenAM come Identity Provider . . . 63
2.4.2 Impostazione SimpleSamlPhp come Service Provider . . . 64
2.4.3 Impostazioni SAML . . . 65
2.4.4 Impostazione OpenAM come Remote Identity Provider su Sim-pleSamlPhp . . . 68
2.4.5 Test integrazione OpenAM - SimpleSamlPhp . . . 70
3 Integrazione Google Apps 71
3.1 Creazione account Google Apps . . . 72
3.2 Creazione Identity Provider . . . 73
3.3 Creazione Service Provider . . . 73
4 Integrazione servizi interni mediante Policy Agent 76 5 Conclusione e Sviluppi futuri 78
VI Ringraziamenti
79
VII Listati
80
1 Modulo di autenticazione IambOOTP 80 1.1 SampleAuth.java . . . 80 1.2 SampleAuthPrincipal.java . . . 84 1.3 JdbcConnect.java . . . 85 1.4 SampleAuth.xml . . . 87 1.5 amAuthSampleAuth.xml . . . 88 1.6 amAuthSampleAuth.properties . . . 89 1.7 Config.cfg . . . 89 2 SugarCRM 90 2.1 Login.php . . . 90 2.2 Logout.php . . . 92VIII Bibliografia
95
Parte I
Introduzione
Sin dalla nascita dei primi sistemi informatici si è avvertita la necessità di renderli capa-ci di accertare l’identità di un utente (persona fisica, hardware, software, o applicativo che sia) che desideri accedere ai loro servizi. Il procedimento attraverso il quale un utente viene riconosciuto da un sistema prende il nome di autenticazione. Storicamen-te già i primi sisStoricamen-temi di elaborazione a schede perforaStoricamen-te utilizzavano un’auStoricamen-tenticazione basata sull’uso di credenziali formate da username e password. Tali tecniche, in realtà, certificano soltanto che la persona che accede al sistema conosce delle informazioni se-grete legate ad un certo account, senza affermare niente riguardo all’identificazione. Un primo passo per cercare di realizzare una forma di autenticazione che fornisca garanzie anche riguardo all’identificazione è stato quello dei sistemi biometrici, come la lettura dell’iride, l’impronta digitale ed il riconoscimento vocale. Purtroppo queste tecniche presentano delle probabilità di errore ancora troppo elevate per poter essere impiegate all’interno di “sistemi sicuri”.
Con lo sviluppo di Internet e della rete globale il problema dell’autenticazione ha as-sunto un ruolo centrale grazie allo sviluppo dell’e-commerce e più in generale delle transazioni sul web. In questi frangenti il problema di autenticazione cresce poiché l’utente deve essere identificato dal server prima che questo rilasci i servizi e lo stesso utente chiede di sapere l’identità esatta del server prima di effettuare un’operazione (pagamento elettronico, inserimento di dati sensibili, inserimento di dati identificativi). Lo sviluppo di nuove tecnologie e la diffusione delle reti hanno, quindi, richiesto una nuova evoluzione delle tecnologie per l’identificazione.
1 Autenticazione e autorizzazione
Un sistema IAM ( Identity and Access Management ) è una soluzione tecnologica alle problematiche di gestione del ciclo di vita delle identità digitali e degli accessi di uten-ti su più sistemi informauten-tici. In un’organizzazione complessa ed eterogenea gli utenuten-ti lavorano su più sistemi, ciascuno con una propria modalità di identificazione ed auten-ticazione. Questa indipendenza tra loro prevede che ognuno di essi possieda un proprio database utenti e proprie politiche di gestione delle identità digitali. Senza un sistema
IAM bisognerebbe gestire gli utenti e le politiche di accesso per ogni singolo sistema; ciò comporterebbe perdita di tempo da parte degli amministratori che si ritroverebbero ad eseguire le stesse operazioni su tutti i sistemi. Ad esempio, un semplice cambio di indirizzo email di un utente dovrebbe essere eseguito su tutte le identità, con conseguen-te perdita di conseguen-tempo e difficoltà di gestione. Un sisconseguen-tema IAM metconseguen-te a disposizione un unico punto di gestione per amministrare gli accessi e gli utenti, rendendo queste ope-razioni rapide e sicure. Il sistema, inoltre, implementa la funzionalità di Single Sign-On (SSO), che permette di autenticarsi ad altri sistemi, senza dover ripetere la procedura di riconoscimento di ogni singola risorsa.
1.1 Autenticazione
L’autenticazione è un processo mediante il quale un computer o un software verifica la corretta identità dell’utente che vuole accedervi.
Le procedure di autenticazione, ossia le procedure utilizzate dai processi per verificare l’identità dell’utente, si basano in genere sull’immissione di una password e si possono suddividere in tre classi:
• Autenticazione a senso unico; • Autenticazione a due sensi;
• Autenticazione con una terza parte.
Si può parlare di autenticazione a senso unico nel caso in cui un utente desidera accedere a un’applicazione host; soltanto l’utente sarà autenticato all’applicazione, mentre l’ap-plicazione non si dovrà autenticare all’utente. La procedura di autenticazione richiede quindi l’immissione dell’username e password solo da parte dell’utente; l’applicazione host verifica la password corrispondente all’username immesso e identifica l’utente. Nell’autenticazione a due sensi, invece, le parti interessate devono autenticarsi a vicenda. A causa di alcuni problemi pratici, questo tipo di autenticazione è poco comune. Si consideri ad esempio una rete in cui siano presenti 50 utenti o applicazioni e dove tutti gli utenti sono in grado di comunicare tra loro. Su una rete di questo tipo, ciascun utente deve avere la possibilità di autenticare qualsiasi altro utente e poiché, per motivi di sicurezza, ciascun utente deve disporre di una propria password, ogni utente deve memorizzare una password per ciascun altro utente: nel nostro esempio 49 password.
Appare evidente come la manutenzione delle password in un sistema a due sensi risulti estremamente pesante e inefficiente. La naturale evoluzione dell’autenticazione a due parti è costituita dall’introduzione di una parte terza a cui concedere fiducia, che ha lo scopo di memorizzare tutte le password. La terza parte, detta Key Distribution Center (KDC), è quindi l’unico luogo di memorizzazione delle password. Per effettuare l’autenticazione ogni utente o applicazione deve quindi inviare username e password alla KDC. Oltre a semplificare le operazioni di memorizzazione e manutenzione delle password, questo metodo consente di aumentare la sicurezza del sistema. Questo perchè le password non sono mai trasferite sulla rete e memorizzate sulle stazioni di lavoro client. Solo il KDC quindi detiene la fiducia di tutti. Nella maggior parte dei casi un KDC non fa distinzione tra utenti e host, o meglio tra programmi server e host. Tratta tutti come principal, entità distinte che condividono un segreto (una key crittografica) con il KDC. Il KDC è in grado di verificare l’identità di un principal basandosi sulla conoscenza del suo segreto. Questa conoscenza gli permette anche di identificare un principal da un altro senza divulgare il segreto di nessuno dei due.
Da sempre esistono tre possibili tecniche mediante le quali è possibile identificare utenti e host:
• Attraverso "something you know" (SYK), "quello che sai"; • Attraverso "something you have" (SYH) "quello che possiedi". • Attraverso "something you are" (SYA), ossia "quello che sei"; 1.1.1 Sistemi SYK (Something you know)
Username/Password I meccanismi di autenticazione basati su username e password sono di gran lunga i metodi di autenticazione più comuni basati sulla conoscenza e quelli più utilizzati per i sistemi informatici; del resto rappresenta l’elemento su cui si basa-vano i primi sistemi di identificazione digitale. Tuttavia è riconosciuta la loro relativa debolezza, in particolare per quanto attiene alle politiche di gestione e di conservazio-ne, la cui complessità rischia spesso di inficiare l’affidabilità e l’utilizzabilità del sistema stesso.
L’utente digita username e password sul form di autenticazione: queste sono trasmesse in chiaro attraverso la rete. Il computer confronta i dati immessi con quelli memorizzati
sul server di validazione e, in caso di successo, l’utente accede altrimenti gli viene negato l’accesso.
La nozione della password si basa su un ossimoro: l’idea è avere una stringa casuale che sia semplice da ricordare. Sfortunatamente se è semplice da ricordare, si tratta di qualcosa di non casuale, come “Alice”. Però se la stringa è casuale, come ad esempio “g034_9sl2”, non è semplice da ricordare. Tanto poco sicure sono le password, per di più gli utenti riusciranno a renderle ancor meno sicure. Se si chiede ad un utente di scegliere una password, ne sceglierà una semplice; se lo si costringe a sceglierne una più difficile, la scriverà su un foglietto che apporrà sul monitor del computer. Se gli si chiede di cambiarla, sceglierà la password che aveva usato il mese precedente. Inoltre gli utenti sceglieranno la stessa password per più applicazioni. Molti studi sulle password confermano le statistiche secondo le quali il 16% delle password hanno tre caratteri o meno e l’86% è facilmente rintracciabile. Un sistema con password lunghe e forti può essere sicuro. Ma tutto questo sta cambiando; la legge di Moore dice che la password forte di oggi è la password debole di domani. In generale, se un sistema è basato sulle password ed un hacker può realizzare un attacco di dizionario, allora il sistema è vulnerabile.
L’attacco di tipo dizionario può essere prevenuto. Un trucco è trovare un dizionario più grande. Un altro consiste nell’aggiungere numeri casuali alle password, trucco conosciuto come “salting”.
Le password continuano ad essere il sistema di autenticazione più utilizzato oggi al mondo in quanto sono semplici da usare, non richiedono alcun hardware o programma-zione particolare. Per effetto di questa popolarità molti utenti hanno una dozzina di password da ricordare ogni giorno, inclusi PIN o password di accesso ai bancomat, alle carte telefoniche, ai sistemi di voice-mail, e poi ancora per sbloccare telefoni cellulari, sbloccare computer, per accedere a servizi Internet, per scaricare la posta elettronica etc.
1.1.2 Sistemi SYH ( Something You Have)
Token Un token di autenticazione può avere differenti caratteristiche che dipendono dal fornitore e dal metodo di autenticazione utilizzato:
• un piccolo dispositivo con solo un display LCD. Gli utenti li preferiscono spesso perchè più difficili da dimenticare o da smarrire;
• un assistente digitale personale (PDA) o uno smart phone con il software del fornitore.
Più fornitori usano un protocollo standard di autenticazione, basato sullo standard ANSI X9.9 per i MACs, mentre alcuni usano un protocollo proprietario. Alcuni fornitori offrono soltanto un metodo di autenticazione, altri ne offrono molteplici. Tutte queste modalità si basano sulla crittografia a chiave segreta: il token dell’utente ed il server di autenticazione hanno una chiave segreta condivisa che viene utilizzata per criptare alcuni dati, dipendenti dal metodo, che servono a generare l’OTP. I veri token usano un orologio od un contatore e qualche volta entrambi per generare l’OTP; il token combina l’orologio od il valore del contatore con la chiave segreta condivisa per generare l’OTP, un codice casuale e non prevedibile.
Il problema più serio con questo sistema è che i token possono essere rubati. Se qualcuno ruba le chiavi di casa, ad esempio, può aprire la casa. Così il sistema non autentica realmente la persona; esso autentica il token; la maggior parte dei computer combinano i token di accesso con password proprio per superare questa vulnerabilità.
1.1.3 Sistemy SYA (Something You Are)
L’autenticazione SYA è applicabile agli esseri umani. Si ottiene mediante la biometria, un’insieme di tecniche che permettono di misurare delle caratteristiche biologiche o dei fenomeni fisici. L’analisi delle impronte digitali, la scansione della retina, e il riconosci-mento della voce o della calligrafia ne sono degli esempi. Uno dei principali vantaggi della biometria si basa sul fatto che le caratteristiche che vengono misurate non pos-sono essere prese da altri, rubate o trovate e pos-sono molto difficili, se non impossibili, da copiare. Inoltre gli scopi delle tecniche biometriche sono essenzialmente due. Per prima cosa devono impedire che un’impostore possa accedere al sistema sotto le spoglie di un utente legittimo. In questo caso si parla di falso positivo. In secondo luogo, gli utenti legittimi non devono essere identificati come impostori. In questo caso si parla di falso negativo. Nel corso degli anni le tecniche di riconoscimento dei falsi positivi e dei falsi negativi sono molto migliorate ed, in generale, è possibile impostare un mar-gine di errore per i falsi positivi e i falsi negativi. Si tratta di una questione piuttosto delicata in quanto tutto dipende se il sistema è più disposto a tollerare i falsi negativi o i falsi positivi. E’ ovvio pensare che un sistema che si limita ad autorizzare gli utenti a prelevare materiale di cancelleria è più disposto a tollerare i falsi negativi rispetto a
un sistema che avvia la sequenza di lancio di una testata nucleare. Il fatto di dover impostare questo margine di errore è sicuramente un limite di questo tipo di autentica-zione; un dispositivo troppo tollerante potrebbe autenticare infatti anche un impostore, mentre uno con scarsa tolleranza potrebbe rifiutare un utente valido. Un altro limite è che solitamente le apparecchiature per le misurazioni biometriche hanno prezzi ecces-sivi per essere applicati sulla maggior parte dei desktop, possono infatti costare anche migliaia di dollari. Per questi motivi al giorno d’oggi le tecniche di autenticazione SYA non sono disponibili per un uso generalizzato su Internet.
Di seguito si esporranno solo quei sistemi di autenticazione che sono stati studiati e utilizzati nello svolgimento del progetto di tesi.
1.2 Autorizzazione
L’autorizzazione è l’operazione che completa la fase di autenticazione. Un utente è au-tenticato quando, fornendo delle credenziali, è riuscito a garantire la propria identità. Ma l’autenticazione in quanto tale è un mezzo e non un fine, ci si autentica per poter svolgere una qualche attività non liberamente fruibile. In un sistema informatico gene-ralmente sono disponibili più servizi e gli utenti che possono accedervi sono molteplici; inoltre è probabile che non tutti gli utenti abbiano uguali caratteristiche; in generale vi sono utenti che hanno la possibilità di accedere ad alcuni servizi mentre altri sono loro preclusi; basti pensare alla distinzione tra utente ed amministratore, l’utente sarà autorizzato ad effettuare un ristretto insieme di operazioni rispetto all’amministratore. Per una gestione sicura di un sistema informatico è necessario gestire i permessi dei singoli utenti.
Il controllo degli accessi consiste nel garantire che tutti gli accessi agli oggetti del sistema informativo avvengano esclusivamente secondo modalità prestabilite. Esso può, quindi, essere visto come un sistema caratterizzato da soggetti (utenti, processi) che accedono ad oggetti (applicazioni, dati, programmi) mediante operazioni (lettura, aggiornamento, esecuzione). Funzionalmente è costituito da:
• un insieme di politiche e di regole di accesso che stabiliscono le modalità (lettura, aggiornamento, etc.) secondo le quali i vari soggetti possono accedere agli oggetti; • un insieme di procedure di controllo (meccanismi di sicurezza) che controllano se la richiesta di accesso è consentita o negata, in base alle suddette regole (validazione della richiesta).
1.3 Basic Authentication VS Strong Authentication
L’accesso alle risorse avviene generalmente tramite la cosiddetta “Basic Authentica-tion”, ossia il processo nel quale il server di autenticazione richiede una coppia user-name/password, il client la invia, tipicamente attraverso un canale SSL e, se il server la trova nel suo database locale, l’utente viene autenticato ed autorizzato ad utilizzare determinate risorse. Questo implica che il suddetto processo di autenticazione venga ripetuto ogni qualvolta un utente richieda di utilizzare una diversa risorsa. È immedia-to immaginare quanimmedia-to il procedimenimmedia-to possa essere tedioso (e insicuro!) per un utente con diversi accessi a diverse risorse, e ancor più per gli amministratori dei sistemi, che vengono in qualche modo obbligati a ricordare o trascrivere la propria lista di user-name/password. L’obiettivo a cui una struttura dovrebbe tendere è quello di fornire all’utenza gli strumenti per l’accesso trasparente e sicuro ad ogni risorsa, semplificando la gestione di tali processi da parte degli amministratori dei sistemi. In altre parole, implementare un meccanismo di Single Sign-on.
Il Single Sign-on (SSO) :
• è un meccanismo che consente all’utente di autenticarsi una sola volta, ovvero di utilizzare un’unica credenziale per avere accesso a tutte quelle risorse per cui è autorizzato.
• prevede che la parte client di un sistema venga riconosciuta solo una volta nel corso di una sessione al momento di accesso ad una applicazione basata su server: questa abilitazione iniziale offre all’utente la possibilità di accedere a tutti i server a cui il client è autorizzato dall’amministratore, senza quindi bisogno di effettuare successivi login.
I vantaggi di un tale approccio sono evidenti, in modo particolare considerando i tem-pi e i costi di amministrazione dell’utenza. Avere un punto centralizzato di gestione dell’utenza facilita quelle operazioni di creazione, ricerca, modifica e cancellazione, nor-malmente richieste in questo contesto. D’altro canto, il fatto che un’unica credenziale permetta di accedere ad un alto numero di risorse può essere considerato come una debolezza dal punto di vista della sicurezza; secondo una definizione proposta da Cryp-tonet5, il passo da singolo punto di accesso (single point of access) e singolo punto di attacco (single point of attack) è breve. Per questo motivo può essere necessario affiancare al meccanismo di Single Sign-on un sistema di autenticazione più sicuro.
Il passo successivo consiste nell’introdurre una forma più forte, e sotto alcuni aspetti più flessibile, di autenticazione: la “Strong Authentication” . La “Strong Authentication” si basa su meccanismi di autenticazione che garantiscono l’appartenenza di determi-nate credenziali ad un’identità fisica. Un esempio è l’utilizzo dei certificati digitali, anziché username e password. Un certificato identifica univocamente un’entità digitale, tipicamente un utente o un server, laddove una Certification Authority garantisce l’as-sociazione tra entità digitale ed entità reale. Il fornitore di un servizio (server) è sicuro dell’identità di chi lo richiede (client) ed il client è certo di contattare effettivamente il server voluto. Sarà sufficiente l’invio, da parte del client, del certificato e di dati firmati con chiave privata, affinché il server, dopo averli decodificati con la chiave pubblica del client, possa autenticarlo. L’utente potrà accedere ad ogni risorsa senza inserire nessuna password, la sua identità sarà garantita dal certificato, così come l’integrità dei dati dalla sua firma digitale. Un altro esempio di “Strong Authentication” è la “Two Factor Authentication” . Il concetto sottostante la “Two Factor Authentication” è che il richiedente (client) ottiene riconoscimento e l’accesso a determinate risorse solo se presenta certe credenziali costituite da due elementi: un qualcosa che “POSSIEDE” (il Token) e un qualcosa che si “CONOSCE” (il PIN). E’ lo stesso meccanismo utilizzato quotidianamente per il prelievo dallo sportello Bancomat: si utilizza qualcosa che si ha (la carta Bancomat) e qualcosa che conosciamo (il codice segreto o PIN). Nei token più evoluti questa combinazione di PIN + passcode (generato dal token) è valida solo per un particolare utente in un determinato momento (per 60 secondi).
2 Il lavoro svolto
Gli argomenti di questa tesi saranno discussi in 5 capitoli:
• Capitolo 2: Stato dell’arte. Saranno illustrate le soluzioni più rappresentative attualmente esistenti.
• Capitolo 3: Sarà discusso ampiamente il Single Sign-On, le alternative proposte, le problematiche che esso comporta e i vantaggi che apporta.
• Capitolo 4: Sarà presentato il prodotto OpenAM di Forgerock, come nasce e come si utilizza.
• Capitolo 5: Saranno illustrate le diverse fasi di sviluppo del progetto fino alla sua ultimazione.
• Capitolo 6: Sarà illustrato il codice utilizzato in fase di sviluppo del progetto. Il presente lavoro effettua un’esplorazione delle possibilità offerte nel campo del Single Sign-On (SSO) mediante l’utilizzo del software open-source OpenAM fornito da For-gerock e ad una commercializzazione del prodotto per la semplificazione della gestione delle identità e degli accessi in sicurezza per le aziende.
3 Aspetti sviluppati
Prima di entrare nel dettaglio del progetto realizzato è stato effettuato uno studio approfondito degli standard, delle applicazioni e delle tecnologie disponibili necessarie alla sua realizzazione. Lo studio è stato rivolto inizialmente alle caratteristiche generali dell’Autenticazione e Autorizzazione e dei loro vantaggi, della Strong Authentication, per poi spostarsi sul Single Sign-On, sulle sue caratteristiche e sui differenti protocolli utilizzabili per la sua implementazione.
4 Strumenti Utilizzati
Per sviluppare il progetto sono stati scelti strumenti rigorosamente Open Source fra cui i seguenti:
• Debian: sistema operativo open-source, versione 7; • Java: fornito da Oracle, versione 7;
• PHP: versione 5;
• OpenAM: fornito da Forgerock, versione 10.1.0.0; • Apache2: fornito da the Apache Software Foundation; • Tomcat: versione 7.
• VMware ESXi, per la gestione delle macchine virtuali. • Windows Server 2008 RC.
Parte II
Stato dell’arte
Il modo in cui l’uomo si interfaccia con la tecnologia è importante oggetto di ricerca e sviluppo nel campo accademico, in quello industriale e, ovviamente, anche nelle sempre più organizzate e vaste comunità di amatori e sviluppatori di software libero. Alcuni esempi di aziende che forniscono applicazioni SSO, con licenza commerciale e non, sono: • OpenSSO (Open Single Sign On), progetto open source rilasciato da Sun nel 2008. Tuttavia, dopo l’acquisizione da parte di Oracle, dal wiki sono iniziati a sparire i contenuti e l’unica versione rimasta è quella enterprise; inoltre, gli aggiornamenti sono disponibili solo per quegli utenti in possesso di un valido contratto di supporto. ForgeRock, una società norvegese, ha tuttavia deciso di continuare il progetto dandogli una nuova casa ed il nome, per motivi di copyright, di OpenAM. Tutti i sorgenti e contenuti cancellati dal sito originale sono stati resi nuovamente disponibili e l’azienda si impegna a proseguire lo sviluppo secondo la tabella di marcia già presentata da Sun.
• IBM con il “Security Access Manager”, permette agli utenti di accedere a tut-te le applicazioni utilizzando una singola password. Tale applicazione facilita la gestione delle password e la protezione delle informazioni mediante strong authen-tication. Access Manager Security consente di ridurre i costi di gestione dell’help desk: se i dipendenti dimenticano la propria password, possono ripristinarla me-diante una semplice domanda e la relativa risposta. Il software fornisce token USB, smart card, token one-time password e dispositivi biometrici di impronte digitali. È inoltre possibile utilizzare i dispositivi di identificazione esistenti come badge e telefoni cellulari. Migliora la produttività e semplifica l’user experien-ces. Fornisce single sign-off in tutte le applicazioni e configura le politiche di protezione del desktop per impedire l’accesso non autorizzato alle applicazioni ri-servate. Se un utente si allontana da una stazione di lavoro senza disconnettersi, il software può applicare policy di timeout per inattività bloccando lo schermo, disconnettendosi forzatamente, etc.
• Shibboleth è una iniziativa inter-universitaria volta sviluppare una soluzione open source che consenta alle organizzazioni lo scambio di informazioni sui propri utenti
in modo sicuro e rispettoso della privacy. E’ basato su SAML (Security Assertion Markup Language) ed è stato sviluppato da Internet 2 e da un gruppo di architetti middleware (MACE) con la collaborazione di membri appartenenti alle universi-tà e alle imprese partner che hanno preso parte a questo progetto le cui finaliuniversi-tà sono la progettazione, la specifica e l’implementazione open source di sistemi per la condivisione di risorse web soggette ad autenticazione. Lo scopo del progetto consiste nel semplificare il problema dell’accesso a contenuti didattici riservati fra più campus universitari, ciascuno dei quali con una differente infrastruttura di autenticazione, e gestire lo scambio di informazioni per determinare se una per-sona, utilizzando i browser web (ad esempio Mozilla Firefox, Netscape Navigator, Internet Explorer), possieda o meno i permessi per accedere a una risorsa o a un target di risorse.
• OpenAM, erede di OpenSSO, offre un software open source per l’autenticazione, la gestione degli accessi e delle federazioni. Per la sua natura open source e per l’esperienza maturata da una società consolidata quale Oracle, questo software è stato scelto per la realizzazione del progetto.
Parte III
SSO
L’autenticazione degli utenti è il punto chiave dei servizi di sicurezza nella struttura informatica di un’organizzazione. Un’organizzazione deve bilanciare la semplicità d’ac-cesso e d’uso con un’efficace configurazione di sicurezza. Spesso, infatti, incrementando una si finisce per degradare l’altra. Una delle conseguenze della complessità ed eteroge-neità delle moderne architetture di rete è la proliferazione delle credenziali che gli utenti devono utilizzare per avere accesso ai sistemi. In uno scenario tipico, gli utenti di un’or-ganizzazione hanno accesso a differenti servizi fra loro indipendenti, ognuno dei quali richiede credenziali differenti per l’autenticazione. Si parla di sistema basato su Single Sign-On (SSO) quando le richieste di autenticazione non vengono direttamente gestite dal sistema stesso ma vengono ridirette verso un altro sistema di autenticazione che ha precedentemente certificato le credenziali dell’utente connesso, senza quindi avere la necessità di richiedere nuovamente le credenziali per l’accesso. L’obiettivo principe del SSO è quello di rendere la sicurezza trasparente all’utente finale, facilmente mantenibile e gestibile per gli amministratori; l’utente deve rendersi conto di lavorare in un sistema sicuro, ma non deve assolutamente vivere la sicurezza come un onere aggiuntivo. Un sistema di SSO era pensato come un prodotto che decrementava la sicurezza; ai giorni nostri con l’uso dei prodotti di SSO si incrementa sia la semplicità di uso, sia la sicurezza utilizzando appropriate implementazioni, contrastando i punti deboli dell’in-frastruttura, non permettendo il trasferimento delle password tra gli utenti, avvalendosi della strong authentication. Pertanto, i nuovi sistemi di SSO allargano notevolmente la visione di quelli tradizionali grazie a nuove tecnologie e ad un’infrastruttura più matura. Inoltre, la richiesta ed i benefici per un’identificazione degli utenti universale e sicura hanno rinnovato l’interesse dell’IT nei sistemi di SSO.
1 Le sfide del Single Sign-On
I sistemi informatici si moltiplicano e gli utenti devono combattere una battaglia persa contro il proliferare delle password. Ogni nuovo sistema richiede una nuova log-in ed ogni utente deve avere un’unica identità sul sistema. L’utente deve fornire una password che permetta al sistema di verificarne l’identità; inoltre, ogni sistema richiede
la propria autenticazione per accertarsi delle generalità dell’utilizzatore non potendo contare sulle precedenti autenticazioni. Un’organizzazione dovrebbe essere in grado di allocare ad ogni utente lo stesso username per ogni sistema, ma la sincronizzazione delle password fa nascere un problema più grande. Ogni utente ha bisogno di una password per ogni sistema, ed anche se si sceglie un’unica password per tutti i sistemi, si ha una modalità molto difficile da mettere in pratica. Differenti sistemi hanno regole diverse per la gestione delle credenziali, come ad esempio l’uso di stringhe di varia lunghezza. Differenti sistemi hanno un diverso ciclo di vita delle password, cosicchè un utente è costretto a cambiare la propria password su un sistema prima che su di un altro. Sia che si mantenga una sola password, sia che se ne mantenga una moltitudine, l’utente dovrà sempre confrontarsi con le richieste di identificazione. Non solo gli utenti devono affrontare il problema delle password, ma più password un utente deve memorizzare, più alta è la probabilità che queste siano dimenticate; di conseguenza gli helpdesk saranno sommersi di richieste per ripristinare le password.
Rischi per la sicurezza possono derivare dal fatto che gli utenti, per non dimenticarsi le password, annotano ad esempio su supporti cartacei informazioni preziose che possono essere facilmente accessibili.
Ultimamente la gestione delle password è stata delegata al browser del PC: l’utente è sollevato dal dover scrivere la password, minimizzando i rischi di perderla. Tuttavia questo non risolve la problematica legata all’accesso ai servizi da differenti PC.
In ogni caso le password possono offrire un certo numero di rischi per la sicurezza, come già visto in precedenza. Le password possono essere un metodo di autenticazione debole e sono vulnerabili a molti attacchi; difatti, come suggerito dalla quasi totalità di siti che gestiscono informazioni sensibili, essa va cambiata a scadenza regolare (tipicamente 3 mesi), evitando di utilizzare password precedenti.
2 Perchè investire sul SSO
Per la maggior parte delle organizzazioni è impossibile incorporare tutte le loro applica-zioni in un’unica interfaccia di presentazione. Pertanto gli utenti dovranno accedere a varie applicazioni o piattaforme nel loro formato originario. Questo formato può essere Windows, web-based oppure proprietario. Fornendo queste diverse modalità, i servizi di IT dovranno fare in modo che l’accesso ai sistemi sia veloce, semplice e coerente. Que-sto obiettivo continua ad essere in evoluzione ed ha una complessità sempre maggiore.
Infatti il numero di applicazioni e piattaforme è in continua crescita e la distribuzione degli utenti, coinvolti nell’uso di questi sistemi, è sempre più grande. L’operazione di logon è divenuta una delle sfide più importanti per l’efficacia e la soddisfazione degli utenti. Inoltre si deve giungere ad un’amministrazione centralizzata degli accessi ed aumentare la sicurezza generale, per difendere il sistema da minacce interne ed esterne.
3 Protocolli Single Sign-On
3.1 Kerberos
I sistemi di SSO esistono da molti anni: uno dei primi esempi è Kerberos.
Kerberos è un servizio di autenticazione sviluppato al MIT nel 1983 nell’ambito del progetto Athena, per fornire agli studenti un’enorme rete di computer che permettesse loro di accedere ai file personali da qualsiasi punto della rete. Immaginiamo un ambiente aperto in cui diversi utenti vogliono accedere ai servizi forniti da server distribuiti sulla rete. I server dovrebbere riuscire a:
• limitare l’accesso ai servizi agli utenti autorizzati;
• autenticare le richieste di servizi, cio‘e autenticare gli utenti da cui provengono tali richieste;
• evitare, mediante opportuna cifratura, che terzi possano intercettare i contenuti delle comunicazioni.
Questi tre obiettivi, di autorizzazione, autenticazione e cifratura, e soprattutto il lo-ro essere tre danno il nome al plo-rotocollo. Kerbelo-ros infatti era il cane a più teste, normalmente tre, con la coda di serpente, che stava a sorvegliare l’ingresso all’Ade. Esistono due versioni di Kerberos, attualmente utilizzate: Kerberos 4, principalmente sviluppata da Steve Miller e Clifford Neuman, e Kerberos 5, progettata da John Kohl e Clifford Neuman.
3.1.1 Obiettivi
Prima di descrivere gli elementi che compongono un sistema di autenticazione Kerberos e di vederne il funzionamento, ecco di seguito quali sono gli obiettivi che tale protocollo vuole raggiungere:
• La password dell’utente non deve mai viaggiare sulla rete;
• La password dell’utente non deve mai essere memorizzata in nessuna forma sulla macchina client: essa dopo essere utilizzata deve essere subito scartata;
• Le password dell’utente non dovrebbero essere memorizzate in chiaro neanche nel database dei server di autenticazione;
• All’utente è richiesto di inserire la password una sola volta per sessione di lavoro. Potrà pertanto accedere, durante detta sessione, a tutti i servizi per il quale è autorizzato, in modo trasparente, senza dover reinserire la password. Questa caratteristica è nota come Single Sign-On.
• La gestione delle informazioni di autenticazione è centralizzata e risiede sul ser-ver di autenticazione. I serser-ver applicativi non devono contenere informazioni di autenticazione dei loro utenti. Ciò è essenziale per ottenere i seguenti risultati:
– L’amministratore potrà disabilitare l’account di un utente agendo in un solo posto senza dover agire su più server applicativi che forniscono i vari servizi; – L’utente, cambiando la password, lo fa per tutti i servizi
contemporanea-mente;
– Non vi è nessuna ridondanza di informazioni di autenticazione che altrimenti bisognerebbe difendere in più posti;
• Non solo gli utenti devono dimostrare di essere chi dicono di essere, ma, quando richiesto, anche i server applicativi devono provare la loro autenticità ai client. Questa caratteristica prende il nome di Mutua autenticazione;
3.1.2 Definizioni
Realm Con il termine realm si indica un dominio amministrativo di autenticazione. Si intende cioè fissare i confini entro cui un server di autenticazione è autoritario nel-l’autenticare un utente, un host o un servizio. Ciò non vuol dire che affinché ci possa essere autenticazione tra un utente e un servizio questi debbano necessariamente ap-partenere allo stesso realm: se due oggetti fanno parte di realm diversi e tra questi ultimi intercorre una relazione di fiducia, allora l’autenticazione potrà aver luogo. In
pratica, un utente/servizio appartiene ad un realm se e soltanto se condivide un segreto (password/chiave) con il server di autenticazione di quel realm.
Il nome di un realm è case sensitive, cioè fa differenza tra maiuscole e minuscole; tuttavia, per consuetudine, i realm sono sempre in maiuscolo. È inoltre buona abitudine, in un’organizzazione, far coincidere il nome del realm con il dominio DNS (in maiuscolo però). Seguire questi consigli al momento della scelta del nome del proprio realm semplifica significativamente la configurazione dei client Kerberos, soprattutto qualora si vogliano stabilire relazioni di fiducia con sottodomini. A titolo di esempio, se ad un’organizzazione appartiene il dominio DNS iamboo.example.com, è opportuno che il relativo realm Kerberos sia IAMBOO.EXAMPLE.COM.
Principal Un principal è il nome con cui si fa riferimento alle entry nel database del server di autenticazione. Ad ogni utente, host o servizio di un dato realm viene associato un principal. Nel caso di un entry riferita ad un utente, il principal è del tipo:
Nome[/Istanza]@REALM
L’istanza è opzionale e la si usa di solito per qualificare meglio il tipo di utente. Per esempio gli utenti amministratori hanno di solito l’istanza admin. Sono esempi di principal riferiti a utenti i seguenti:
• pippo@IAMBOO.EXAMPLE.COM;
• admin/admin@IAMBOO.EXAMPLE.COM; • pluto/admin@IAMBOO.EXAMPLE.COM.
Se invece le entry sono riferite a servizi, i pricipal assumono la forma: Servizio/Hostname@REALM
La prima componente è il nome del servizio, per esempio http, imap, afs, ftp. Spesso è la parola host con cui si indica accesso generico alla macchina (http, telnet, rsh, ssh). La seconda componente è l’hostname completo (FQDN - Fully Qualified Domain Name) della macchina che fornisce il servizio richiesto. È importante che questa componente coincida esattamente (in minuscolo) alla reverse DNS dell’IP del server applicativo. Una valido esempio di principal riferito a servizi è il seguente:
Ticket Un ticket è un "biglietto" che un client presenta ad un server applicativo per dimostrargli l’autenticità della sua identità. I ticket vengono emessi dal server di autenticazione e vengono criptati con la chiave segreta del servizio a cui sono destinati. Poiché tale chiave è un segreto condiviso soltanto tra il server di autenticazione e il server che fornisce il servizio, neanche il client stesso che ha richiesto il ticket potrà conoscerne o modificarne il contenuto. Le principali informazioni contenute in un ticket sono:
• Il principal del richiedente (in genere è lo username); • Il principal del servizio a cui è destinato;
• L’indirizzo IP della macchina client da cui il ticket può essere usato. In Kerberos 5 questo campo è opzionale;
• La data e l’ora (in formato di timestamp) in cui ha inizio la validità del ticket; • Il tempo massimo di vita (lifetime) del ticket;
• La chiave di sessione (ha un ruolo fondamentale che viene descritto più avanti); Ogni ticket ha una scadenza (in genere 10 ore). Ciò è essenziale in quanto su un ticket già emesso, il server di autenticazione non ha più nessun controllo. L’amministratore del realm, cioè, benchè possa in qualsiasi momento impedire l’emissione di nuovi ticket per un certo utente, non potrà impedire a quest’ultimo di utilizzare quelli che già possiede. Da qui la necessità di limitare il tempo di vita dei ticket in modo da limitare nel tempo eventuali abusi.
3.1.3 Funzionamento
Schema di funzionamento del protocollo Kerberos
Tutto comincia da un utente, che si connette ad una workstation, accedendo ad un servizio client, e chiedendo l’accesso al servizio fornito da un server S.
• Il client C chiede ad un server di autenticazione (AS - Authentication Server) un ticket di assegnamento ticket(T icketT GS) per conto dell’utente. Manda quindi ad
AS il proprio codice identificativo (IdC) , quello del ticket-granting server di cui
intende servirsi (IdT GS) ed un Timestamp (T S1).
C → AS: [IdC|IdT GS| T S1],
dove | indica la concatenazione.
• AS manda al client un ticket ed una chiave di sessione (KC,T GS) crittografate
attraverso una chiave generata a partire dalla password dell’utente: KC. La
chiave di sessione è una chiave crittografica, quindi un’informazione segreta, for-nita da AS, in modo sicuro, al client e a TGS. Il client e TGS possono dimo-strare reciprocamente la propria identità mostrando all’altro di conoscere questa informazione.
AS → C : eKC [KC,T GS|IdT GS| T S2| Lifetime2|T icketT GS]
dove T icketT GS = eKT GS [KC,T GS,IdC|ADC|IdT GS| T S2|Lifetime2 ]
Solo l’utente conosce la password, e quindi solo il client C può recuperare il ticket. In questo modo l’utente ottiene il ticket senza trasmettere in chiaro la sua password. Possiamo osservare che AS manda al client anche altre informazioni come IdT GS, T S2
e Lifetime2 in modo che questi possa ricordarsi, in qualsiasi momento, che il ticket di
cui dispone è per il server TGS e possa controllare la sua scadenza. Queste informazioni sono contenute anche in T icketT GS.
Il client così possiede un ticket riutilizzabile solo per un periodo di tempo stabilito e dunque, in quel tempo, non deve chiedere la password all’utente per ogni servizio cui vuole accedere. Inoltre T icketT GS è crittografato con chiave segreta nota solo ad AS e
TGS. Il suo contenuto non è dunque modificabile. Viene poi crittografato una seconda volta con una chiave generata direttamente dalla password dell’utente. In questo modo T icketT GS è recuperabile solo dall’utente corretto, che comunque rimane non in grado
di leggerlo, e dunque il sistema di autenticazione è ancora valido.
Ora il client possiede il ticket di assegnamento ticket T icketT GS e la chiave di
sessio-ne KC,T GS; può quindi richiedere un secondo ticket, che possiamo chiamare ticket di
servizio.
• Il client, per conto dell’utente, chiede un ticket di servizio a TGS. Per farlo invia a TGS, insieme a T icketT GS, l’identificatore del server S (IdS) al cui servizio vuole
accedere ed un autenticatore.
C → TGS: eKC,T GS[IdS|T icketT GS| AutenticatoreC ],
dove AutenticatoreC = KC,T GS [IdC|ADC|T S3]
L’autenticatore viene usato una sola volta ed è di breve durata, piccoli accorgimenti per scongiurare gli attacchi a replay.
• TGS decifra T icketT GS usando KT GS ( condivisa sempre tra AS e TGS). Inoltre
usa la chiave di sessione KC,T GS per decifrare l’ AutenticatoreC. TGS ottiene
dunque IdC e ADC sia dall’autenticatore che dal ticket, e può confrontarli. Se
sono uguali, considera verificata l’identità del client. TGS controlla che a questo utente sia garantito l’accesso al servizio di S e, in caso affermativo, emette T icketS.
TGS → C: eKC,T GS[KC,S|IdS|T S4 T icketS ],
dove T icketS = eKV [KC,S|IdC|ADC|T S4|Lifetime4]
• Viene istituita da TGS una chiave di sessione anche tra il client ed il server S:
C → S: [T icketS|AutenticatoreC2 ],
dove AutenticatoreC2 = eKC,S [IdC|ADC|T S5]
• Il server S decifraT icketS usando la chiave KS, condivisa tra TGS e V. Recupera
così KC,S e può decifrare anche l’autenticatore, verificandol’identità del client.
• A questo schema, ormai completo, possiamo aggiungere un ultimo passaggio, facoltativo, che permette al client di avere la certezza di comunicare con il vero server S. É infatti sufficiente che S invii al client:
V → C: eKC,S [T S5+ 1]
Il server rimanda dunque al client il valore del Timestamp ottenuto dall’autenticatore del client incrementato di 1, e crittografato con la chiave di sessione KC,S . L’utilizzo
proprio di quella chiave di sessione assicura al client che solo il server S possa aver generato quel messaggio, e decifrando il messaggio il client ottiene il Timestamp del-l’autenticatore e sa che non è il replay di una vecchia risposta. Grazie a questo metodo, inoltre, C e V condividono una chiave di sessione KC,V che possono usare per
scambiar-si altri messaggi o per trasmetterscambiar-si una nuova chiave temporanea attraverso un canale sicuro. Se KC,V venisse intercettata, sarebbe compromessa tutta la comunicazione tra
3.1.4 Kerberos V5
La versione 5 di Kerberos (K5), pur mantenendo la forma base della versione 4, apporta modifiche volte a risolvere problemi e vulnerabilità del sistema, di natura ambientale e tecnica. Molte migliorie vengono apportate mediante l’utilizzo di flags dei ticket. Il campo FLAG è un campo del ticket che può supportare funzionalità differenti a seconda della versione di Kerberos considerata.
Kerberos 4 impiega DES. DES non è un sistema adattabile a diverse piattaforme e non è un sistema a sicurezza assoluta. Nella versione 5 il tipo di crittografia può variare, anche nel numero e nel tipo delle chiavi, informazioni specificate su un identificatore che accompagna il testo cifrato.
In Kerberos 4 la durata massima del ticket è : 28 ∗ 5 = 1280minuti ⇡ 21ore, che sono poche per alcune applicazioni. In Kerberos 5, i ticket includono:
1. from: tempo di inizio della validità del ticket; 2. till: tempo di fine della validità del ticket; 3. rtime: tempo di rinnovo richiesto;
La durata del ticket è dunque arbitraria.
3.2 SAML 2.0
L’autenticazione è il processo che stabilisce l’identità ed è richiesto per limitare l’accesso alle risorse, per identificare i partecipanti ad una transazione e per creare una persona-lizzazione delle informazioni basata sull’identità. Prendiamo come esempio un portale di viaggi che offre le informazioni sulle destinazioni, l’orario dei voli, la possibilità di prenotazione ed altri servizi. Ad un cliente tutto ciò dovrebbe apparire come un singolo sito web, ma in effetti ci sono diversi sistemi che cooperano per realizzare il servizio. Per l’usabilità e la trasparenza, un cliente dovrebbe potersi autenticare una sola volta al portale, e le informazioni sulla riuscita identificazione dovrebbero essere condivise dai vari sottosistemi cooperanti, con un certo periodo di validità. Strettamente legata all’operazione di autenticazione troviamo l’autorizzazione, che consiste nel dover deter-minare se una parte autenticata possa accedere ad una risorsa o fare una certa azione. Per fare un esempio, soltanto alcuni individui o persone che ricoprono dei ruoli specifici possono entrare in transazioni di grandi valori sul conto di una compagnia.
Lo standard Security Assertion Markup Language ( SAML) definisce un framework, basato su XML, per lo scambio di informazioni di sicurezza tra partners commerciali in rete. Nel gennaio del 2001 una divisione di CA, insieme ad altre società, ha dato vita alla Commissione Tecnica per i Servizi di Sicurezza (SSTC, Security Services Technical Committee) del consorzio OASIS, che è culminata con l’adozione dello standard SAML nel mese di novembre 2002. SAML 2.0, la versione attuale di SAML, è stata approvata dalla SSTC di OASIS nel mese di marzo 2005.
3.2.1 Definizioni
Identità digitale Per identità digitale si intende la rappresentazione elettronica di un set di asserzioni fatte da un soggetto digitale riguardo se stesso o un altro soggetto. Un’identità digitale è articolata in due parti:
• Chi uno è (identità);
• Le credenziali che ognuno possiede (gli attributi di tale identità).
Le credenziali corrispondono ad un set di proprietà che possono differire di parecchio in funzione dell’utilizzo che se ne intende fare. Un esempio più semplice di identità digitale consiste nella coppia di attributi corrispondenti ad un’username e alla password ad essa associata. In questo caso l’username è l’identità, mentre la password è chiamata credenziale di autenticazione. Ma l’identità digitale può essere complessa come una vera e propria identità umana e ha implicazioni sia legali che tecniche.
In generale, non è possibile identificare al 100% un individuo: prendiamo il caso di due gemelli, gli attributi fisici non basterebbero, così come il semplice nome. In realtà, quello che ci garantisce una certa univocità è la singola esperienza che ogni individuo lascia in noi. Incrociando tali ricordi, riusciamo a identificare un soggetto con una precisione tanto più alta quanto più sono le informazioni raccolte da noi sul suo conto, direttamente e indirettamente. Si può affermare che l’identità coincide con reputazione e questo non è qualcosa che necessariamente possiede l’individuo quanto piuttosto un insieme di informazioni che le persone attribuiscono al soggetto.
Dando un’interpretazione tecnologica, l’identità digitale è l’insieme delle informazioni e delle risorse concesse da un sistema informatico ad un particolare utilizzatore. Nel mondo dei web services, anche un’applicazione che richiede un servizio può essere vista come identità digitale e per questo motivo necessita di possedere adeguate proprietà
che le permettano di accedere alle risorse richieste. In questo caso, poiché non vi è un’interazione umana, la gestione dell’identità deve essere ancor più accurata in quanto non vi è la possibilità di interagire con un vero e proprio utente. Tutto deve risolversi in modo automatico ed ogni possibile deviazione del flusso procedurale deve essere contemplato.
Federazione di identità digitali Nel campo dell’ICT, la federazione di identità assume due significati generali:
• L’unificazione virtuale delle informazioni utente di un soggetto, detto anche Prin-cipal, memorizzate su diversi sistemi di gestione delle identità distribuiti nei di-versi sistemi di autenticazione della federazione. I dati di uno stesso soggetto sono collegati tra loro mediante l’uso di un token comune, tipicamente una username; • Un processo di autenticazione di un utente che si sviluppa trasversalmente sui
diversi sistemi IT delle varie organizzazioni federate.
Si può dire quindi che la federazione di identità elettroniche permette la cosiddetta Autenticazione Federata, che consiste nel dare fiducia ad una identità che richiede una risorsa appoggiandosi su un partner noto o un sito affidabile, appartenente alla stessa federazione il quale garantisce sull’identità richiedente.
Questo permette di scambiare informazioni in modo sicuro tra partner, clienti, fornitori e ogni altro stakeholder eventualmente interessato, e autorizzato, alla condivisione delle risorse. Il concetto di federazione di identità è assimilabile al collegamento mutuo tra i sistemi di identificazione dei singoli service provider al fine di creare una sovrastruttura che consenta di accertarsi dell’autenticità di un utente senza dovere chiedere ripetuta-mente le credenziali di accesso. Un classico esempio è rappresentato da un sottoinsieme di imprese che si occupano di turismo e che, opportunamente federate, decidono di erogare diversi servizi complementari tra loro, alla propria potenziale clientela. Ecco che allora un turista potrebbe essere visto come passeggero aereo così come ospite di un albergo. Inoltre questo soggetto potrebbe aver necessità di prenotare ingressi a musei o accedere a eventi artistici e culturali e via discorrendo. Con un adeguato sistema di gestione delle identità federate, tale utente potrà accedere alle varie risorse distribuite fisicamente in domini di sicurezza distinti, in modo del tutto trasparente senza dover ogni volta autenticarsi a questo o a quel sistema.
Come si vedrà in seguito, gli standard per la federazione delle identità identificano tipicamente due ruoli funzionali nelle transazioni:
• L’Identity Provider (IdP), che si occupa di fornire a richiesta, l’identità dell’utente o servizio che richiede l’accesso a una risorsa;
• Il Service Provider (SP), che potrebbe essere rappresentato da un fornitore di servizi.
La federazione di identità digitali permette ad entrambe le organizzazioni di definire una relazione fiduciaria dove SP fornisce l’accesso ad una risorsa dopo avere autenticato l’utente richiedente tramite un IdP.
Identity Provider (Idp) Un IdP (Identity Provider) è un sistema informatico che tratta individualmente le credenziali degli utenti finali e verifica che queste risultino valide. Ogni IdP è in grado di autenticare l’utente e fornire informazioni aggiuntive o attributi sul suo conto; può operare uno o più servizi di credenziali, ciascuno dei quali tratta le credenziali dell’utente basandosi su degli standard per la verifica dell’identità. Un utente può possedere credenziali da più Identity Provider, alcuni dei quali possono essere gestiti dalla stessa organizzazione o dalla stessa società.
L’Identity Provider controlla se esiste già una sessione per l’utente e, in caso contrario, l’IdP applica una autenticazione per l’utente.
Service Provider (SP) Il Service Provider è l’ente presso il quale è gestita la risorsa web a cui l’utente fa richiesta e che ha il compito di proteggerla attraverso qualche forma di policy di accesso. I dati associati a una sessione SP sono gli attributi, le informazioni di autenticazione (tempo, metodo, classe, ...); in altre parole, tutte le informazioni che sono state fornite dall’ IdP entro l’asserzione(i).
3.2.2 Architettura generale
Lo scenario tipico di un’infrastruttura di Identity e Access Management federato è quello in cui gli utenti, facenti parte di un’organizzazione, sono autenticati tramite l’Identity Provider (IdP) e possono accedere alle risorse localizzate presso i Service Provider (SP).
All’interno di questa architettura base le diverse organizzazioni fanno capo alla federa-zione, la quale ha il compito di coordinare le differenti risorse a loro interno.
Scenario 1 Il caso tipico è quello in cui un utente di una organizzazione vuole accedere a una risorsa della propria struttura.
In questo scenario la federazione non risulta essere un elemento significativo, tuttavia il sistema di Identity Access e Management è in grado di fornire il servizio di SSO internamente.
1. L’utente richiede l’accesso a una risorsa all’interno dello SP; 2. L’SP contatta l’IdP per ottenere le credenziali di accesso; 3. L’IdP domanda le credenziali all’utente;
4. Ad autenticazione avvenuta, l’utente viene indirizzato alla risorsa che aveva pre-cedentemente richiesto.
Scenario 2 Un ulteriore caso d’uso è quello in cui l’utente fa accesso ad una risorsa di un’organizzazione diversa.
In questo scenario il concetto di federazione risulta essere fondamentale, perché attraver-so questo elemento di unione l’utente è in grado di accedere a una riattraver-sorsa appartenente a una diversa organizzazione.
1. L’utente richiede l’accesso ad una risorsa all’interno dell’SP; 2. L’SP contatta l’IdP per ottenere le credenziali di accesso; 3. L’IdP domanda le credenziali all’utente;
4. Ad autenticazione avvenuta, l’utente viene indirizzato alla risorsa che aveva pre-cedentemente richiesto;
5. L’utente richiede una risorsa localizzata all’interno di un SP differente dalla pro-pria organizzazione;
6. L’SP contatta l’IdP di appartenenza dell’utente. In questo punto gioca un ruolo fondamentale la federazione, la quale ha il compito specifico di tenere aggiornata la lista degli IdP e SP disponibili all’interno della federazione;
7. L’IdP richiede le credenziali di autenticazione;
8. Una volta autenticato, l’utente è in grado di accedere alla risorsa all’interno di una differente organizzazione.
3.2.3 Vantaggi
I vantaggi di SAML sono molteplici:
• L’indipendenza dalla piattaforma utilizzata;
• Non è più necessario mantenere sincronizzate le informazioni utente tra le diverse directory. Ogni dominio gestisce gli attributi necessari al contesto d’uso;
• Miglioramento dell’esperienza online per l’utente finale, fornendo semplicità e sicurezza delle informazioni introdotte;
• Riduzione del costo d’amministrazione per i service provider, poiché l’atto di autenticazione può essere riusato senza bisogno di mantenere le informazioni d’account;
• Riduzione del rischio di trasferimento delle informazioni tramite meccanismi di sicurezza come firme digitali (XML Signature), cifratura (XML Encryption), crittografia (SSL e TLS), codifica, etc.
3.3 OAuth 2.0
OAuth, acronimo di Open Authorization, è un protocollo open che permette l’uso au-torizzato e sicuro di API (Application Programming Interface) da parte di applicazioni su sistemi desktop, web e mobile. Lo sviluppo è iniziato nel novembre 2006 ad opera di un gruppo di programmatori web tra cui Blaine Cook, che all’epoca stava sviluppando il sistema Twitter OpenID1, con lo scopo di risolvere il problema dell’accesso, tramite delega, a risorse protette.
Con il crescente successo di siti web come Twitter, Facebook, Google etc. sono nate intorno ad essi applicazioni, sviluppate da terze parti, per utilizzare questi servizi; basti pensare ai vari client mobile per i social network. Parallelamente è quindi nata la necessità di autorizzare queste applicazioni ad accedere, in modo sicuro, ai dati privati dell’utente.
Per capirne il funzionamento, basti pensare alle "valet key" delle macchine di lusso, una chiave speciale per i parcheggiatori, che diversamente dalla chiave regolare, non permette alla macchina di essere guidata per più di uno o due chilometri. Alcune “valet key” non permettono per esempio di aprire il bagagliaglio, mentre altre bloccano
l’accesso al telefono di bordo. Indipendentemente dalle restrizioni imposte dalla “valet key”, l’idea è molto intelligente: fornire l’accesso limitato alla macchina con una chiave speciale e usare la chiave regolare per sblocca tutto.
3.3.1 Client-Server vs OAuth
Il modello tradizionale di autenticazione Client-Server usa le credenziali dell’utente (tipicamente username e password) per accedere alle risorse private che sono ospitate nel server. Con questo metodo di autenticazione, l’uso di applicazioni sviluppate da terzi parti pone chiari problemi di sicurezza:
• La password non è più un segreto tra servizio e utente, viene salvata anche dall’applicazione;
• L’applicazione client a totale accesso alle informazioni riservate.
• L’autorizzazione rimane in possesso dell’applicazione client fino al cambiamento della password da parte dell’utente.
L’idea proposta da OAuth, per risolvere questo problema, è quella di introdurre un terzo ruolo oltre ai due classici, client e server: il proprietario delle risorse (resource owner). Nel modello OAuth il client, che non è il proprietario delle risorse ma è colui che agisce in suo nome, deve richiede il permesso all’utente per accedere alle sue risorse. Inoltre OAuth permette al server di verificare non solo che il client abbia l’autorizzazione, da parte del proprietario delle risorse, ma anche l’identità del client che fa la richiesta. Quindi, affinché il client possa accedere alle risorse, in primo luogo deve ottenere il per-messo dal proprietario della risorsa. Questa autorizzazione viene espressa in forma di token (gettone) ed uno shared-secret. Il cuore del protocollo è proprio il token, che per-mette appunto di gestire gli accessi senza la condivisione della password e diversamente dalle credenziali dell’utente, può essere rilasciato con delle restrizioni e/o con durata limitata, nonché essere revocato in maniera indipendente dalla volontà del client. 3.3.2 Terminologia
Prima di vedere un esempio reale, vediamo qual è la terminologia che vedremo nell’im-plementazione del protocollo OAuth:
• Service Provider: un server http in grado di accettare richieste OAuth autenti-cate. Inoltre è il sito o servizio web all’interno del quale le risorse protette sono memorizzate (Es. Facebook, Twitter, Google, etc);
• Consumer(Client): un client http in grado di effettuare una richiesta OAuth; può essere un sito web, un programma, un dispositivo mobile, o qualsiasi altra cosa connessa al web;
• Protected resource: risorsa ad accesso ristretto che può essere ottenuta dal server usando una richiesta OAuth autenticata. In sostanza è l”’oggetto” che Oauth tutela, sul quale concede accesso e permessi.
• Resource owner: un entità in grado di accedere e controllare risorse protette tramite l’utilizzo di credenziali autenticate con il server;
• Credenziali: sono una coppia formata da un identificatore unico e un corrispon-dente segreto condiviso. OAuth definisce tre classi di credenziali: client, tem-poranee e token, usate rispettivamente per identificare e autenticare il client che effettua la richiesta, la richiesta di autorizzazione e la concessione di accesso; • Token: un identificatore univoco rilasciato dal server e usato dal client per
asso-ciare le richieste autenticate con il proprietario della risorsa, la cui autorizzazione è richiesta o è stata ottenuta dal client. I token hanno una corrispondenza che è usata dal client per stabilire il possesso del token e “l’autorità” di rappresentare il possessore della risorsa.
3.3.3 Funzionamento
Richiesta OAuth da parte del client In questa prima fase, il Client si Affi-lia al Service Provider (passo 1 ). Ad esempio, supponiamo di aver creato una ap-plicazione per smartphone, la quale vuole accedere ad alcuni dei nostri dati, me-diante autenticazione OAth2.0, memorizzati su Facebook. Il processo di affiliazione consiste nel registrare l’applicazione su Facebook (per ulteriori informazioni, visitare http://developers.facebook.com/docs/authentication/). Una volta effettuata la registrazione, il Service Provider genera una API key ed uno Shared Secret, (passo 2 ) necessari alla nostra applicazione per effettuare l’autenticazione (passo 3-4 ).
Richiesta dell’utente al client L’utente, proprietario della risorsa protetta, inoltra una richiesta al client. Il client, essendo in possesso delle API key e dello Shared Secret, crea una richiesta Oauth e reindirizza l’utente al Service Provider.
Richiesta dell’utente al Service Provider L’utente si autentica con il Service Provider. Viene generato un “gettone” e l’utente viene reindirizzato nuovamente verso il Client.
Richiesta del Client al Service Provider OAuth utilizza un sistema di firme digitali per non dover trasmettere credenziali non divulgabili come login e password. Il Client, richiede un Access Token mediante firma digitale. Per garantirne la sicurezza nella firma digitale sono contenuti Shared Secret, Nonce (Number used ONCE) e Ti-mestamp. Il Service Provider controlla la validità del certificato e, se valido, invia un Access Token al Client.
Il Client riceve le informazioni richieste dal Service Provider Il Client richie-de le risorse (per conto richie-dell’Utente) inclurichie-dendo la firma digitale. Il Service Provirichie-der controlla la sua validità ed, in caso affermativo, restituisce al client le risorse protette richieste. A questo punto il Client può erogare il servizio richiesto dall’Utente.
3.4 Policy Agent
Il Policy Agent consiste in un programma che controlla il web container ospitante le risorse. Per spiengarne meglio il funzionamento, si descrive come un Policy Agent agisce in OpenAM.
Supponiamo che un utente tenti di accedere a una risorsa protetta prima di essersi autenticato, puntando il browser verso una pagina web. Supponiamo, inoltre, di aver configurato OpenAM per la protezione di una pagina web. Il Policy Agent intercetta la richiesta e, non trovando alcun token di sessione nella richiesta, reindirizza il browser dell’utente alla pagina di login OpenAM per l’autenticazione. Dopo l’autenticazione dell’utente, OpenAM imposta un token di sessione in un cookie del browser, e reindirizza il browser alla pagina cui si era tentato di accedere precedentemente.
Quando il browser dell’utente rieffettua la richiesta, il policy agent controlla nuovamente se la richiesta possiede un token di sessione: trovandolo, convalida il token di sessione
con OpenAM. Poichè il token di sessione è valido, si demanda ad OpenAM la gestione del suo accesso. Se il Service Policy di OpenAM determina che l’utente è autorizzato ad accedere alla pagina, OpenAM risponde al policy agent informandolo che è concesso l’accesso. Il policy agent a quel punto permette l’accesso alla risorsa per quell’utente.
Più in dettaglio:
1. Un client richiede l’accesso ad una risorsa protetta
2. Il policy agent gestisce la richiesta, valutando se è presente un token di sessione valido;
3. Il policy agent comunica con OpenAM;
4. Per quella risorsa cui è stato concesso l’accesso da OpenAM, viene concesso l’accesso dal policy agent;
Parte IV
Forgerock & OpenAM
1 Un pò di storia
Sun Microsystem, nel lontano 2000, iniziò lo sviluppo di un progetto, Directory Server Access Management Edition, mirato a risolvere il problema del Single Sign-On. L’o-biettivo iniziale era quello di fornire solo autenticazione e autorizzazione da parte della SSO utilizzando un protocollo proprietario. Nel corso degli anni si è evoluto per diven-tare una leggera applicazione Java che fornisce un set completo di funzioni di sicurezza per proteggere le risorse aziendali. Dopo aver subito una moltitudine di cambiamenti in termini di nome del prodotto, caratteristiche, etc, venne rilasciata con il nome di OpenSSO.
OpenSSO fu l’unico progetto open source di tal tipo che ottenne un grande successo sul mercato. Furono effettuati oltre otto mila casi di test ed è supportato da una comunità di ingegneri, analisti e sviluppatori che rispondono tempestivamente a qualsiasi dubbio e/o anomalia.
Dopo l’acquisizione da parte di Oracle, la versione open del progetto fu abbandonata: dal wiki iniziarono a sparire contenuti e l’unica versione rimasta fu quella enterprise, e gli aggiornamenti rimasero disponibili solo per utenti con un valido contratto di supporto. Fortunatamente ForgeRock, una società norvegese, decise di prendere in mano il pro-getto dandogli una nuova casa ed il nome, per motivi di copyright, di OpenAM. Tutti i sorgenti e contenuti cancellati dal sito originale furono resi nuovamente disponibili e l’azienda proseguì lo sviluppo secondo la tabella di marcia già presentata da Sun.
2 SSO in OpenAM
La sessione SSO in OpenAM si basa sui cookie del browser. Un cookie è rappresantato da righe di testo usate per eseguire autenticazioni automatiche, tracciatura di sessioni e memorizzazione di informazioni specifiche riguardanti gli utenti che accedono al server, come ad esempio siti web preferiti o, in caso di acquisti via internet, il contenuto dei loro "carrelli della spesa". Nel dettaglio, sono stringhe di testo di piccola dimensione
inviate da un server ad un Web client (di solito un browser) e poi rimandati indietro dal client al server (senza subire modifiche) ogni volta che il client accede alla stessa porzione dello stesso dominio web.
I cookies di sessione contengono l’ID di sessione, che identifica il client al server ad ogni interazione. In OpenSSO ci sono più i cookies coinvolti, e non tutti vengono impostati ogni volta: le loro informazioni e le loro validità sono impostate durante il processo di autenticazione.
OpenAM richiede, per il suo funzionamento, la definizione di un FQDN (acronimo di Fully Qualified Domain Name). Esso consiste in un nome di dominio non ambiguo che specifica la posizione assoluta di un nodo all’interno della gerarchia dell’albero DNS. Per distinguere un FQDN da un nome di dominio standard si aggiunge il nome dell’host alla stringa del dominio, in modo da renderla assoluta. In fase di test del prodotto, è stato scelto il seguente FQDN: openam.example.com, mappato all’indirizzo privato 10.0.0.216.
##
# Host Database #
# localhost is used to configure the loopback interface # when the system is booting. Do not change this entry. ## 127.0.0.1 localhost 255.255.255.255 broadcasthost 10.0.0.216 openam.example.com 10.0.0.205 protected.example.com 10.0.0.204 protected2.example.com
3 Installazione OpenAM
OpenAM è un’applicazione WAR (java Web ARchive) la quale non richiede nessun’altro componente esterno quali database o server LDAP per la sua configurazione base. Esso può essere eseguito su qualsiasi container semplicemente trasportando il WAR nella directory opportuna. Per esempio, nel server Apache Tomcat, è necessario copiare il file openam_10.1.0.war (al momento in cui si scrive, scaricabile su https://download. forgerock.com/downloads/enterprise/openam/openam10/10.1.0/openam_10.1.0. war) all’interno della cartella webapp. Non appena copiato, l’applicazione sarà imme-diatamente disponibile all’URL:
3.1 Predisposizione del software necessario
L’installazione di OpenAM è piuttosto semplice. Tuttavia è necessario scaricare alcuni pacchetti software, tra cui:
• Java Development Kit 6 (http://www.oracle.com/technetwork/java/javasebusiness/ downloads/java-archive-downloads-javase6-419409.html#jdk-6u45-oth-JPR). • Apache Tomcat 7 (http://it.apache.contactlab.it/tomcat/tomcat-7/v7.
0.42/bin/apache-tomcat-7.0.42.zip);
• OpenAM 10.1.0 Deployable War (https://download.forgerock.com/downloads/ enterprise/openam/openam10/10.1.0/openam_10.1.0.war);
3.1.1 JDK 6
1. Scarichiamo direttamente da terminale l’sdk java 6:
sudo apt-get install sun-java6-jdk
2. Troveremo la cartella java-6-sun-1.6.0.26 in /usr/lib/jvm
3. Impostiamo la variabile d’ambiente JAVA_HOME in modo che essa punti al percorso in cui risiede la cartella contentente il JDK:
export JAVA_HOME=/usr/lib/jvm/java-6-sun-1.6.0.26
4. Testiamo se la variabile d’ambiente è stata impostata correttamente:
$JAVA_HOME/bin/java -version
Il comando dovrebbe restituire il seguente output:
java version "1.6.0_26" Java(TM) SE Runtime Environment (build 1.6.0_26-b03) Java HotSpot(TM) Client VM (build 20.1-b02, mixed mode, sharing)
