Università degli Studi di Napoli Federico II

Transcript

1 Università degli Studi di Napoli Federico II Facoltà di Scienze MM.FF.NN. Corso di Laurea in Informatica Tesi Sperimentale di Laurea Triennale Autenticazione mediante certificati X.509 e mediante SSO per l accesso ai servizi di monitoraggio e di accounting Relatori Candidato Prof. Guido Russo Marco Alfano Dr. Giuseppe Vitagliano Matricola: 566/2817 Anno accademico 2008/2009

2 Ringraziamenti Al termine di questo lavoro di tesi, vorrei ringraziare le persone che mi hanno permesso di vivere questa esperienza e raggiungere questo traguardo, la mia famiglia, che ha sempre creduto nelle mie capacità, mi ha sempre appoggiata in qualsiasi scelta di vita e mi ha fornito le risorse economiche per affrontare questo percorso di studi. Desidero ringraziare innanzitutto i miei relatori, il prof. Guido Russo e il Dr. Giuseppe Vitagliano per avermi offerto tutto il supporto necessario per portare a termine questa esperienza accademica. I miei ringraziamenti vanno anche al Ing. Gianluca Vuolo, l'ing. Maurizio Pollio e l'ing. Giovanni Barone per il supporto, i consigli e l'esperienza fornitomi per portare a termine questo lavoro. Ringrazio tutti gli amici del centro S.Co.P.E. per le piacevoli giornate passate insieme, per la loro simpatia e per essersi dimostrati delle persone splendide, sempre pronte ad aiutarti. Un ringraziamento particolare va alla mia ragazza Simona, che mi ha incoraggiato ad intraprendere questa magnifica esperienza di vita, mi ha capito nei momenti difficili, ed ha creduto nelle mie capacità. Grazie a tutti!

3 Indice generale OBIETTIVO DEL PROGETTO IAM (Identity and Access Management) Cos'è Un Sistema IAM Identità E Ciclo Di Vita Delle Identità Identità Ciclo di vita delle identità Autenticazione Ed Autorizzazione Autenticazione degli utenti Autorizzazione LDAP Gestione dell'accesso Il Significato Sulla Gestione Dell'accesso Tecnologie Per L'accesso Single Sign-On Stato Dell'arte Soluzioni A Confronto Scelta Del Sistema SSO Sicurezza Progetto: Autenticazione mediante X.509 e Single Sign-On Contesto Di Lavoro OpenSSO: Autenticazione Architettura Presente Analisi Dei Requisiti Realizzazione Del Prototipo Progettazione Architettura Scelte progettuali Descrizione e Diagramma delle classi sviluppate Casi d'uso Diagrammi di sequenza Implementazione Integrazione Liferay OpenSSO Integrazione OpenSSO LDAP Descrizione del funzionamento...62 CONCLUSIONI...64 APPENDICE A: Schema LDAP...66 APPENDICE B: Codice delle classi...72 APPENDICE C: Procedure Installazione Sistema...94 APPENDICE D: File di configurazione BIBLIOGRAFIA...113

4 OBIETTIVO DEL PROGETTO L'utilizzo di risorse informatiche avviene spesso in ambienti in cui è necessario conoscere l'identità dell'utilizzatore. L'identità digitale per quanto riguarda i sistemi operativi, viene gestita centralmente dal sistema stesso, ciò non avviene nelle applicazioni; per queste ultime, l'identità viene memorizzata e gestita dalla singola applicazione. Questo, implica l'esistenza di diverse identità digitali dello stesso utente, una per ogni applicazione; quindi l'utente è costretto a ripetere la procedura di autenticazione se vuole utilizzare un altro sistema. Nasce così l'esigenza di un sistema centralizzato capace di gestire sia le identità digitali che le procedure di accesso per le singole risorse informatiche. Questa problematica è molto sentita all'interno dell'infrastruttura di rete UniNA. Essa infatti, possiede diverse risorse informatiche utilizzate da docenti, studenti e personale, che hanno come prerequisito fondamentale il riconoscimento dell'utilizzatore. Dato il gran numero di utenti, è impensabile gestire gli utenti per ogni singola risorsa, perciò è stato creato un unico database utenti basato su directory Ldap ed utilizzante il sistema OpenLdap. Tutte le risorse però implementano, in maniera autonoma, una propria procedura di autenticazione, con il risultato che l'utente deve ripetere la suddetta per accedere ad un altro servizio. Inoltre tale problematica è estesa al progetto S.Co.P.E., una rete di calcolo basata sul paradigma Grid, a supporto della ricerca. Il progetto è in continua evoluzione, ed allo stato attuale si sta lavorando per implementare un'interfaccia di utilizzo basata su web. Il problema descritto è risolvibile utilizzando un sistema di Single Sign-On. Lo scopo di questo progetto è studiare e progettare l'integrazione di un sistema di Single Sign-On per le risorse informatiche presenti nell'infrastruttura di rete UniNA ed in particolare per il portale web (Liferay) utilizzato nel progetto S.Co.P.E.. L'utilizzo di un sistema di autenticazione centralizzato comporta la formazione Marco Alfano 566/2817 Pagina 4 di 113

5 di un punto critico per quanto riguarda la sicurezza e l'affidabilità del servizio, poiché il sistema gestisce in ogni suo aspetto il riconoscimento degli utenti e quindi l'accesso al database centrale degli utenti. Per quanto detto è stata svolta, all'interno del periodo tirocinio, un'intensa attività di ricerca per selezionare il sistema SSO ideale per l'integrazione con l'infrastruttura di rete esistente; la scelta è ricaduta sul sistema OpenSSO, un sistema Open Source realizzato dalla SUN Microsystem e basato interamente su Java. OpenSSO fa parte dei sistemi di Single Sign-On per applicazioni web; permette, in seguito alla fase di autenticazione, il passaggio da un portale ad un altro senza la necessità di ripetere la procedura di autenticazione. Esso offre un servizio di conservazione dello stato di autenticazione ed incorpora anche la funzione di autorizzazione, che permette di stabilire quali utenti possono accedere alle diverse risorse, sfruttando la suddivisione degli utenti in base a gruppi di appartenenza. La comunicazione tra il portale ed il sistema SSO avviene mediante un client, denominato Agent in Opensso, che si frappone tra i due sistemi per offrire un'interfaccia di comunicazione conosciuta ad entrambi i sistemi. È stato analizzato interamente l'agent di interfacciamento già presente nel portale Liferay e modificato al fine di renderlo adeguato alle particolari esigenze. Nello specifico, l'agent esistente utilizzava soltanto la funzionalità di autenticazione fornita da OpenSSO, ma non quella di autorizzazione. Il lavoro di modifica effettuato è stato realizzato con lo scopo di fornire al portale, Liferay, dell'indispensabile funzione di autorizzazione utilizzando quella messa a disposizione da OpenSSO. Il lavoro di modifica è stato pubblicato sulla community di Liferay, rendendo disponibile la preziosa e molto richiesta funzionalità di autorizzazione a tutti i suoi utenti. Il sistema è stato configurato anche per l'utilizzo dell'autenticazione basata su Marco Alfano 566/2817 Pagina 5 di 113

6 certificati asimmetrici X.509, funzionalità necessaria soprattutto in futuro per l'utilizzo delle risorse GRID direttamente dal portale Liferay. Poiché OpenSSO non possiede un Agent scritto in PHP, è stato preso in considerazione per l'integrazione anche il sistema CAS, poiché nella rete UniNA è presente un portale scritto in PHP, Moodle. Marco Alfano 566/2817 Pagina 6 di 113

7 1 IAM (Identity and Access Management) 1.1 Cos'è un sistema IAM Un sistema IAM è una soluzione tecnologica alle problematiche di gestione del ciclo di vita delle identità digitali e degli accessi di utenti su più sistemi informatici. I sistemi informatici solitamente sono indipendenti tra loro ed ognuno di essi ha un proprio database utenti e delle proprie politiche di gestione delle identità digitali. In queste condizioni gli utenti si trovano ad avere più identità digitali, ognuna associata ad un sistema. 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 di un utente dovrebbe essere eseguito su tutte le identità, con conseguente perdita di tempo e difficoltà di gestione. Un sistema IAM mette a disposizione un unico punto di gestione per amministrare gli accessi e gli utenti rendendo queste operazioni 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. Un sistema IAM è multidisciplinare e comprende vari aspetti: Tecnico: Sistemi di gestione delle identità Legale: Normativa in materia di protezione dei dati Sociale: Gestione della privacy Sicurezza: Controllo di Accesso Marco Alfano 566/2817 Pagina 7 di 113

8 Illustrazione 1: Architettura IAM 1.2 Identità e ciclo di vita delle identità Identità Un'identità digitale è l'insieme delle informazioni mantenute nel sistema informatico che rappresentano un'entità che accede alle risorse concesse dal sistema stesso. Un'identità digitale è identificata dai seguenti macro-attributi: 1) Dati anagrafici: Informazioni anagrafiche dell'utente, ad esempio: nome, cognome, codice fiscale. 2) Identifier: sono informazioni che identificano in modo univoco il soggetto dell'entità. Un esempio sono gli indirizzi e i Globally Unique Identifiers (GUIDs). 3) Credentials: Dati privati o pubblici che possono essere utilizzati per identificare l'autenticità di una identità. Un esempio sono le password utente, solo l'utente è a conoscenza della propria password, quindi il suo inserimento consente l'identificazione univoca dell'utente. Un altro esempio di credenziali sono la chiave pubblica e privata di un certificato X ) Core Attribute: informazioni aggiuntive aventi come ruolo un ulteriore Marco Alfano 566/2817 Pagina 8 di 113

9 descrizione dell'identità. Queste informazioni possono essere utilizzate da diverse aziende o applicazioni. Un esempio possono essere gli indirizzi e i numeri telefonici. 5) Context-specific Attributes: Informazioni specifiche riferite ad un particolare contesto e che non hanno significato in altri. Illustrazione 2: Concetto di Identità Ciclo di vita delle identità Una identità non rimane immutata nel tempo ma può subire dei cambiamenti a causa delle seguenti operazioni Creazione Modifica Eliminazione Lo schema riportato di seguito mostra, a vari livelli, le funzionalità che il sistema deve avere per la gestione del ciclo di vita di un'identità. Marco Alfano 566/2817 Pagina 9 di 113

10 Illustrazione 3: Funzionalità Necessarie per Gestire le Identità Il livello Identity Data contiene la tipologia di dati che il sistema deve poter gestire. Data Operations identifica le possibili funzionalità che il sistema mette a disposizione per ogni singola operazione. Ad esempio la creazione di una nuova identità comporta l'inserimento delle informazioni sull'utente nel database utenti, quindi il sistema deve prevedere le funzionalità per l'acquisizione delle informazioni, e quelle di assegnazione dei permessi. l'administration Model, contiene due possibilità: self service e delegated administration; questi descrivono in che modo l'utente può accedere e modificare i propri dati. Nel primo casol'utente può modificare in modo autonomo tutte le proprie informazioni; nel secondo invece, gli si da la possibilita di poter modificare solo una parte di essi. 1.3 Autenticazione ed Autorizzazione Autenticazione degli utenti L'autenticazione è un processo mediante il quale un computer o un software verifica la corretta identità dell'utente che vuole accedervi. Essa Marco Alfano 566/2817 Pagina 10 di 113

11 utilizza diverse tipologie di credenziali, che vanno dal semplice nome utente e password, a quelle biometriche come le impronte digitali. La sicurezza delle informazioni utilizzate per l'autenticazione è fondamentale, ad esempio la divulgazione o lo smarrimento di una password permetterebbe a chiunque di impersonare, a tutti gli effetti, l'identità della persona con tutti i rischi che ne derivano Autorizzazione L'autorizzazione è l'operazione che completa la fase di autenticazione; consiste nello specificare, per un determinato utente, le operazioni che può svolgere o meno in un preciso contesto. Le autorizzazioni sono alla base di tutti i sistemi informatici oggi disponibili, basta pensare alla distinzione tra utente ed amministratore, l'utente sarà autorizzato ad effettuare un ristretto insieme di operazioni rispetto all'amministratore. Il concetto di gruppo di appartenenza è stato introdotto per associare, gli stessi privilegi a più persone, evitando, di conseguenza, la gestione per singolo utente. Il gruppo è un'entità a cui sono assegnate una o più autorizzazioni ed ogni utente può essere inserito ad uno o più gruppi e sarà autorizzato ad effettuare tutte le operazioni associate al gruppo di appartenenza. Si comprende subito che, con questo tipo di gestione, l'assegnazione delle autorizzazioni risulta semplificata; infatti la modifica delle autorizzazioni fatta a livello gruppo viene propagata automaticamente a tutti gli utenti che vi appartengono. 1.4 LDAP LDAP (Lightweight Directory Access Protocol) è un protocollo utilizzato per accedere ai servizi di directory. I Directory sono database specializzati per offrire massime prestazioni in fase di lettura delle informazioni. Per quanto detto, le direcory ldap possono essere impiegate in ambiti dove gli accessi in lettura sono maggiormente utilizzati rispetto a quelli in scrittura, questo è il caso di dati statici Marco Alfano 566/2817 Pagina 11 di 113

12 come l'anagrafica degli utenti, in cui le modifiche sono rare ed effettuate quasi esclusivamente dagli amministratori del sistema. L'informazione all'interno di una directory è organizzata in elementi chiamati entry. Le entry vanno a formare una struttura dati organizzata ad albero, dove ogni nodo o foglia viene identificata mediante un Relative distinguished name (RDN). L'unione degli RDN, a partire dalla foglia fino alla radice dell'albero, costituisce il distinguished name (DN), che identifica in modo univoco le entry. Una entry è costituita da una o più objectclass, ovvero, da gruppi di attributi. Lo schema identifica, le caratteristiche degli attributi relativi ad una objectclass come ad esempio il nome, se singolo o multivalore, opzionale oppure obbligatorio ed altri. Illustrazione 4: Struttura Ldap UniNA Marco Alfano 566/2817 Pagina 12 di 113

13 2 Gestione dell'accesso 2.1 Il significato sulla gestione dell'accesso L'utilizzo di un sistema informatico, ci pone quasi sempre nella condizione di dover dimostrare la nostra identità. Prelevamenti a sportelli bancomat, accesso ad un sito di acquisti online, accesso ad un forum, sono tutti esempi di operazioni che necessitano di identificare la nostra persona. È evidente che, nella maggior parte delle volte, l'accesso implica l'utilizzo di dati sensibili, come password, pin, o qualsiasi altro sistema di riconoscimento;nasce così l'esigenza di gestire l'accesso e la sicurezza. Gestire l'accesso va oltre il bisogno di gestire l'autenticazione e quindi comprovare l'identità di un utente, è una materia che coinvolge molti aspetti connessi tra di loro, come la gestione delle credenziali utente e la gestione delle autorizzazioni. Si crea quindi l'esigenza di un sistema capace di gestire tutti gli aspetti già citati e di considerare per ognuno di essi il problema sicurezza. Nel corso degli anni i sistemi per l'accesso si sono evoluti per fronteggiare il crescente problema sicurezza; tecnologie sempre più evolute hanno reso i primi sistemi di autenticazione sempre più vulnerabili e inaffidabili. 2.2 Tecnologie per l'accesso Il sistema più comunemente utilizzato per eseguire l'accesso ad un sistema è costituito dall'inserimento della coppia di valori username e password. Il primo rappresenta il nome univoco mediante il quale un utente viene riconosciuto da un sistema informatico e nella maggior parte delle volte, non corrisponde al nome o al cognome proprio della persona, ma è uno pseudonimo. La seconda unita all'username permette di comprovare che l'utente che ha inserito quella particolare username ne è il titolare. Percui l'username è spesso di dominio pubblico, mentre la password è strettamente personale. Un esempio potrebbe essere l'utilizzo del bancomat: la carta bancomat dice al sistema chi siamo, ed il pin permette di comprovare che siamo proprio noi ad utilizzarla; è evidente che il furto della sola Marco Alfano 566/2817 Pagina 13 di 113

14 carta non ne permetterebbe l'utilizzo. Allo stesso modo, per l'username, la sola conoscenza di essa non permetterebbe l'autenticazione al sistema se non dopo aver inserito anche la password associata. La maggior parte delle volte questo sistema crea difficoltà all'utente che deve scegliere username e password diverse; ogni sistema presenta una propria politica riguardo username e password. Alcuni dei parametri sono la lunghezza (minima e massima), la composizione (numeri, lettere o una loro combinazione) e la complessità della password poichè spesso è richiesto l'utilizzo di almeno un carattere speciale, cioè non alfanumerico, ad esempio un qualsiasi tipo di punteggiatura. La password è strettamente personale e per nessun motivo dovrebbe essere annotata; ciò implica la disagevole necessità di ricordare diversi nomi utente e diverse password. Per ovviare a questo problema è stata realizzata una soluzione logicamente semplice, ma laboriosa da realizzare, il Single Sign-On. Il Single Sign-On, di seguito SSO, si pone come unico sistema di autenticazione utente per diversi sistemi; permette ad un utente di effettuare la procedura di autenticazione una sola volta e di poter accedere a tutti i sistemi associati con il sistema di SSO. Normalmente i sistemi di SSO offrono all'utente la possibilità di utilizzare diverse tecnologie di autenticazione, la tecnologia più comunemente utilizzata resta username e password. Offre una serie di vantaggi sia dal punto di vista dell'utente che da quello dell'amministratore dei sistemi. Il vantaggio percepito dall'utente è immediato, ricordare un'unica password e un unico username per accedere a molti sistemi, senza dover ripetere la procedura di autenticazione per ognuno di essi; inoltre per modificare la password o i dati dell'identità digitale basta modificarla una sola volta per tutti i sistemi. A vantaggio del Sistem Administrator va la possibilità di avere un database unico per tutti gli utenti, invece di uno per ogni sistema e quindi una gestione centralizzata degli stessi. La centralità e l'unicità della password, per molti sistemi, comporta un unico punto di vulnerabilità per la sicurezza; la perdita o divulgazione di una password, Marco Alfano 566/2817 Pagina 14 di 113

15 permette l'accesso a tutti i sistemi associati al sistema di SSO. Sotto questo punto di vista, l'utente è invogliato ad utilizzare password più complesse, poichè deve ricordarne solo una; ma in alcuni ambiti la sicurezza gioca un ruolo fondamentale, ed è per questo che sono stati creati mezzi per fornire un tipo di autenticazione ancora più sicura: le infrastrutture a chiave pubblica. Un'infrastruttura a chiave pubblica (PKI) consiste in una serie di accordi che consentono a terze parti fidate di verificare e/o farsi garanti dell'identità di un utente e di associare ad esso una chiave pubblica, di solito sotto forma di certificato digitale. La struttura PKI oltre a riguardare l'autorità di certificazione (CA) e i relativi accordi, comprende la Registration Authority e il Certificate Server. Gli utenti si rivolgono alla Registration Authority per richiedere la certificazione delle chiavi; essi si identificano, forniscono la chiave pubblica e l indirizzo . Nel Certificate Server vengono pubblicati i certificati e le liste dei certificati revocati o sospesi. La struttura PKI impone per le CA una struttura di tipo ad albero; ci sono diversi livelli di CA, ognuna ha un certificato firmato da una CA di livello superiore; si viene così a creare una catena di fiducia per le CA. Questo aspetto è molto importante, dato che per poter verificare un certificato bisogna controllare l'attendibilità della CA firmataria;con questo meccanismo è sufficiente risalire la catena per arrivare alla CA Root di cui tutti si fidano. La PKI risolve quattro problemi legati alla sicurezza dell'informazione (PAIN): Privacy: le transazioni sono protette contro gli accessi fraudolenti ai dati. Autenticazione: l'accesso alle applicazioni e ai dati è ristretto a chi può provare la propria identità. Integrità: dati e applicazioni sono protetti dalle modifiche non autorizzate, che vengono rilevate ed evitate. Non-Ripudio: le transazioni sono registrate e riportate in modo tale che se Marco Alfano 566/2817 Pagina 15 di 113

16 dovesse sorgere una controversia, può essere prodotta una prova delle transazioni avvenute. Uno standard che implementa la PKI è lo standard X.509, che definisce formati per i certificati a chiave pubblica e un algoritmo per la validazione. Nel sistema X.509, una CA rilascia un certificato che accoppia una chiave pubblica ad un nome distintivo (Distinguished Name) o ad un nome alternativo (Alternative Name) come un indirizzo . Lo standard X.509 utilizza una crittografia a chiave asimmetrica, questa utilizza due chiavi, una pubblica ed una privata, queste sono indipendenti e non è possibile risalire ad una dall'altra; ogni chiave può essere utilizzata per decriptare le informazioni che ha criptato l'altra. La struttura di un certificato X.509 v3 è la seguente: Marco Alfano 566/2817 Pagina 16 di 113

17 Il meccanismo di creazione di un certificato X.509 è illustrato nel seguente diagramma: L'utente crea le 2 chiavi, pubblica e privata; la chiave privata deve essere custodita dall'utente, mentre la chiave pubblica è inserita, insieme alle informazioni dell'utente, in un contenitore apposito da sottomettere alla CA per essere firmato, il CSR: Illustrazione 7: CSR Marco Alfano 566/2817 Pagina 17 di 113

18 Per confermare l'autenticità del CSR, viene generato l'hash delle informazioni contenute, che viene poi firmato con la chiave privata dell'utente (indicato nell'illustrazione con Signature Algorithm ) e posto in coda al CSR. Il CSR così formato viene inviato alla CA. La CA analizza il contenuto e lo confronta con l'hash ottenuto decriptandolo con la chiave pubblica dell'utente; questo meccanismo permette di sapere con certezza se l'utente possiede la chiave privata associata alla chiave pubblica inviata nel CSR, inoltre il confronto dell'hash permette di confermare l'autenticità del CSR per prevenirne modifiche illecite durante il trasferimento. Se i dati sono confermati la CA aggiunge le proprie informazioni, genera l'hash da tutti i dati e firma l'hash ottenuto con la sua chiave privata, il certificato così generato è completo. Per stabilire una comunicazione client-server protetta, bisogna eseguire l'handshake definito di mutua autenticazione. Il client ed il server devono provare la valida identità del soggetto con cui stanno comunicando. La mutua autenticazione prevede le seguenti fasi: Il client invia il proprio certificato al server Il Server controlla se la CA che ha firmato il certificato è attendibile, risalendo la catena di fiducia delle CA se necessario. Il Server controlla se il certificato è stato manomesso, andando a confrontare l'hash calcolato dai dati del certificato con l'hash decriptato calcolato al momento della firma del certificato dalla CA Opzionalmente, se il certificato è valido, il server può controllare se l'identità associata al certificato è autorizzata ad accedervi. Gli stessi passi vengono eseguiti dal client nei confronti del certificato del server. Dopo la fase di mutua autenticazione, la comunicazione protetta avviene seguendo i Marco Alfano 566/2817 Pagina 18 di 113

19 passi definiti dal presente schema: Illustrazione 8: Esempio di Comunicazione Protetta Dal diagramma è evidente che soltanto il destinatario può decifrare il contenuto del messaggio, dato che è l'unico a possedere la chiave privata necessaria per decriptarlo, questo risolve il problema della privatezza dei dati. Per garantire anche l'autenticità del mittente, il messaggio criptato con la chiave pubblica del destinatario, viene criptato una seconda volta con la chiave privata del mittente, si ha così la certezza che il messaggio sia stato inviato da quel particolare utente, dato che è possibile decriptarlo solo con la chiave pubblica associata all'utente. Marco Alfano 566/2817 Pagina 19 di 113

20 3 Single Sign-On 3.1 Stato dell'arte Il Single Sign-On è un sistema che permette ad un utente di autenticarsi una sola volta e di ottenere l'accesso a tutte le risorse, alle quali è abilitato, senza doversi ri-autenticare. L'implementazione di un SSO può essere riconducibile ad una delle seguenti architetture: Centralizzata: prevede l'utilizzo di un database unico di utenti e una gestione unificata delle politiche di sicurezza. Solitamente utilizzato dai servizi dipendenti da una stessa entità, ad esempio la stessa azienda. Federativa: si basa sul concetto di federazione, due o più entità (aziende) federate tra loro gestiscono i dati di uno stesso utente. L'accesso ad uno dei sistemi comporta l'accesso a tutti i sistemi federati. Cooperativa: ogni sistema gestisce in maniera autonoma il database utenti e le politiche di sicurezza, ma come per l'approccio federativo, l'autenticazione su uno dei sistemi implica l'accesso a tutti i sistemi cooperanti. Il principio di funzionamento base dei sistemi di SSO può essere visto come una struttura Client/Server a 3 livelli: Client layer, Application Layer, Data Layer. Ogni livello svolge un compito ben preciso e si comporta come Server per il livello sovrastante (offre servizi) e come Client per il livello sottostante (utilizza i servizi offerti dai Server). Questo tipo di architettura è definita chiusa, dato che ogni livello può accedere solo al livello immediatamente sottostante; questo comporta un'elevata indipendenza tra i livelli che favorisce la manutenibilità del sistema stesso. L'aggiunta di un nuovo Marco Alfano 566/2817 Pagina 20 di 113

21 sistema non comporta la modifica di altri livelli o la modifica dei sistemi esistenti. L'architettura descritta è rappresentata nel seguente diagramma: Illustrazione 9: Architettura Generica Sistemi SSO Il livello Client identifica il livello utente ovvero le postazioni fisiche che accedono alle applicazioni esistenti e che quindi fanno richieste di servizi al livello sottostante. Il livello Applicazione è l'insieme dei Server sui quali girano le applicazioni, ricevono le richieste dai Client ed offrono il servizio richiesto. Infine, quello Dati è l'insieme dei database dove risiedono le informazioni. Il suo compito è quello di processare le richieste e di restituirle al livello superiore. I livelli applicazione e dati possono risiedere su più macchine o sulla stessa Marco Alfano 566/2817 Pagina 21 di 113

22 macchina. Lo stato di autenticazione di un utente è memorizzato utilizzando un ticket emesso dal sistema SSO (il ticket è detenuto dall'utente). Quando un'applicazione richiede il riconoscimento dell'utente, il ticket gli viene inviato in modo automatico. È compito dell'applicazione contattare il sistema SSO per verificare la validità del ticket ed in caso affermativo richiedere le informazioni utente. Esistono varie forme di ticket, ciascuna dipendente dal tipo di applicazione che si vuole gestire; Per applicazioni web, il ticket è rilasciato sotto forma di cookie da inviare al browser del client (il cookie è un'informazione testuale che il browser associa al dominio di provenienza). Per i sistemi operativi e per le applicazioni, lo stato di autenticazione è memorizzato utilizzando un Ticket Granting Ticket (TGT), composto da un file di identificazione criptato con validità limitata nel tempo ed associato all'indirizzo IP dell'utente. Il TGT è utilizzato mediante il protocollo Kerberos, un protocollo di autenticazione di rete. Il funzionamento dell'intero sistema è descritto analizzando i messaggi scambiati tra i diversi livelli: Marco Alfano 566/2817 Pagina 22 di 113

23 Illustrazione 10: Comunicazione tra livelli I possibili vantaggi derivanti dall'utilizzo dei sistemi di Single Sign-On sono molteplici, fra cui: Gestione centralizzata degli utenti per tutti i portali e le applicazioni esistenti: questo permette di non dover mantenere un database utenti per ogni Marco Alfano 566/2817 Pagina 23 di 113

24 applicazione con tutti i problemi di gestione che questo comporta Gestione dell'autenticazione e delle autorizzazione demandate al sistema SSO e non a carico delle diverse applicazioni: la manutenzione è effettuata modificando direttamente le impostazioni utente presenti nel database centrale. Utilizzo e gestione delle credenziali utente più sicure mediante certificati X.509 in un unico ambiente centralizzato. Senza un SSO, per il loro utilizzo, si sarebbe dovuto integrare in ogni applicazione la loro gestione ed infine, queste ultime, interfacciarle singolarmente con il database utenti. 3.2 Soluzioni a confronto Esistono molti sistemi che svolgono funzionalità di SSO, tra questi alcuni sono in versione commerciale, altri Open Source e quindi di libero utilizzo. Inoltre i sistemi SSO possono gestire diverse tipologie di applicazioni; nel nostro caso l'interesse è rivolto alle applicazioni web. Nel ricercare il sistema SSO si è tenuto conto dell'attuale utilizzo del suddetto in ambienti di produzione ed il grado di supporto offerto in caso di problemi. Dalle informazioni raccolte è stata stilata una tabella comparativa che ci ha permesso di eseguire un rapido confronto dei vari sistemi. Marco Alfano 566/2817 Pagina 24 di 113

25 Marco Alfano 566/2817 Pagina 25 di 113

26 L'analisi effettuata, ci ha permesso di evidenziare vantaggi e svantaggi dei sistemi analizzati: CAS è un sistema Open Source realizzato dalla Jasig, risulta essere un ampiamente compatibile con tutte le piattaforme server e con tutti i linguaggi di programmazione ed è già integrato in molti portali tra cui Liferay. Per contro è stata rilevata la mancanza di una caratteristica essenziale, quella delle autorizzazioni; il sistema CAS ha solo la funzionalità di autenticazione. Il supporto a pagamento è offerto da una società esterna, la Unicon Inc.. Trattandosi di un progetto Open Source, il supporto gratuito è offerto dalla community e dal sito del progetto stesso. OpenSSO è un sistema Open Source realizzato dalla Sun Microsystem, gli sviluppatori di Java, risulta essere un sistema ampiamente compatibile con tutte le piattaforme ed i linguaggi di programmazione, tranne che per il linguaggio PHP, per il quale non è stato ancora realizzato un Agent, ma esiste un SDK già pronto per l'implementazione. È già integrato nativamente in diversi portali, tra cui Liferay. Esistono due versioni di OpenSSO: Express ed Enterprise. Pur avendo le stesse funzionalità, la versione Enterprise è a pagamento e nuove release vengono rilasciate ogni mesi perché maggiormente testato rispetto alla versione Express che invece è Open Source e per la quale si prevede un rilascio di nuove release ogni 3 mesi. Il supporto a pagamento è offerto dalla stessa Sun Microsystem, mentre quello gratuito è offerto dalla community del progetto stesso. Il sistema è stato eletto prodotto dell'anno 2009 tra i software di sicurezza dal sito Developer.com. Josso è un sistema Open Source basato su Java realizzato dalla società Atricore, che ne fornisce anche il supporto a pagamento ed è ampiamente Marco Alfano 566/2817 Pagina 26 di 113

27 compatibile con tutte le piattaforme ed i linguaggi di programmazione attualmente disponibili. Non sono stati trovate informazioni riguardanti l'attuale utilizzo in ambienti operativi. L'aspetto negativo per questo sistema è la non integrazione nativa nel portale Liferay, che risulta disponibile solo come soluzione a pagamento. Shibboleth è un sistema Open Source realizzato dalla società Internet2. Questo sistema ha una limitata compatibilità per quanto riguarda gli Agent con i più comuni linguaggi di programmazione. È integrato nativamente in diversi portali, tra cui Liferay. Il supporto a pagamento è fornito da diverse società esterne al progetto. Il sistema Shibboleth è stato escluso immediatamente come candidato per la sua scarsa compatibilità con linguaggi di programmazione; questo comporterebbe un limitato ambito di utilizzo legato ai soli sistemi compatibili. CAS è risultato essere il sistema attualmente più utilizzato per la sua semplicità di implementazione. La mancanza della funzionalità di autorizzazione costringe, gli utilizzatori, ad implementare un proprio sistema di gestione delle stesse per singola applicazione. Per quanto detto, il suo utilizzo potrebbe essere preso in considerazione solo nel caso in cui ci siano problemi di compatibilità tra il sistema SSO prescelto ed alcune delle applicazioni attualmente utilizzate. OpenSSO è quello che supporta tutti i requisiti richiesti; è ampiamente utilizzato in ambienti di produzione, per cui è considerato un valido candidato. Il sistema Josso, pur essendo un valido candidato in quanto possiede la maggior parte dei requisiti richiesti, non supporta l'integrazione con il portale Liferay; inoltre JOSSO non supporta il protocollo SAML, Security Assertion Markup Language, utilizzato per un SSO Federativo; questo aspetto limita le espansioni future del progetto. Per i motivi descritti il sistema JOSSO è stato Marco Alfano 566/2817 Pagina 27 di 113

28 scartato. 3.3 Scelta del Sistema SSO Per la scelta del sistema si è tenuto conto di diversi fattori, definiti come requisiti base per il sistema SSO: Sistema Open Source. Funzionalità di autorizzazione. Integrazione con il portale Liferay. Supporto autenticazione mediante certificati X.509. Supporto DataBase Utenti di tipo Ldap, nello specifico OpenLdap. Supporto gratuito e/o a pagamento. In definitiva, per quanto detto nel precendete paragrafo, il candidato come futuro sistema SSO della rete UniNA è OpenSSO. OpenSSO è un singolo prodotto che unisce le funzionalità di diversi prodotti SUN, ossia System Access Manager, System Federation Manager e System SAMLv2 Plug-in per i servizi di federazione. OpenSSO fornisce funzioni di access management attraverso l'implementazione di servizi di autenticazione, servizi di autorizzazione basati su policy, servizi di federazione e servizi di sicurezza di web services. OpenSSO ha una struttura di tipo Client/Server composta da un Client SDK, denominato Agent, utilizzato dall'applicazione da proteggere per accedere e comunicare con OpenSSO, un framework di servizi che implementa la logica di business di OpenSSO, e di interfacce di service provider (SPI) utilizzate per estendere le funzionalità di OpenSSO e per estrarre le informazioni presenti nei data store. Marco Alfano 566/2817 Pagina 28 di 113

29 Illustrazione 11: Architettura Client/Server OpenSSO La gestione di tutti i componenti, e quindi del funzionamento di Opensso, può essere effettuata attraverso la console di amministrazione oppure tramite linea di comando attraverso il comando ssoadm. OpenSSO fornisce diverse funzionalità: Controllo Accesso OpenSSO gestisce l'accesso a servizi e a risorse di rete implementando servizi di autenticazione e di autorizzazioni. OpenSSO assicura che l'accesso alle risorse protette sia ristretto ai soli utenti autorizzati. Gestione della federazione Con l'introduzione dei protocolli di federazione, le informazioni di identità ed i diritti di un utente possono essere comunicati tra domini diversi. Configurando un circolo di fiducia e definendo applicazioni e servizi come provider del circolo gli utenti possono associare o collegare le identità locali ai Marco Alfano 566/2817 Pagina 29 di 113

30 provider; le identità locali sono federate e consentono ad un utente di effettuare il login su un identity provider ed utilizzare un service provider federato senza dover effettuare di nuovo l'operazione di autenticazione. OpenSSO supporta diverse tecnologie di federazione: in particolare SAML v. 1 e 2, WS-Federation e Liberty Alliance Project Identity Federation Framework. Sicurezza dei web services Un web services è un servizio o una applicazione che espone una funzionalità di business o di infrastruttura attraverso una interfaccia di rete neutra rispetto al linguaggio ed indipendente dalla piattaforma. Il web service definisce la sua interfaccia (per esempio il formato dei messaggi scambiati) attraverso il Web Service Description Language (WSDL) e comunica usando il protocollo SOAP e messaggi XML. Il client web services (WSC) comunica con il web service provider (WSP) attraverso un intermediario, tipicamente un firewall o un load balancer. Assicurare l'integrità, la confidenzialità e la sicurezza dei web services è critico sia per i fornitori del servizio che per gli utilizzatori. Il modello di sicurezza adottato da OpenSSO identifica l'utente e ne preserva l'identità attraverso interazioni multiple, mantenendo l'integrità e la riservatezza dei dati, attraverso l'uso di tecnologie esistenti. In particolare OpenSSO implementa i seguenti standard di sicurezza di web services: Liberty Alliance Project Identity Web Services Framework (ID-WSF), WS-I Basic Security Profile e WS-Trust. Identity web services Con l'attuale release di OpenSSO il sistema espone alcune funzioni come semplici identity web services consentendo agli sviluppatori di invocarli nello sviluppo dei propri applicativi attraverso l'ide utilizzato. Gli identity web services sono disponibibili usando SOAP e WSDL oppure REST Marco Alfano 566/2817 Pagina 30 di 113

31 (Representational State Transfer). I web services non richiedono il deploy di un agent o di un proxy ed includono le seguenti funzionalità: autenticazione per validare le credenziali utente; autorizzazione per consentire l'accesso alla risorsa protetta; provisioning per la gestione degli attributi utente e l'auto registrazione; log delle operazioni. Infine, l'analisi ha evidenziato la mancanza di un Agent scritto in PHP; questa, pur essendo una piccola limitazione, ha portato a considerare nel progetto anche il sistema CAS, da utilizzare in aggiunta ad OpenSSO, data la presenza nell'infrastruttura UniNa di applicazioni scritte in PHP. 3.4 Sicurezza L'utilizzo di sistemi centralizzati in una rete comporta la formazione di punti di vulnerabilità per il sistema sia dal punto di vista della sicurezza dei dati, sia dal punto di vista dell'affidabilità. La non disponibilità momentanea di un sistema centralizzato può portare alla congestione e all'inutilizzo di tutte risorse informatiche, ragion per cui l'analisi di un sistema centralizzato di SSO non può avvenire senza considerare anche l'aspetto sicurezza. Di per sé un sistema di SSO prevede particolari misure di sicurezza per garantire un accesso sicuro alle sue funzioni. Per un sistema di SSO un punto critico per la sicurezza è il database utenti; l'accesso da parte di un malintenzionato al database, comprometterebbe tutto il sistema e di conseguenza anche i sistemi ad esso connessi, poichè nel database sono presenti anche le credenziali amministratore che non pongono limiti all'utilizzatore. È evidente che un primo sistema di protezione deve essere presente per l'accesso al database utenti. Per i servizi Ldap il metodo per eseguire un accesso sicuro è quello di utilizzare i certificati X.509. L'implementazione di questo tipo di accesso implica la creazione Marco Alfano 566/2817 Pagina 31 di 113

32 di: un certificato per il server Ldap certificati per i client che vogliono accedervi un sistema per indicare al server Ldap di quali CA firmatarie ci si può fidare. Questo ultimo passo è realizzato tramite un TrustStore, al cui interno sono memorizzati i certificati delle CA attendibili. Questo garantisce che soltanto un sistema con un certificato valido può accedere ai dati in esso contenuti. Altro problema non legato strettamente alla sicurezza dei dati, ma all'affidabilità del sistema è la fault tolerance. Un unico sistema centrale gestisce in modo autonomo tutte le funzioni di accesso; se per qualsiasi malfunzionamento il sistema dovesse non essere disponibile, gli utenti si ritroverebbero a non poter utilizzare i sistemi dipendenti da esso. Nasce quindi il problema di garantire il funzionamento anche in queste circostanze. Una possibile soluzione al problema è quella di creare sistemi ridondanti, cioè fornire ad un sistema un suo clone che entrerà in funzione nel caso in cui il primo sia non disponibile. Si è parlato di sistemi in generale poiché il malfunzionamento non interessa solo il sistema di SSO, ma anche il servizio Ldap. In definitiva, un sistema di ridondanza deve essere progettato per ogni punto critico dell'intera infrastruttura. Marco Alfano 566/2817 Pagina 32 di 113

33 4 Progetto: Autenticazione mediante X.509 e Single Sign- On 4.1 Contesto di lavoro Il progetto si inserisce in un contesto di lavoro complesso, composto da un'architettura di rete ridondata con suddivisione del carico di lavoro e da diverse tipologie di sistemi. Il progetto nasce per integrare un sistema di autenticazione centralizzata con l'enterprise Information Portal utilizzato nel progetto S.Co.P.E.. IL progetto S.Co.P.E. realizza un sistema di calcolo basato sulle più moderne tecnologie di calcolo distribuito operante con paradigma GRID. All'interno dello stesso si inserisce anche l'esperimento ATLAS, che utilizza le risorse GRID e l'ambiente del data center di ScoPE per elaborare l'enorme mole di dati. 4.2 OpenSSO: Autenticazione Quando un utente od una applicazione richiede l'accesso ad un contenuto protetto presente su un server, un policy agent, installato sullo stesso server, intercetta la richiesta e la esamina. Se alla richiesta non è associato un token di sessione valido, il policy agent indirizza la richiesta dell'utente a OpenSSO. OpenSSO richiederà le credenziali di autenticazione (username e password o un certificato x.509), se sono valide allora l'utente è autorizzato ad accedere alla risorsa. Successivamente all'autenticazione, l'accesso al contenuto richiesto è determinato dal policy agent che valuta le politiche associate alla risorsa con l'identità autenticata. Le policy, create utilizzando OpenSSO, identificano a quali identità è consentito l'accesso e per quali risorse, specificando le condizioni sotto le quali l'autorizzazione è valida. Il risultato della valutazione delle policy è quello di permettere o di negare l'accesso alla risorsa protetta. Il funzionamento descritto è illustrato nell'immagine seguente: Marco Alfano 566/2817 Pagina 33 di 113

34 Illustrazione 12: Principio di funzionamento OpenSSO Di seguito vengono riportati, come ulteriore livello di dettaglio, i messaggi scambiati tra le parti coinvolte nel processo di autenticazione: In particolare, l'agent presente in Liferay, utilizza il seguente schema di funzionamento: Illustrazione 13: Comunicazione tra le parti Marco Alfano 566/2817 Pagina 34 di 113

35 Activity 1: Agent presente in Liferay 4.3 Architettura presente Le risorse già presenti nell'infrastruttura di rete UniNA che necessitano di una descrizione per l'attuale progetto sono: Il portale web Liferay. Il database utenti OpenLdap. Liferay è un portale Open Source utilizzato come front-end nel progetto SCoPE. Permette di raggruppare applicazioni e dati in un'unica interfaccia grafica, utilizzando le così dette Portlet, infatti la sua definizione precisa è portlet container. Le portlet sono dei moduli web riusabili all'interno di un portale che sono strutturati come finestre all'interno di una pagina web; essendo finestre, queste possono essere spostate, chiuse o ridotte come le finestre utilizzate nelle normali applicazioni. Liferay offre la possibilità di integrarsi con i più noti sistemi di Single Sign-On permettendo quindi un autenticazione unica per l'utilizzo di tutte le risorse del portale. L'installazione standard di Liferay contiene già moltissime portlet, come ad esempio la gestione delle mail, gestione dei documenti, agenda e ed altre, ed ogni utente può personalizzare la propria Homepage con le applicazioni desiderate. Liferay è utilizzato da molte società, tra cui: Cisco Developer Network Marco Alfano 566/2817 Pagina 35 di 113

36 French Ministry of Defense Lufthansa Flight Training Il database utenti, presente nella rete UniNA utilizza il sistema OpenLdap. OpenLdap implementa il protocollo Ldap per l'accesso ai directory. Utilizza come database di default Oracle Berkeley DB, in cui ogni applicazione che lo utilizza decide la struttura dati composta da nome=valore. Allo stato attuale Liferay e OpenLdap sono totalmente separati; anche se Liferay consente l'integrazione con un database utenti Ldap, la sua funzione è solo quella di importare gli utenti nel database interno di Liferay, operazione insufficiente ad implementare la funzionalità di Single Sign-On. 4.4 Analisi dei requisiti Il progetto è volto a realizzare l'integrazione di un sistema di Single Sign-On nell'attuale infrastruttura di rete UniNA. In particolare il progetto è volto all'integrazione del sistema di SSO con il portale web utilizzato nel progetto SCoPE. Il Sistema definitivo deve prevedere le seguenti funzionalità: Auteticazione mediante credenziali utenti semplici, UID fornita dalla stessa UniNA. Autenticazione mediante certificati asimmetrici X.509, rilasciati attualmente per l'utilizzo delle risorse GRID del progetto ScoPE. Profilatura degli utenti che accedono a Liferay utilizzando il concetto di gruppo di appartenenza. Utilizzo per l'autenticazione dell'attuale database utenti presente nell'infrastruttura. È stato stabilito che l'intero sistema venga utilizzato da cinque gruppi principali Marco Alfano 566/2817 Pagina 36 di 113

37 di utenti: Guest User SuperUser Admin Administrator Il Guest è l'utente non autenticato al sistema, può soltanto visualizzare alcune sezioni del portale, senza poter eseguire nessuna operazione. L'User è l'utente autenticato al sistema, può eseguire un'insieme limitato di operazioni. Il SuperUser può eseguire un'insieme più ampio di operazioni rispetto a quello dell'utente. L'Admin può eseguire la maggior parte delle operazioni di gestione e di visualizzazione delle Portlets. L'Administrator è l'amministratore del portale Liferay, può eseguire tutte le operazioni di gestione e visualizzazione del portale e delle Portlets 4.5 Realizzazione del prototipo Per analizzare l'integrazione tra i sistemi, precedentemente descritti, è stato realizzato un prototipo utilizzando Liferay, OpenSSO e OpenLdap. Le installazioni di Liferay ed OpenSSO sono state prima effettuate con configurazioni standard ed indipendenti per studiarne il funzionamento; in seguito le configurazioni sono state modificate per permettere l'integrazione tra di esse. In appendice, sono state inserite tutte le procedure ed i file di configurazione Marco Alfano 566/2817 Pagina 37 di 113

38 necessari per la realizzazione del sistema prototipale. Da questa fase sono emersi vari problemi di integrazione che saranno descritti in dettaglio nel paragrafo 4.7 Implementazione. Questa fase di analisi ci ha permesso di identificare un problema presente nell'agent di Liferay, ovvero quello di non supportare la gestione dei gruppi di appartenenza degli utenti; da ciò è scaturita una fase di progettazione e sviluppo software per effettuare la modifica del suddetto agent. 4.6 Progettazione Architettura Il funzionamento della procedura di Login effettuata dall'agent OpenSSO presente in Liferay è descritto nel seguente diagramma: Activity 2: Login Prima della Modifica Da questo si evince che la modifica da attuare per gestire i gruppi deve essere fatta per due circostanze diverse: Alla creazione del nuovo utente nel database Liferay Quando l'utente è già presente nel database Liferay Nel primo caso, poiché l'utente non è associato a nessun gruppo, basta associarlo a tutti quelli passati da OpenSSO; mentre nel secondo, dato che Marco Alfano 566/2817 Pagina 38 di 113

39 l'utente è già associato a qualche gruppo, bisogna eseguire una verifica ed un eventuale modifica delle associazioni esistenti Scelte progettuali Analizzando le classi esistenti, si è scelto di implementare la modifica andando a modificare il diagramma, precedentemente mostrato, nel seguente modo: Activity 3: Metodo Login dopo la modifica Liferay utilizza nelle sue configurazioni i termini Ruolo e Gruppo, questi anche se apparentemente molto simili, vengono utilizzati da Liferay in modo diverso, permettendo di effettuare diverse tipologie di configurazioni. Poiché OpenSSO gestisce soltanto i Gruppi, e poiché le nostre esigenze di configurazione, ci portano a dover convertire il gruppo di OpenSSO in un Ruolo di Liferay, si è deciso di completare la modifica effettuata, permettendo all'amministratore del sistema di poter scegliere in quale tipologia, ruolo o gruppo, convertire il gruppo passato da OpenSSO; inoltre, poichè per associare l'utente ad un gruppo o ad un ruolo questi devono già essere presenti in Liferay, si è deciso di aggiungere un metodo, sempre controllabile dall'amministratore, Marco Alfano 566/2817 Pagina 39 di 113

40 che permettesse l'inserimento automatico dei gruppi e dei ruoli mancanti. Si è sfruttata per questa tipologia di configurazione una caratteristica di Liferay, cioè quella di utilizzare un file di configurazione testuale per impostare diversi parametri di configurazione del comportamento di Liferay e dei sui plugin. In questo modo, l'amministratore, può controllare completamente il comportamento dell'agent, potendo scegliere le seguenti impostazioni: open.sso.convert.role=[true/false] open.sso.convert.group=[true/false] open.sso.auto.role=[true/false] open.sso.auto.group=[true/false] Come funzionamento di default, si è deciso di disabilitare le funzionalità implementate, dando la possibilità di utilizzare l'agent nella sua configurazione originaria. Le conversioni, in ruolo o gruppo, sono completamente indipendenti, ed è possibile attivare l'una o l'altra o entrambe indifferentemente; la stessa cosa vale per l'autoinserimento. Trattandosi di una modifica, si è mantenuta l'architettura già presente per la strutturazione del codice. Per questo motivo, i metodi implementati hanno la stessa visibilità dei metodi già contenuti nella classe. Per ridurre il numero di file da modificare, e quindi per facilitare l'integrazione della modifica in altre installazioni, i metodi sono stati inseriti nelle classi già esistenti; in questo modo le classi modificate sono solamente quattro, OpenSSOAutoLogin e OpenSSOUtil che gestiscono la procedura di login e la conversione dei gruppi, PropsKeys e PropsValues che contengono i nomi dei parametri, già specificati, utilizzati nel file di configurazione. Segue un diagramma Activity del metodo updateroles implementato: Marco Alfano 566/2817 Pagina 40 di 113

41 Activity 4: Metodo updateroles Marco Alfano 566/2817 Pagina 41 di 113

42 4.6.3 Descrizione e Diagramma delle classi sviluppate È stato analizzato il funzionamento della procedura di login eseguita dall'agent OpenSSO esistente andando a ricercare le classi coinvolte in questo processo. Illustrazione 14: Classi prima della modifica L'interfaccia AutoLogin viene implementata dalla classe OpenSSOAutoLogin. OpenSSOAutoLogin utilizza per svolgere alcune delle sue funzioni le classi OpenSSOUtil, PrefsPropsUtil, PropsKeys e PropsValues. L'Agent effettua il login utilizzando il metodo pubblico login della classe OpenSSOAutoLogin, la procedura si compone dei seguenti passi: Verifica se l'autenticazione mediante OpenSSO è stata abilitata valutando il valore dell'impostazione open.sso.auth.enabled mediante il metodo getboolean della classe PrefsPropsUtil. Richiama il metodo OpenSSOUtil.isAuthenticated per verificare se il Token è valido Se il Token non è valido esce dal metodo Login; altrimenti richiama dal database di Liferay il nome dei parametri utente passati da OpenSSO: uid, mail, givenname, sn. Marco Alfano 566/2817 Pagina 42 di 113

43 Richiama il metodo OpenSSOUtil.getAttributes che restituisce gli attributi dell'utente passati da OpenSSO. Il metodo è un parser che esegue una richiesta HTTP ad OpenSSO all'indirizzo "/identity/attributes". OpenSSO restituisce i seguenti dati relativi all'utente che ha effettuato il login: userdetails.token.id=aqic5wm2ly4sfcwqtuenmh7kuv+yywx9llda2aorrrbcc4ade=# userdetails.role=id=admin,ou=group,dc=opensso,dc=java,dc=net userdetails.role=id=administrator,ou=group,dc=opensso,dc=java,dc=net userdetails.attribute.name=uid userdetails.attribute.value=marc.alfano userdetails.attribute.name=mail userdetails.attribute.value=marc.alfano@studenti.unina.it userdetails.attribute.name=userpassword userdetails.attribute.value={shaoclia5psrdlfc5gejlrptvsht7w= userdetails.attribute.name=sn userdetails.attribute.value=alfano userdetails.attribute.name=cn userdetails.attribute.value=marco alfano (marc.alfano@studenti.unina.it) userdetails.attribute.name=givenname userdetails.attribute.value=marco userdetails.attribute.name=inetuserstatus userdetails.attribute.value=active userdetails.attribute.name=agenttype userdetails.attribute.name=objectclass userdetails.attribute.value=organizationalperson userdetails.attribute.value=person userdetails.attribute.value=posixaccount userdetails.attribute.value=inetlocalmailrecipient userdetails.attribute.value=shadowaccount userdetails.attribute.value=inetorgperson userdetails.attribute.value=inetuser userdetails.attribute.value=top Da notare che il parser non include nella lista dei parametri i campi userdatails.role, che contengono i gruppi di appartenenza dell'utente. Controlla se nel database utenti di Liferay è già presente l'utente utilizzando il metodo UserLocalServiceUtil.getUserByScreenName e ricercandolo tramite l'uid. Se l'utente è già presente nel database, il login in Liferay è completato; altrimenti l'utente viene inserito nel database di liferay tramite il metodo adduser; questo inserisce l'utente impostando solo i campi givenname e sn passati da OpenSSO, tutti gli altri valori sono fittizi. uid, mail, Marco Alfano 566/2817 Pagina 43 di 113

44 Per quanto analizzato, di seguito, viene riportato il diagramma delle classi che evidenzia le modifiche effettuate: Illustrazione 15: Classi dopo la modifica Di seguito saranno spiegate la parti del codice da me realizzato di maggior interesse: Come prima operazione, è stato modificato il parser getattributes della classe OpenSSOUtil per fare in modo che venissero presi anche gli attributi riguardanti i gruppi di appartenenza dell'utente. Marco Alfano 566/2817 Pagina 44 di 113

45 127) while ((line = br.readline())!= null) { 128) //User Groups from OpenSSO 129) if(line.startswith("userdetails.role")){ 130) String name="memberof"; 131) String value = line.replacefirst("userdetails.role=id=", ""); 132) value = value.split(",")[0]; 133) namevalues.put(name + Integer.toString(x), value); 134) x++; 135) 136) //end 137) else { 138) if (line.startswith("userdetails.attribute.name=")) { 139) 140) String name = line.replacefirst("userdetails.attribute.name=", ""); 141) line = br.readline(); 142) if (line.startswith("userdetails.attribute.value=")) { 143) String value = line.replacefirst("userdetails.attribute.value=", ""); 144) namevalues.put(name, value); Codice 1: Modifica effettuata al metodo getattributes La modifica è stata effettuata per recuperare la voce NOME_GRUPPO dalla seguente riga: userdetails.role=id=nome_gruppo,ou=group,dc=opensso,dc=java,dc=net la riga 129 controlla il tipo di riga, se inizia con userdetails.role, la riga riguarda il nome di un gruppo; allora la riga 131 rimuove dalla stringa la seguente sottostringa: userdetails.role=id=, in questo modo il nome del gruppo si trova all'inizio della stringa; la riga 132, utilizzando la funzione split, divide la stringa utilizzando il separatore, ed inserisce tutte le sottostringhe in un array. La riga 133 a questo punto, inserisce il nome del gruppo nell'elenco dei parametri passati, il nome del parametro è indicato alla riga 130; il risultato sarà: memberofx=nome_gruppo la X inizialmente ha valore 1, e viene incrementata dalla riga 134 quando viene trovato un gruppo di appartenenza; questa tipologia di implementazione permette di associare l'utente ad un numero illimitato di gruppi. L'operazione di modifica descritta non è sufficiente però ad implementare la gestione dei ruoli e dei gruppi, in quanto il metodo adduser non gestisce le Marco Alfano 566/2817 Pagina 45 di 113

46 informazioni aggiuntive, per cui sono stati aggiunti altri metodi alla classe OpenSSOAutoLogin: getroles setroles setgroups UpdateRoles UpdateGroups Per verificare le impostazioni scelte nel file di configurazione, sono state inserite le seguenti linee di codice: //read opensso settings boolean convert_role= PrefsPropsUtil.getBoolean(PropsKeys.OPEN_SSO_CONVERT_GROUP_TO_ROLE, PropsValues.OPEN_SSO_CONVERT_GROUP_TO_ROLE); boolean convert_group= PrefsPropsUtil.getBoolean( PropsKeys.OPEN_SSO_CONVERT_GROUP_TO_GROUP, PropsValues.OPEN_SSO_CONVERT_GROUP_TO_GROUP); boolean auto_role=prefspropsutil.getboolean( PropsKeys.OPEN_SSO_AUTO_CREATE_ROLE, PropsValues.OPEN_SSO_AUTO_CREATE_ROLE); boolean auto_group=prefspropsutil.getboolean( PropsKeys.OPEN_SSO_AUTO_CREATE_GROUP, PropsValues.OPEN_SSO_AUTO_CREATE_GROUP); Codice 2: Recupero informazioni configurazione Queste salvano le impostazioni specificate rispettivamente nelle variabili booleane: convert_role, convert_group, auto_role e auto_group. Per richiamare i suddetti metodi, sono state inserite in opportune posizioni nel codice esistente le seguenti chiamate: Marco Alfano 566/2817 Pagina 46 di 113

47 132) try { 133) user = UserLocalServiceUtil.getUserByScreenName( 134) companyid, screenname); 135) 136) //*** If user already exist into liferay database, if enabled, update user Group and Role ********************* 137) 138) if (convert_role){ 139) updateroles(namevalues, companyid, screenname, auto_role); 140) 141) if (convert_group){ 142) updategroups(namevalues, companyid, screenname, auto_group); Codice 3: Chiamata per aggiornamento la riga 132 verifica l'esistenza nel database di Lyferay dell'utente, se questo è presente, allora bisogna verificare e aggiornare i gruppi e/o i ruoli di appartenenza dell'utente in questione; se è attiva la conversione dei ruoli (riga 138) richiama il metodi updateroles (riga 139), se è attiva la conversione dei gruppi (riga 141) richiama il metodo updategroups (riga 142). I metodi updateroles e updategroup si comportano nello stesso modo, per cui verrà descritto nel dettaglio solo updateroles. 164) user = adduser(companyid, firstname, lastname, address, screenname,locale); 165) 166) //*** If enabled, set Roles and/or Groups for new User *********************************************************** 167) 168) //get userid from liferay database 169) UserId=UserLocalServiceUtil.getUserIdByScreenName(companyId, screenname); 170) 171) //set user role from opensso group to Liferay Role 172) if (convert_role){ 173) setroles(namevalues, UserId, companyid, auto_role); 174) 175) //set user group from opensso group to Liferay Group 176) if (convert_group){ 177) setgroups(namevalues, UserId, companyid, auto_group); 178) 179) //***************************************************************** ********************** Codice 4: Chiamate per nuovi utenti Se l'utente non è ancora presente nel database di Liferay, viene aggiunto Marco Alfano 566/2817 Pagina 47 di 113

48 eseguendo la riga 164; poiché è un nuovo utente, questo non è associato a nessun gruppo e/o ruolo, viene quindi recuperato l'id identificativo associato all'utente appena creato (riga 169) e se attiva la conversione dei ruoli (riga 172) invocato il metodo setroles (riga 173), se è attiva la conversione dei gruppi (riga 176) invocato il metodo setgroups (riga 177). I metodi setroles e setgroups si comportano nello stesso modo, per cui verrà descritto nel dettaglio solo setroles. Segue la descrizione dei metodi realizzati: 235) //get user group name from opensso 236) protected List<String> getroles(map<string, String> namevalues){ 237) String name="memberof"; 238) List<String> Roles = new ArrayList<String>(); 239) int x=1; 240) while(namevalues.get(name+x)!=null){ 241) Roles.add(nameValues.get(name+x)); 242) x++; 243) 244) return Roles; 245) Codice 5: Metodo getroles Il metodo getroles, inserisce in una lista composta da stringhe i nomi dei gruppi di appartenenza dell'utente. Come descritto precedentemente, i nomi dei gruppi sono identificati all'interno della lista dei parametri come: memberofx=nome_gruppo, quindi, la X viene inizializzata al valore 1, e viene eseguito un ciclo while che va a testare l'esistenza dell'attributo di nome memberofx (riga 240); se trovato, viene recuperato il relativo valore (riga 241) ed incrementata la variabile X per testare il successivo attributo (riga 242). Alla fine del ciclo while, che termina quando sono stati recuperati tutti i nomi dei gruppi, viene restituita la lista contenente i suddetti gruppi (riga 244). Marco Alfano 566/2817 Pagina 48 di 113

49 249) //set user Role from opensso group to liferay role 250) protected void setroles(map<string, String> namevalues, long UserId, long companyid, boolean auto_role) throws PortalException, SystemException, NoSuchRoleException{ 252) 253) List<String> UserRoles=getRoles(nameValues); 254) Iterator<String> itr = UserRoles.iterator(); 255) long[] UserIds = new long[1]; 256) UserIds[0]=UserId; 257) long RoleId=0; 258) String RoleName=null; 259) while(itr.hasnext()){ 260) RoleName=itr.next(); 261) 262) try{ 263) //get role ID from liferay 264) RoleId=RoleLocalServiceUtil.getRole(companyId, RoleName).getRoleId(); 265) 266) //set user group to liferay user 267) UserLocalServiceUtil.setRoleUsers(RoleId, UserIds); 268) 269) catch (NoSuchRoleException e){ 270) if (auto_role){ 271) RoleLocalServiceUtil.addRole(UserId, companyid, RoleName, "Created Automatically from OpenSSO", 0); 272) 273) RoleId=RoleLocalServiceUtil.getRole(companyId, RoleName).getRoleId(); 274) 275) UserLocalServiceUtil.setRoleUsers(RoleId, UserIds); 276) 277) 278) 279) Codice 6: Metodo setroles Il metodo setroles, imposta i ruoli di appartenenza di un utente appena creato. La prima operazione che esegue è quella di recuperare i gruppi passati da OpenSSO invocando il metodo getroles descritto precedentemente (riga 253), viene creato un oggetto iteratore dalla lista dei gruppi per scorrerla completamente (riga 254). A questo punto con un ciclo while scorre tutta la lista dei gruppi, e per ognuno di essi esegue due operazioni: recupera l'id identificativo del ruolo dal database di Liferay (riga 264), e se il ruolo esiste associa l'utente a quel ruolo (riga 267); altrimenti, viene catturata l'eccezione Marco Alfano 566/2817 Pagina 49 di 113

50 NoSuchRoleException (riga 269) e, se è attiva la creazione automatica dei ruoli (riga 270), viene creato prima il ruolo (riga 271) e poi associatogli l'utente (riga 275). Marco Alfano 566/2817 Pagina 50 di 113

51 281) //Update user role from opensso group to liferay role 282) protected void updateroles(map<string, String> namevalues, long companyid, String screenname, boolean auto_role) throws PortalException, SystemException, NoSuchRoleException{ 283) 284) //get userid from liferay 285) Long UserId=UserLocalServiceUtil.getUserIdByScreenName(companyId, screenname); 286) 287) //get user roles from liferay 288) List<Role> UserRoles = RoleLocalServiceUtil.getUserRoles(UserId); 289) 290) Iterator<Role> itruserroles=userroles.iterator(); 291) 292) //get group name from opensso 293) List<String> openssorole = getroles(namevalues); 294) 295) Role role=null; 296) while(itruserroles.hasnext()){ 297) role=itruserroles.next(); 298) 299) if(!openssorole.contains(role.getname())) 300) UserLocalServiceUtil.deleteRoleUser(role.getRoleId(), UserId); 301) //else remove the group from list 302) else openssorole.remove(role.getname()); 304) 305) Iterator<String> itropenssoroles=openssorole.iterator(); 306) long RoleId=0; 307) long[] UserIds = new long[1]; 308) UserIds[0]=UserId; 309) String RoleName=null; 310) 311) //add the new role to liferay user 312) while(itropenssoroles.hasnext()){ 313) RoleName=itrOpenssoRoles.next(); 314) try{ 316) //get role ID from liferay 317) RoleId=RoleLocalServiceUtil.getRole(companyId, RoleName).getRoleId(); 318) 319) UserLocalServiceUtil.setRoleUsers(RoleId, UserIds); 322) catch (NoSuchRoleException e){ 323) if (auto_role){ 324) RoleLocalServiceUtil.addRole(UserIds[0], companyid, RoleName, "Created Automatically from OpenSSO", 0); 325) 326) RoleId=RoleLocalServiceUtil.getRole(companyId, RoleName).getRoleId(); 327) 328) UserLocalServiceUtil.setRoleUsers(RoleId, UserIds); Codice 7: Metodo updateroles Marco Alfano 566/2817 Pagina 51 di 113

52 Il metodo updateroles aggiorna i ruoli assegnati ad un utente già esistente nel database di Liferay. La riga 285 recupera l'id dell'utente presente nel database di Liferary. Viene recuperata la lista dei ruoli associati all'utente nel database di Liferay (riga 288) e la lista dei gruppi passati da OpenSSO tramite il metodo getroles (riga 293); viene creato un oggetto iteratore dalla lista dei ruoli di Liferay che permette di scorrere completamente la lista (riga 290). A questo punto viene eseguito un ciclo while, su l'iteratore appena creato, che svolge la seguente funzione: per ogni ruolo associato all'utente nel database Liferay, viene controllata l'esistenza dello stesso nella lista dei gruppi passati da OpenSSO, e se il gruppo non è più presente, viene rimossa l'associazione dal database di Liferay (riga 300); altrimenti, se l'utente è ancora associato a quel ruolo, il ruolo stesso viene rimosso dalla lista dei gruppi passati da OpenSSO (riga 302). Alla fine di questo ciclo, la lista dei gruppi passati da OpenSSO contiene solo i gruppi per i quali non esiste ancora un associazione per l'utente nel database Liferay. A questo punto viene creato l'oggetto iteratore di questi gruppi (riga 305), viene recuperato per ognuno di essi l'id corrispondente nel database di Liferay (riga 317), se il ruolo esiste nel database, viene inserita l'associazione corrispondente (riga 319); altrimenti, l'eccezione NoSuchRoleException viene catturata (riga 322) e gestita nel seguente modo: se è attivo l'auto inserimento dei ruoli (riga 323), viene creato il nuovo ruolo (riga 324) e l'utente viene associato a quest'ultimo (riga 328). Per poter gestire i parametri di configurazione inseriti nel file portalext.properties, sono state create le relative voci nelle classi PropsKeys e PropsValues: Marco Alfano 566/2817 Pagina 52 di 113

53 905) public static final String OPEN_SSO_AUTO_CREATE_GROUP = "open.sso.auto.create.group"; 906) 907) public static final String OPEN_SSO_AUTO_CREATE_ROLE = "open.sso.auto.create.role"; 908) 909) public static final String OPEN_SSO_CONVERT_GROUP_TO_GROUP = "open.sso.convert.group"; 910) 911) public static final String OPEN_SSO_CONVERT_GROUP_TO_ROLE = "open.sso.convert.role"; Codice 8: PropsKeys Questa classe contiene il nome delle impostazioni assegnabili a Liferay, da come è evidente, sono stati assegnati i nomi delle impostazioni per l'auto creazione dei gruppi e dei ruoli (righe 905 e 907), e i nomi per abilitare le conversione dei gruppi di OpenSSO in ruoli di Liferay (riga 911) e per abilitare la conversione dei gruppi di OpenSSO in gruppi di Liferay (riga 909). 942) public static final boolean OPEN_SSO_AUTO_CREATE_GROUP = 943) GetterUtil.getBoolean( PropsUtil.get(PropsKeys.OPEN_SSO_AUTO_CREATE_GROUP)); 944) 945) public static final boolean OPEN_SSO_AUTO_CREATE_ROLE = 946) GetterUtil.getBoolean( PropsUtil.get(PropsKeys.OPEN_SSO_AUTO_CREATE_ROLE)); 947) 948) public static final boolean OPEN_SSO_CONVERT_GROUP_TO_GROUP = 949) GetterUtil.getBoolean( PropsUtil.get(PropsKeys.OPEN_SSO_CONVERT_GROUP_TO_GROUP)); 950) 951) public static final boolean OPEN_SSO_CONVERT_GROUP_TO_ROLE = 952) GetterUtil.getBoolean( PropsUtil.get(PropsKeys.OPEN_SSO_CONVERT_GROUP_TO_ROLE)); Codice 9: PropsValues La classe PropsValues, contiene i metodi per la lettura dei valori delle impostazioni assegnate a Liferay. In questa quindi è stata inserita la lettura dei valori assegnati alle impostazioni dell'agent; trattandosi di valori booleani, sono stati utilizzati i metodi, già presenti in Liferay per gestire questa tipologia di valore. Marco Alfano 566/2817 Pagina 53 di 113

54 4.6.4 Casi d'uso In figura viene riportato il caso d'uso relativo al progetto sviluppato: Illustrazione 16: Caso d'uso Login Si evince che quando l'utente Guest, accede a Liferay, può effettuare la procedura di login; per portare a termine detta procedura, Liferay ha bisogno della collaborazione del sistema esterno OpenSSO Diagrammi di sequenza La fase di progettazione ha portato alla realizzazione dei diagrammi di sequenza che illustrano le comunicazioni tra le classi coinvolte nella procedura di login. Il seguente diagramma illustra il metodo login prima della modifica effettuata: Marco Alfano 566/2817 Pagina 54 di 113

55 Sequence 1: Metodo Login originale Per non appesantire la lettura del diagramma, non sono stati inseriti i metodi che recuperano le impostazioni da alcune variabili utilizzate dalla procedura di login. Marco Alfano 566/2817 Pagina 55 di 113

56 Nel successivo invece, sono illustrate le invocazioni dei due metodi creati per la gestione dei gruppi di appartenenza: Sequence 2: Metodo Login dopo la modifica Anche in questo caso non sono stati inseriti i metodi che recuperano i valori di alcune variabili utilizzate dalla procedura di login, anche la lettura delle variabili contenenti le nuove impostazioni per la gestione della modifica non sono state inserite per non appesantire il diagramma. Marco Alfano 566/2817 Pagina 56 di 113

57 I sequence dei metodi updateroles e setroles sono stati analizzati separatamente per migliorare la comprensione dei diagrammi: Sequence 3: Metodo SetRoles Marco Alfano 566/2817 Pagina 57 di 113

58 Sequence 4: Metodo UpdateRoles Marco Alfano 566/2817 Pagina 58 di 113

59 4.7 Implementazione Integrazione Liferay OpenSSO Sono state utilizzate tutte le ultime versioni; per Liferay la versione con Apache Tomcat ed OpenSSO 8, distribuito su Apache Tomcat versione Di seguito riporto gli accorgimenti, fondamentali, da utilizzare per il corretto funzionamento dell'ambiente realizzato: OpenSSO e Liferay devono avere lo stesso dominio di appartenenza, poiché il ticket rilasciato da OpenSSO è associato al dominio stesso; se Liferay è sotto un dominio diverso, il ticket non viene rilevato da Liferay e quindi l'autenticazione fallisce. La configurazione di OpenSSO deve essere fatta utilizzando per la sua procedura d'installazione il nome completo del server, altrimenti sorgono problemi con il ticket rilasciato, poichè associa un dominio errato al ticket stesso. In OpenSSO bisogna abilitare la proprietà "Encode Cookie Value". Se non viene fatto, al momento del Login, avviene un redirect infinito tra OpenSSO e Liferay. Marco Alfano 566/2817 Pagina 59 di 113

60 Illustrazione 17: Parametri Configurazione OpenSSO Oltre alla configurazione per l'abilitazione alla gestione dei gruppi utente, sono state sostituite le classi originali con quelle modificate ed illustrate precedentemente. Tutta la procedura di integrazione è stata allegata in appendice Integrazione OpenSSO LDAP Per legare OpenSSO alla directory Ldap bisogna eseguire alcune modifiche essenziali da apportare alla struttura Ldap esistente: Marco Alfano 566/2817 Pagina 60 di 113

61 Aggiungere una OU contenente i gruppi utente Modificare la OU creata al passo precedente, aggiungendo i gruppi per gli utenti, con l'obbligo di avere come objectclass groupofuniquenames. Ogni utente deve contenere l'objectclass inetuser, ed impostare il campo inetuserstatus. Se quest'ultimo campo non viene impostato, OpenSSO considera attivi tutti gli utenti. Impostare il campo memberof ad uno o più gruppi utente creati Utilizzando lo schema Ldap di OpenSSO disponibile per OpenLdap, non è possibile associare, utilizzando l'attributo memberof, un utente a più gruppi di appartenenza; inoltre, data la grande quantità di utenti presenti nel Ldap UniNA, si è scelto di non aggiungere agli utenti l'objectclass inetuser. Questa modifica comporta però che non è possibile impostare gli attributi inetuserstatus e memberof poiché non sono presenti nello schema, quindi si sono scelti due attributi già disponibili e non utilizzati. La scelta è ricaduta sull'attributo gecos per inetuserstatus, e pager per memberof. OpenSSO supporta diversi User DataStore, e permette di amministrarli mediante un pannello di gestione web da cui è possibile aggiungere, eliminare e modificare i database degli utenti. Illustrazione 18: Pannello di Amministrazione User Data Stores La procedura di integrazione è descritta in appendice. Marco Alfano 566/2817 Pagina 61 di 113

62 4.7.3 Descrizione del funzionamento Quando un utente guest, cioè non autenticato al sistema, seleziona il link relativo al Login su Liferay; viene rediretto da Liferay alla pagina di Login di OpenSSO. L'utente inserisce le proprie credenziali ed OpenSSO controlla, nei data stores configurati, se le credenziali inserite sono valide ed associate ad un utente attivo. In caso affermativo, OpenSSO genera un Ticket che viene inviato al Browser dell'utente sotto forma di cookie e redirige l'utente alla pagina di gestione del Login di Liferay. Liferay a questo punto utilizza la classe OpenSSOAutoLogin per completare il Login. La classe, trovando un ticket, richiede ad OpenSSO la validità dello stesso; se il ticket è valido, richiede ad OpenSSO gli attributi riguardanti l'utente. Il sistema OpenSSO, risponde inviandao una pagina html contente i dati dell'utente ed in seguito elaborata da un parser. A questo punto, viene controllata l'esistenza dell'utente sul database di Liferay ed in base a questo controllo vengono seguite due strade diverse: se l'utente è già presente nel database; con la modifica della classe effettuata, vengono verificate e nel caso aggiornate le associazioni dei gruppi di appartenenza dell'utente. Altrimenti, l'utente viene inserito nel database di Liferay e gli vengono associati i relativi gruppi di appartenenza. A questo punto il Login è completato, e l'utente si ritrova connesso al sistema. La gestione delle autorizzazioni da parte di Liferay viene effettuata in due modi diversi: utilizzando i gruppi di appartenenza, oppure mediante i ruoli associati all'utente. Poiché attraverso i ruoli, è possibile gestire la visibilità e l'utilizzo di ogni singola portlet, le associazioni dei gruppi, sono state convertite in associazioni di ruoli dalla classe modificata. Quando l'utente richiede di effettuare il Logout da Liferay, cliccando sul relativo Link, l'utente viene rediretto all'url impostato per il Logout con Marco Alfano 566/2817 Pagina 62 di 113

63 OpenSSO; quest'ultimo, ricevendo il ticket che aveva precedentemente inviato al browser, lo rende invalido, e redirige l'utente alla pagina guest di Liferay, che si ritrova non autenticato poiché il ticket memorizzato ancora nel browser non è più valido. Marco Alfano 566/2817 Pagina 63 di 113

64 CONCLUSIONI Il lavoro svolto realizza una infrastruttura di gestione dell accesso centralizzata, mantenendo la tanto agognata identità unica per ogni utente; permettendo, agli stessi, di accedere a tutte le risorse informatiche, utilizzando sempre le stesse credenziali di accesso. Il progetto è stato eseguito in due fasi distinte: nella prima, sono stati analizzati i diversi sistemi di Single Sign-On oggi esistenti, per poi individuare quello più adatto ad un ambiente eterogeneo come la rete UniNa; nella seconda, invece, è stata eseguita l analisi, la progettazione e la modifica di alcune classi Java presenti nel codice sorgente di Liferay per consentire la gestione dei gruppi utente. In generale lo scopo del progetto è esattamente quello di semplificare l intera gestione degli utenti aumentando la produttività e semplificando la possibile integrazione con applicazioni già esistenti grazie alla scelta di un sistema di Single Sign-On modulare e flessibile come quello analizzato ed utilizzato. L intero progetto tiene conto anche di eventuali sviluppi futuri come l introduzione di nuovi metodi di accesso basati, soprattutto, sui certificati digitali. Dal punto di vista più generale, l'attività svolta ha fornito le basi per una futura integrazione del Single Sign-On nella rete UniNA; è previsto infatti che dopo un periodo di test all interno del progetto S.Co.P.E., il sistema verrà esteso a tutte le applicazioni della rete ed in seguito adottato in ambiente di produzione. Gli utilizzatori di Liferay da tempo richiedevano le modifiche da me realizzate, per cui ho provveduto ad inviare al team di sviluppo di Liferay il codice e la relativa documentazione, per poterlo direttamente integrare nella prossima versione. Allo stato attuale, il codice realizzato e successivamente inviato è stato accettato, validato e si trova in fase di testing. Ho ricevuto decine e decine di richieste da parte degli utilizzatori di Liferay, molto sensibili a questa problematica, di inviare le classi compilate. Questi ultimi ne hanno apprezzato immediatamente le potenzialità, Marco Alfano 566/2817 Pagina 64 di 113

65 formulando ulteriori richieste che hanno consentito la progettazione di una ulteriore aggiunta ovvero la gestione dei gruppi e della relativa configurazione direttamente dal file di properties di Liferay. Tutto ciò mi ha permesso di contribuire in un progetto Open Source importante come Liferay. Marco Alfano 566/2817 Pagina 65 di 113

66 APPENDICE A: Schema LDAP version: 1 dn: dc=unina,dc=it objectclass: dcobject objectclass: organization dc: unina o: unina dn: ou=opensso,dc=unina,dc=it objectclass: organizationalunit objectclass: top ou: opensso dn: ou=istituzionali,ou=opensso,dc=unina,dc=it objectclass: organizationalunit objectclass: top ou: istituzionali dn: ou=docenti,ou=istituzionali,ou=opensso,dc=unina,dc=it objectclass: organizationalunit objectclass: top ou: Docenti dn: ou=polo DELLE SCIENZE E DELLE TECNOLOGIE (400000),ou=Docenti,ou=istituzionali,ou=opensso,dc=unina,dc=it objectclass: top objectclass: organizationalunit objectclass: inetlocalmailrecipient objectclass: posixaccount cn: POLO DELLE SCIENZE E DELLE TECNOLOGIE (400000) description: gidnumber: 100 homedirectory: /home/ maillocaladdress: doc_400000@unina.it mailroutingaddress: doc_400000@unina.it ou: POLO DELLE SCIENZE E DELLE TECNOLOGIE (400000) uid: doc_ uidnumber: dn: ou=dipartimento DI SCIENZE FISICHE (100560),ou=POLO DELLE SCIENZE E DELLE TECNOLOGIE (400000),ou=Docenti,ou=istituzionali,ou=opensso,dc=unina,dc=it objectclass: top objectclass: organizationalunit objectclass: inetlocalmailrecipient objectclass: posixaccount cn: DIPARTIMENTO DI SCIENZE FISICHE (100560) description: gidnumber: 100 homedirectory: /home/ maillocaladdress: doc_100560@unina.it mailroutingaddress: doc_100560@unina.it ou: DIPARTIMENTO DI SCIENZE FISICHE (100560) uid: doc_ Marco Alfano 566/2817 Pagina 66 di 113

67 uidnumber: dn: cn=docente docente DI SCIENZE FISICHE (100560),ou=POLO DELLE SCIENZE E DELLE TECNOLOGIE (400000),ou=Docenti,ou=istituzionali,ou=opensso,dc=unina,dc=it objectclass: inetorgperson objectclass: inetlocalmailrecipient objectclass: posixaccount objectclass: shadowaccount objectclass: organizationalperson objectclass: person objectclass: top objectclass: inetuser businesscategory: N carlicense: {SHA98O8HYCOBHMq32eZZczDTKeuNEE= cn: docente docente (docente@unina.it) departmentnumber: DDDDDD11D11D111D description: cn=user,ou=gruppi,ou=opensso,dc=unina,dc=it employeenumber: employeetype: Docenti gidnumber: 100 givenname: docente homedirectory: /home/docente inetuserstatus: Active internationalisdnnumber: loginshell: /bin/false mail: docente@unina.it mail: mat98765@unina.it maillocaladdress: docente@unina.it mailroutingaddress: docente@unina.it ou: docente docente (docente@unina.it) physicaldeliveryofficename: physicaldeliveryofficename: FACOLTA' DI SCIENZE MATEMATICHE, FISICHE E NATURALI sn: docente title: Docenti di ruolo di Ia fascia uid: docente uidnumber: userpassword:: e1niqx1rs0r2whrluwfutc8wa3lhn1d1a1bdduhozwc9 dn: ou=personalet.a.,ou=istituzionali,ou=opensso,dc=unina,dc=it objectclass: organizationalunit objectclass: top ou: PersonaleT.A. dn: ou=altra struttura (100000),ou=PersonaleT.A.,ou=istituzionali,ou=opensso,dc=unina,dc=it objectclass: top objectclass: organizationalunit objectclass: inetlocalmailrecipient objectclass: posixaccount cn: ALTRA STRUTTURA (100000) description: gidnumber: 100 homedirectory: /home/ maillocaladdress: @unina.it mailroutingaddress: @unina.it ou: altra struttura (100000) Marco Alfano 566/2817 Pagina 67 di 113

68 uid: doc_ uidnumber: dn: ou=csi - centro di ateneo per i servizi informativi (295550),ou=altra struttura (100000),ou=PersonaleT.A.,ou=istituzionali,ou=opensso,dc=unina,dc=it objectclass: top objectclass: organizationalunit objectclass: inetlocalmailrecipient objectclass: posixaccount cn: CSI - CENTRO DI ATENEO PER I SERVIZI INFORMATIVI (295550) description: gidnumber: 100 homedirectory: /home/ maillocaladdress: @unina.it mailroutingaddress: @unina.it ou: csi - centro di ateneo per i servizi informativi (295550) uid: doc_ uidnumber: dn: cn=personale personale(personale@unina.it),ou=csi - centro di ateneo per i servizi informativi (295550),ou=altra struttura (100000),ou=PersonaleT.A.,ou=istituzionali,ou=opensso,dc=unina,dc=it objectclass: inetorgperson objectclass: inetlocalmailrecipient objectclass: posixaccount objectclass: shadowaccount objectclass: organizationalperson objectclass: inetuser objectclass: person objectclass: top businesscategory: N carlicense: {SHA98O8HYCOBHMq32eZZczDTKeuNEE= cn: personale personale(personale@unina.it) departmentnumber: PPPPPP11P11P111P description: cn=user,ou=gruppi,ou=opensso,dc=unina,dc=it employeenumber: employeetype: PersonaleTA gidnumber: 100 givenname: personale homedirectory: /home/personale inetuserstatus: Active loginshell: /bin/false mail: personale@unina.it mail: mat11111@unina.it maillocaladdress: personale@unina.it mailroutingaddress: personale@unina.it ou: personale personale(personale@unina.it) physicaldeliveryofficename: physicaldeliveryofficename: CSI - CENTRO DI ATENEO PER I SERVIZI INFORMATIVI sn: personale title: Personale tecnico amm.vo uid: personale uidnumber: userpassword:: e1niqx05oe84sfldt0jitxezmmvawmn6rfrlzxvoruu9 dn: ou=studenti,ou=opensso,dc=unina,dc=it Marco Alfano 566/2817 Pagina 68 di 113

69 objectclass: organizationalunit objectclass: top ou: studenti dn: ou=attivi,ou=studenti,ou=opensso,dc=unina,dc=it objectclass: top objectclass: organizationalunit ou: attivi dn: ou=facolta' DI SCIENZE MATEMATICHE FISICHE E NATURALI (17),ou=attivi,ou=studenti,ou=opensso,dc=unina,dc=it objectclass: top objectclass: organizationalunit objectclass: inetlocalmailrecipient objectclass: posixaccount cn: FACOLTA' DI SCIENZE MATEMATICHE FISICHE E NATURALI (17) description: 17 gidnumber: 100 homedirectory: /home/17 maillocaladdress: fac17@unina.it mailroutingaddress: fac17@unina.it ou: FACOLTA' DI SCIENZE MATEMATICHE FISICHE E NATURALI (17) uid: fac17 uidnumber: dn: ou=informatica (566),ou=FACOLTA' DI SCIENZE MATEMATICHE FISICHE E NATURALI (17),ou=attivi,ou=studenti,ou=opensso,dc=unina,dc=it objectclass: top objectclass: organizationalunit objectclass: inetlocalmailrecipient objectclass: posixaccount cn: INFORMATICA (566) description: 566 gidnumber: 100 homedirectory: /home/566 maillocaladdress: cdl566@unina.it mailroutingaddress: cdl566@unina.it ou: INFORMATICA (566) uid: cdl566 uidnumber: dn: cn=studente studente (studente@studenti.unina.it),ou=informatica (566),ou=FACOLTA' DI SCIENZE MATEMATICHE FISICHE E NATURALI (17),ou=attivi,ou=studenti,ou=opensso,dc=unina,dc=it objectclass: inetorgperson objectclass: inetlocalmailrecipient objectclass: posixaccount objectclass: shadowaccount objectclass: organizationalperson objectclass: person objectclass: top objectclass: inetuser carlicense: {SHA98O8HYCOBHMq32eZZczDTKeuNEE= cn: studente studente (studente@studenti.unina.it) departmentnumber: SSSSSS11S11S111S description: cn=user,ou=gruppi,ou=opensso,dc=unina,dc=it Marco Alfano 566/2817 Pagina 69 di 113

70 description: cn=admin,ou=gruppi,ou=opensso,dc=unina,dc=it employeenumber: employeetype: Studente gidnumber: 100 givenname: studente homedirectory: /home/studente inetuserstatus: Active loginshell: /bin/bash mail: mail: maillocaladdress: maillocaladdress: mailroutingaddress: ou: studente studente physicaldeliveryofficename: 566 roomnumber: sn: studente street: Inactive uid: studente uidnumber: userpassword:: e1niqx1py00rwvhqauvmmm9wsnredzk2vxjeys90exm9 dn: cn=marco alfano (566),ou=FACOLTA' DI SCIENZE MATEMATICHE FISICHE E NATURALI (17),ou=attivi,ou=studenti,ou=opensso,dc=unina,dc=it objectclass: inetorgperson objectclass: organizationalperson objectclass: inetlocalmailrecipient objectclass: posixaccount objectclass: shadowaccount objectclass: person objectclass: top objectclass: inetuser cn: marco alfano (marc.alfano@studenti.unina.it) description: cn=administrator,ou=gruppi,ou=opensso,dc=unina,dc=it description: cn=admin,ou=gruppi,ou=opensso,dc=unina,dc=it gidnumber: 23 givenname: marco homedirectory: 23 inetuserstatus: Active mail: marc.alfano@studenti.unina.it sn: alfano title: Active uid: marc.alfano uidnumber: 34 userpassword:: e1niqx1pq2xjytvqc1jebgzdnwdfskxychr2c0h0n3c9 dn: cn=simona alfano (simona.alfano@studenti.unina.it),ou=informatica (566),ou=FACOLTA' DI SCIENZE MATEMATICHE FISICHE E NATURALI (17),ou=attivi,ou=studenti,ou=opensso,dc=unina,dc=it objectclass: inetorgperson objectclass: posixaccount objectclass: top objectclass: inetuser objectclass: inetlocalmailrecipient cn: simona alfano (simona.alfano@studenti.unina.it) description: cn=superuser,ou=gruppi,ou=opensso,dc=unina,dc=it Marco Alfano 566/2817 Pagina 70 di 113

71 gidnumber: 1 givenname: simona homedirectory: /home/users/simona.alfano inetuserstatus: Active loginshell: /bin/sh mail: simona.alfano@studenti.unina.it sn: alfano uid: simona.alfano uidnumber: 1000 userpassword:: e1niqx1eafdsnm9lthuyr1mryunla1rtvdvjrxdjd1e9 dn: cn=studente2 studente (studente2@studenti.unina.it),ou=informatica (566),ou=FACOLTA' DI SCIENZE MATEMATICHE FISICHE E NATURALI (17),ou=attivi,ou=studenti,ou=opensso,dc=unina,dc=it objectclass: inetorgperson objectclass: inetlocalmailrecipient objectclass: posixaccount objectclass: shadowaccount objectclass: organizationalperson objectclass: person objectclass: top objectclass: inetuser carlicense: {SHA98O8HYCOBHMq32eZZczDTKeuNEE= cn: studente2 studente (studente2@studenti.unina.it) departmentnumber: SSSSSS11S11S111S description: cn=user,ou=gruppi,ou=opensso,dc=unina,dc=it description: cn=admin,ou=gruppi,ou=opensso,dc=unina,dc=it employeenumber: employeetype: Studente gidnumber: 100 givenname: studente homedirectory: /home/studente inetuserstatus: Active loginshell: /bin/bash mail: studente@studenti.unina.it mail: mat @studenti.unina.it maillocaladdress: studente@studenti.unina.it maillocaladdress: mat @studenti.unina.it mailroutingaddress: studente@studenti.unina.it ou: studente studente (studente@studenti.unina.it) physicaldeliveryofficename: 566 roomnumber: sn: studente2 street: Inactive uid: studente2 uidnumber: userpassword:: e1niqx1py00rwvhqauvmmm9wsnredzk2vxjeys90exm9 dn: ou=gruppi,ou=opensso,dc=unina,dc=it objectclass: organizationalunit objectclass: top ou: gruppi dn: cn=user,ou=gruppi,ou=opensso,dc=unina,dc=it objectclass: groupofuniquenames Marco Alfano 566/2817 Pagina 71 di 113

72 objectclass: top cn: User uniquemember: cn=studente studente (566),ou=FACOLTA' DI SCIENZE MATEMATICHE FISICHE E NATURALI (17),ou=attivi,ou=studenti,ou=opensso,dc=unina,dc=it dn: cn=admin,ou=gruppi,ou=opensso,dc=unina,dc=it objectclass: groupofuniquenames objectclass: top cn: admin uniquemember: cn=studente studente (studente@studenti.unina.it),ou=informatica (566),ou=FACOLTA' DI SCIENZE MATEMATICHE FISICHE E NATURALI (17),ou=attivi,ou=studenti,ou=opensso,dc=unina,dc=it dn: cn=superuser,ou=gruppi,ou=opensso,dc=unina,dc=it objectclass: groupofuniquenames objectclass: top cn: superuser uniquemember: cn=studente studente (studente@studenti.unina.it),ou=informatica (566),ou=FACOLTA' DI SCIENZE MATEMATICHE FISICHE E NATURALI (17),ou=attivi,ou=studenti,ou=opensso,dc=unina,dc=it dn: cn=administrator,ou=gruppi,ou=opensso,dc=unina,dc=it objectclass: groupofnames objectclass: top cn: Administrator member: cn=studente studente (studente@studenti.unina.it),ou=informatica (566),ou=FACOLTA' DI SCIENZE MATEMATICHE FISICHE E NATURALI (17),ou=attivi,ou=studenti,ou=opensso,dc=unina,dc=it APPENDICE B: Codice delle classi ################## OpenSSOAutoLogin ################## /** * Copyright (c) Liferay, Inc. All rights reserved. * * Permission is hereby granted, free of charge, to any person obtaining a copy * of this software and associated documentation files (the "Software"), to deal * in the Software without restriction, including without limitation the rights * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell * copies of the Software, and to permit persons to whom the Software is * furnished to do so, subject to the following conditions: * * The above copyright notice and this permission notice shall be included in * all copies or substantial portions of the Software. * * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE Marco Alfano 566/2817 Pagina 72 di 113

73 * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE * SOFTWARE. */ package com.liferay.portal.security.auth; import com.liferay.portal.nosuchroleexception; import com.liferay.portal.nosuchuserexception; import com.liferay.portal.nosuchusergroupexception; import com.liferay.portal.portalexception; import com.liferay.portal.systemexception; import com.liferay.portal.kernel.log.log; import com.liferay.portal.kernel.log.logfactoryutil; import com.liferay.portal.kernel.util.localeutil; import com.liferay.portal.kernel.util.stringpool; import com.liferay.portal.kernel.util.validator; import com.liferay.portal.kernel.util.webkeys; import com.liferay.portal.model.role; import com.liferay.portal.model.usergroup; import com.liferay.portal.model.user; import com.liferay.portal.service.rolelocalserviceutil; import com.liferay.portal.service.usergrouplocalserviceutil; import com.liferay.portal.service.servicecontext; import com.liferay.portal.service.userlocalserviceutil; import com.liferay.portal.servlet.filters.sso.opensso.openssoutil; import com.liferay.portal.theme.themedisplay; import com.liferay.portal.util.portalutil; import com.liferay.portal.util.prefspropsutil; import com.liferay.portal.util.propskeys; import com.liferay.portal.util.propsvalues; import com.liferay.util.pwdgenerator; import java.util.arraylist; import java.util.calendar; import java.util.iterator; import java.util.list; import java.util.locale; import java.util.map; import javax.servlet.http.httpservletrequest; import javax.servlet.http.httpservletresponse; /** * <a href="openssoautologin.java.html"><b><i>view Source</i></b></a> * Brian Wing Shun Chan Prashant Dighe * */ public class OpenSSOAutoLogin implements AutoLogin { public String[] login( Marco Alfano 566/2817 Pagina 73 di 113

74 HttpServletRequest request, HttpServletResponse response) { String[] credentials = null; try { long companyid = PortalUtil.getCompanyId(request); if (!PrefsPropsUtil.getBoolean( companyid, PropsKeys.OPEN_SSO_AUTH_ENABLED, PropsValues.OPEN_SSO_AUTH_ENABLED)) { return credentials; String serviceurl = PrefsPropsUtil.getString( companyid, PropsKeys.OPEN_SSO_SERVICE_URL); if (!OpenSSOUtil.isAuthenticated(request, serviceurl)) { return credentials; String screennameattr = PrefsPropsUtil.getString( companyid, PropsKeys.OPEN_SSO_SCREEN_NAME_ATTR, PropsValues.OPEN_SSO_SCREEN_NAME_ATTR); String addressattr = PrefsPropsUtil.getString( companyid, PropsKeys.OPEN_SSO_ _ADDRESS_ATTR, PropsValues.OPEN_SSO_ _ADDRESS_ATTR); String firstnameattr = PrefsPropsUtil.getString( companyid, PropsKeys.OPEN_SSO_FIRST_NAME_ATTR, PropsValues.OPEN_SSO_FIRST_NAME_ATTR); String lastnameattr = PrefsPropsUtil.getString( companyid, PropsKeys.OPEN_SSO_LAST_NAME_ATTR, PropsValues.OPEN_SSO_LAST_NAME_ATTR); //read opensso settings boolean convert_role=prefspropsutil.getboolean(propskeys.open_sso_convert_group_to_ ROLE, PropsValues.OPEN_SSO_CONVERT_GROUP_TO_ROLE); boolean convert_group=prefspropsutil.getboolean(propskeys.open_sso_convert_group_to _GROUP, PropsValues.OPEN_SSO_CONVERT_GROUP_TO_GROUP); boolean auto_role=prefspropsutil.getboolean(propskeys.open_sso_auto_create_role, PropsValues.OPEN_SSO_AUTO_CREATE_ROLE); boolean auto_group=prefspropsutil.getboolean(propskeys.open_sso_auto_create_group, PropsValues.OPEN_SSO_AUTO_CREATE_GROUP); Map<String, String> namevalues = OpenSSOUtil.getAttributes( request, serviceurl); String screenname = namevalues.get(screennameattr); Marco Alfano 566/2817 Pagina 74 di 113

75 String address = namevalues.get( addressattr); String firstname = namevalues.get(firstnameattr); String lastname = namevalues.get(lastnameattr); null"); if (Validator.isNull( Address)) { throw new AutoLoginException(" address is User user = null; long UserId=0; try { user = UserLocalServiceUtil.getUserByScreenName( companyid, screenname); //*** If user already exist into liferay database, if enabled, update user Group and Role ********************* if (convert_role){ System.out.println("OpenSSO Convert Group To Role Enabled for update"); updateroles(namevalues, companyid, screenname, auto_role); else System.out.println("OpenSSO Convert Group To Role Disabled for update"); if (convert_group){ System.out.println("OpenSSO Convert Group To GROUP Enabled for update"); updategroups(namevalues, companyid, screenname, auto_group); else System.out.println("OpenSSO Convert Group To Group Disabled for update"); //************************************************************************* *************************** catch (NoSuchUserException nsue) { ThemeDisplay themedisplay = (ThemeDisplay)request.getAttribute( WebKeys.THEME_DISPLAY); Locale locale = LocaleUtil.getDefault(); if (themedisplay!= null) { some users // ThemeDisplay should never be null, but // complain of this error. Cause is unknown. locale = themedisplay.getlocale(); user = adduser(companyid, firstname, lastname, Marco Alfano 566/2817 Pagina 75 di 113

76 address, screenname,locale); //*** If enabled, set Roles and/or Groups for new User *********************************************************** //get userid from liferay database UserId=UserLocalServiceUtil.getUserIdByScreenName(companyId, screenname); //set user role from opensso group to Liferay Role if (convert_role){ System.out.println("OpenSSO Convert Group To Role Enabled for new"); setroles(namevalues, UserId, companyid, auto_role); else System.out.println("OpenSSO Convert Group To Role Disabled for new"); //set user group from opensso group to Liferay Group if (convert_group){ System.out.println("OpenSSO Convert Group To GROUP Enabled for new"); setgroups(namevalues, UserId, companyid, auto_group); else System.out.println("OpenSSO Convert Group To group Disabled for new"); //************************************************************************* ************** credentials = new String[3]; credentials[0] = String.valueOf(user.getUserId()); credentials[1] = user.getpassword(); credentials[2] = Boolean.TRUE.toString(); catch (Exception e) { _log.error(e, e); return credentials; protected User adduser( long companyid, String firstname, String lastname, String address, String screenname, Locale locale) throws Exception { long creatoruserid = 0; boolean autopassword = false; String password1 = PwdGenerator.getPassword(); String password2 = password1; boolean autoscreenname = false; Marco Alfano 566/2817 Pagina 76 di 113

77 password2, firstname, birthdaymonth, organizationids, String openid = StringPool.BLANK; String middlename = StringPool.BLANK; int prefixid = 0; int suffixid = 0; boolean male = true; int birthdaymonth = Calendar.JANUARY; int birthdayday = 1; int birthdayyear = 1970; String jobtitle = StringPool.BLANK; long[] groupids = null; long[] organizationids = null; long[] roleids = null; long[] usergroupids = null; boolean send = false; ServiceContext servicecontext = new ServiceContext(); return UserLocalServiceUtil.addUser( creatoruserid, companyid, autopassword, password1, autoscreenname, screenname, address, openid, locale, middlename, lastname, prefixid, suffixid, male, birthdayday, birthdayyear, jobtitle, groupids, roleids, usergroupids, send , servicecontext); private static Log _log = LogFactoryUtil.getLog(OpenSSOAutoLogin.class); //*********************get user group name from opensso ************************************************ protected List<String> getroles(map<string, String> namevalues){ String name="memberof"; List<String> Roles = new ArrayList<String>(); int x=1; while(namevalues.get(name+x)!=null){ Roles.add(nameValues.get(name+x)); x++; return Roles; //************************************************************************* ****************************** //*********************set user Role from opensso group to liferay role********************************** protected void setroles(map<string, String> namevalues, long UserId, long companyid, boolean auto_role) throws PortalException, SystemException, NoSuchRoleException{ List<String> UserRoles=getRoles(nameValues); Iterator<String> itr = UserRoles.iterator(); long[] UserIds = new long[1]; Marco Alfano 566/2817 Pagina 77 di 113

78 UserIds[0]=UserId; long RoleId=0; String RoleName=null; while(itr.hasnext()){ RoleName=itr.next(); try{ RoleName).getRoleId(); //get role ID from liferay RoleId=RoleLocalServiceUtil.getRole(companyId, //set user group to liferay user UserLocalServiceUtil.setRoleUsers(RoleId, UserIds); catch (NoSuchRoleException e){ if (auto_role){ RoleLocalServiceUtil.addRole(UserId, companyid, RoleName, "Created Automatically from OpenSSO", 1); RoleId=RoleLocalServiceUtil.getRole(companyId, RoleName).getRoleId(); UserLocalServiceUtil.setRoleUsers(RoleId, UserIds); //************************************************************************* ********************* //*** Update user role from opensso group to liferay role ************************************** protected void updateroles(map<string, String> namevalues, long companyid, String screenname, boolean auto_role) throws PortalException, SystemException, NoSuchRoleException{ //get userid from liferay Long UserId=UserLocalServiceUtil.getUserIdByScreenName(companyId, screenname); //get user roles from liferay List<Role> UserRoles = RoleLocalServiceUtil.getUserRoles(UserId); Iterator<Role> itruserroles=userroles.iterator(); //get group name from opensso List<String> openssorole = getroles(namevalues); Role role=null; while(itruserroles.hasnext()){ role=itruserroles.next(); //if the role is removed from opensso, then remove the role from lifery user if(!openssorole.contains(role.getname())) Marco Alfano 566/2817 Pagina 78 di 113

79 UserLocalServiceUtil.deleteRoleUser(role.getRoleId(), UserId); //else remove the group from list else openssorole.remove(role.getname()); Iterator<String> itropenssoroles=openssorole.iterator(); long RoleId=0; long[] UserIds = new long[1]; UserIds[0]=UserId; String RoleName=null; //add the new role to liferay user while(itropenssoroles.hasnext()){ RoleName=itrOpenssoRoles.next(); try{ //get role ID from liferay RoleId=RoleLocalServiceUtil.getRole(companyId, RoleName).getRoleId(); UserLocalServiceUtil.setRoleUsers(RoleId, UserIds); catch (NoSuchRoleException e){ if (auto_role){ RoleLocalServiceUtil.addRole(UserIds[0], companyid, RoleName, "Created Automatically from OpenSSO", 1); RoleId=RoleLocalServiceUtil.getRole(companyId, RoleName).getRoleId(); UserLocalServiceUtil.setRoleUsers(RoleId, UserIds); //************************************************************************* ******************************* //SET_GROUPS***********************set user group from opensso to liferay group************************** protected void setgroups(map<string, String> namevalues, long UserId, long companyid, boolean auto_group) throws PortalException, SystemException, NoSuchRoleException{ List<String> UserGroups=getRoles(nameValues); Iterator<String> itr = UserGroups.iterator(); long[] UserIds = new long[1]; UserIds[0]=UserId; long GroupId=0; String GroupName=null; while(itr.hasnext()){ Marco Alfano 566/2817 Pagina 79 di 113

80 GroupName=itr.next(); try{ //get role ID from liferay GroupId=RoleLocalServiceUtil.getRole(companyId, GroupName).getRoleId(); UserIds); //set user group to liferay user UserLocalServiceUtil.setUserGroupUsers(GroupId, catch (NoSuchRoleException e){ if (auto_group){ UserGroupLocalServiceUtil.addUserGroup(UserId, companyid, GroupName, "Created Automatically from OpenSSO"); GroupId=RoleLocalServiceUtil.getRole(companyId, GroupName).getRoleId(); //set User Group UserLocalServiceUtil.setUserGroupUsers(GroupId, UserIds); //UPDATE_GROUP*****************************update user group from opensso group to liferay group************ protected void updategroups(map<string, String> namevalues, long companyid, String screenname, boolean auto_group) throws PortalException, SystemException, NoSuchRoleException{ //get userid from liferay Long UserId=UserLocalServiceUtil.getUserIdByScreenName(companyId, screenname); long[] UserIds = new long[1]; UserIds[0]=UserId; //get user roles from liferay List<UserGroup> UserGroups = UserGroupLocalServiceUtil.getUserUserGroups(UserId); Iterator<UserGroup> itrusergroups=usergroups.iterator(); //get group name from opensso List<String> openssorole = getroles(namevalues); UserGroup Group=null; while(itrusergroups.hasnext()){ Group=itrUserGroups.next(); //if the role is removed from opensso, then remove the role from lifery user Marco Alfano 566/2817 Pagina 80 di 113

81 if(!openssorole.contains(group.getname())) UserLocalServiceUtil.unsetUserGroupUsers(Group.getUserGroupId(), UserIds); //else remove the group from list else openssorole.remove(group.getname()); Iterator<String> itropenssoroles=openssorole.iterator(); long GroupId=0; String GroupName=null; //add the new role to liferay user while(itropenssoroles.hasnext()){ GroupName=itrOpenssoRoles.next(); try{ //get role ID from liferay GroupId=UserGroupLocalServiceUtil.getUserGroup(companyId, GroupName).getUserGroupId(); UserLocalServiceUtil.setUserGroupUsers(GroupId, UserIds); catch (NoSuchUserGroupException e){ if (auto_group){ UserGroupLocalServiceUtil.addUserGroup(UserId, companyid, GroupName, "Created Automatically from OpenSSO"); GroupId=UserGroupLocalServiceUtil.getUserGroup(companyId, GroupName).getUserGroupId(); UserLocalServiceUtil.setUserGroupUsers(GroupId, UserIds); Marco Alfano 566/2817 Pagina 81 di 113

82 ################## OpenSSOUtil ################## /** * Copyright (c) Liferay, Inc. All rights reserved. * * Permission is hereby granted, free of charge, to any person obtaining a copy * of this software and associated documentation files (the "Software"), to deal * in the Software without restriction, including without limitation the rights * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell * copies of the Software, and to permit persons to whom the Software is * furnished to do so, subject to the following conditions: * * The above copyright notice and this permission notice shall be included in * all copies or substantial portions of the Software. * * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE * SOFTWARE. */ package com.liferay.portal.servlet.filters.sso.opensso; import com.liferay.portal.kernel.log.log; import com.liferay.portal.kernel.log.logfactoryutil; import com.liferay.portal.kernel.util.stringpool; import com.liferay.portal.kernel.util.stringutil; import com.liferay.util.cookieutil; import java.io.bufferedreader; import java.io.ioexception; import java.io.inputstream; import java.io.inputstreamreader; import java.io.outputstreamwriter; import java.net.httpurlconnection; import java.net.malformedurlexception; import java.net.url; import java.util.arraylist; import java.util.hashmap; import java.util.list; import java.util.map; import java.util.concurrent.concurrenthashmap; Marco Alfano 566/2817 Pagina 82 di 113

83 import javax.servlet.http.httpservletrequest; /** * <a href="openssoutil.java.html"><b><i>view Source</i></b></a> * * <p> * See * </p> * Prashant Dighe Brian Wing Shun Chan * */ public class OpenSSOUtil { public static Map<String, String> getattributes( HttpServletRequest request, String serviceurl) { return _instance._getattributes(request, serviceurl); public static String[] getcookienames(string serviceurl) { return _instance._getcookienames(serviceurl); public static String getsubjectid( HttpServletRequest request, String serviceurl) { return _instance._getsubjectid(request, serviceurl); public static void setcookieproperty(httpservletrequest request, HttpURLConnection urlc, String[] cookienames) { public static boolean isauthenticated( HttpServletRequest request, String serviceurl) throws IOException { return _instance._isauthenticated(request, serviceurl); private OpenSSOUtil() { private Map<String, String> _getattributes( HttpServletRequest request, String serviceurl) { Map<String, String> namevalues = new HashMap<String, String>(); String url = serviceurl + _GET_ATTRIBUTES; try { URL urlobj = new URL(url); Marco Alfano 566/2817 Pagina 83 di 113

84 HttpURLConnection urlc = (HttpURLConnection)urlObj.openConnection(); urlc.setdooutput(true); urlc.setrequestmethod("post"); urlc.setrequestproperty( "Content-type", "application/x-www-formurlencoded"); String[] cookienames = _getcookienames(serviceurl); _setcookieproperty(request, urlc, cookienames); OutputStreamWriter osw = new OutputStreamWriter( urlc.getoutputstream()); osw.write("dummy"); osw.flush(); int responsecode = urlc.getresponsecode(); if (responsecode == HttpURLConnection.HTTP_OK) { BufferedReader br = new BufferedReader( new InputStreamReader((InputStream)urlc.getContent())); String line = null; int x=1; while ((line = br.readline())!= null) { //User Groups from OpenSSO if(line.startswith("userdetails.role")){ String name="memberof"; String value = line.replacefirst("userdetails.role=id=", ""); value = value.split(",")[0]; //System.out.println(name + Integer.toString(x) + "=" + value); namevalues.put(name + Integer.toString(x), value); x++; //end else { if (line.startswith("userdetails.attribute.name=")) { String name = line.replacefirst( "userdetails.att ribute.name=", ""); line = br.readline(); if (line.startswith("userdetails.attribute.value=")) { line.replacefirst( String value = Marco Alfano 566/2817 Pagina 84 di 113

85 ls.attribute.value=", ""); value); ame + "=" + value); "userdetai namevalues.put(name, //System.out.println(n else if (_log.isdebugenabled()) { _log.debug("attributes response code " + responsecode); catch (MalformedURLException mfue) { _log.error(mfue.getmessage()); if (_log.isdebugenabled()) { _log.debug(mfue, mfue); catch (IOException ioe) { _log.error(ioe.getmessage()); if (_log.isdebugenabled()) { _log.debug(ioe, ioe); return namevalues; private String[] _getcookienames(string serviceurl) { String[] cookienames = _cookienamesmap.get(serviceurl); if (cookienames!= null) { return cookienames; List<String> cookienameslist = new ArrayList<String>(); try { String cookiename = null; String url = serviceurl + _GET_COOKIE_NAME; URL urlobj = new URL(url); HttpURLConnection urlc = (HttpURLConnection)urlObj.openConnection(); BufferedReader br = new BufferedReader( new Marco Alfano 566/2817 Pagina 85 di 113

86 InputStreamReader((InputStream)urlc.getContent())); int responsecode = urlc.getresponsecode(); responsecode); ""); if (responsecode!= HttpURLConnection.HTTP_OK) { if (_log.isdebugenabled()) { _log.debug(url + " has response code " + else { String line = null; while ((line = br.readline())!= null) { if (line.startswith("string=")) { line = line.replacefirst("string=", cookiename = line; url = serviceurl + _GET_COOKIE_NAMES; urlobj = new URL(url); urlc = (HttpURLConnection)urlObj.openConnection(); br = new BufferedReader( new InputStreamReader((InputStream)urlc.getContent())); { responsecode); ""); if (urlc.getresponsecode()!= HttpURLConnection.HTTP_OK) if (_log.isdebugenabled()) { _log.debug(url + " has response code " + else { String line = null; while ((line = br.readline())!= null) { if (line.startswith("string=")) { line = line.replacefirst("string=", cookiename); if (cookiename.equals(line)) { cookienameslist.add(0, else { cookienameslist.add(line); Marco Alfano 566/2817 Pagina 86 di 113

87 catch (IOException ioe) { if (_log.iswarnenabled()) { _log.warn(ioe, ioe); cookienames = cookienameslist.toarray( new String[cookieNamesList.size()]); _cookienamesmap.put(serviceurl, cookienames); return cookienames; private String _getsubjectid( HttpServletRequest request, String serviceurl) { String cookiename = _getcookienames(serviceurl)[0]; return CookieUtil.get(request, cookiename); private boolean _isauthenticated( HttpServletRequest request, String serviceurl) throws IOException { boolean authenticated = false; String url = serviceurl + _VALIDATE_TOKEN; URL urlobj = new URL(url); HttpURLConnection urlc = (HttpURLConnection)urlObj.openConnection(); urlc.setdooutput(true); urlc.setrequestmethod("post"); urlc.setrequestproperty( "Content-type", "application/x-www-form-urlencoded"); String[] cookienames = _getcookienames(serviceurl); _setcookieproperty(request, urlc, cookienames); OutputStreamWriter osw = new OutputStreamWriter(urlc.getOutputStream()); osw.write("dummy"); osw.flush(); int responsecode = urlc.getresponsecode(); if (responsecode == HttpURLConnection.HTTP_OK) { Marco Alfano 566/2817 Pagina 87 di 113

88 String data = StringUtil.read(urlc.getInputStream()); if (data.tolowercase().indexof("boolean=true")!= -1) { authenticated = true; else if (_log.isdebugenabled()) { _log.debug("authentication response code " + responsecode); return authenticated; private static void _setcookieproperty( HttpServletRequest request, HttpURLConnection urlc, String[] cookienames) { StringBuilder sb = new StringBuilder(); for (String cookiename : cookienames) { String cookievalue = CookieUtil.get(request, cookiename); sb.append(cookiename); sb.append(stringpool.equal); sb.append(cookievalue); sb.append(stringpool.semicolon); if (sb.length() > 0) { urlc.setrequestproperty("cookie", sb.tostring()); private static final String _GET_ATTRIBUTES = "/identity/attributes"; private static final String _GET_COOKIE_NAME = "/identity/getcookienamefortoken"; private static final String _GET_COOKIE_NAMES = "/identity/getcookienamestoforward"; private static final String _VALIDATE_TOKEN = "/identity/istokenvalid"; private static Log _log = LogFactoryUtil.getLog(OpenSSOUtil.class); private static OpenSSOUtil _instance = new OpenSSOUtil(); private static Map<String, String[]> _cookienamesmap = new ConcurrentHashMap<String, String[]>(); Marco Alfano 566/2817 Pagina 88 di 113

89 ################## PropsKeys ################## /** * Copyright (c) Liferay, Inc. All rights reserved. * * Permission is hereby granted, free of charge, to any person obtaining a copy * of this software and associated documentation files (the "Software"), to deal * in the Software without restriction, including without limitation the rights * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell * copies of the Software, and to permit persons to whom the Software is * furnished to do so, subject to the following conditions: * * The above copyright notice and this permission notice shall be included in * all copies or substantial portions of the Software. * * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE * SOFTWARE. */ package com.liferay.portal.util; /** * <a href="propskeys.java.html"><b><i>view Source</i></b></a> * Brian Wing Shun Chan * */ public interface PropsKeys { public static final String ADMIN_DEFAULT_GROUP_NAMES = "admin.default.group.names"; public static final String ADMIN_DEFAULT_ROLE_NAMES = "admin.default.role.names"; public static final String ADMIN_DEFAULT_USER_GROUP_NAMES = "admin.default.user.group.names"; public static final String ADMIN_ _FROM_ADDRESS = "admin. .from.address"; Marco Alfano 566/2817 Pagina 89 di 113

90 public static final String NTLM_AUTH_ENABLED = "ntlm.auth.enabled"; public static final String NTLM_DOMAIN = "ntlm.auth.domain"; public static final String NTLM_DOMAIN_CONTROLLER = "ntlm.auth.domain.controller"; public static final String OMNIADMIN_USERS = "omniadmin.users"; public static final String OPEN_ID_AUTH_ENABLED = "open.id.auth.enabled"; public static final String OPEN_SSO_AUTH_ENABLED = "open.sso.auth.enabled"; public static final String OPEN_SSO_AUTO_CREATE_GROUP = "open.sso.auto.create.group"; public static final String OPEN_SSO_AUTO_CREATE_ROLE = "open.sso.auto.create.role"; public static final String OPEN_SSO_CONVERT_GROUP_TO_GROUP = "open.sso.convert.group"; public static final String OPEN_SSO_CONVERT_GROUP_TO_ROLE = "open.sso.convert.role"; public static final String OPEN_SSO_ _ADDRESS_ATTR = "open.sso. .address.attr"; public static final String OPEN_SSO_FIRST_NAME_ATTR = "open.sso.first.name.attr"; public static final String OPEN_SSO_LAST_NAME_ATTR = "open.sso.last.name.attr"; public static final String OPEN_SSO_LOGIN_URL = "open.sso.login.url"; public static final String OPEN_SSO_LOGOUT_URL = "open.sso.logout.url"; public static final String OPEN_SSO_SCREEN_NAME_ATTR = "open.sso.screen.name.attr"; public static final String OPEN_SSO_SERVICE_URL = "open.sso.service.url"; public static final String OPENOFFICE_CACHE_ENABLED = "openoffice.cache.enabled"; public static final String OPENOFFICE_SERVER_ENABLED = Marco Alfano 566/2817 Pagina 90 di 113

91 "openoffice.server.enabled"; public static final String WIKI_RSS_ABSTRACT_LENGTH = "wiki.rss.abstract.length"; public static final String YM_LOGIN = "ym.login"; public static final String YM_PASSWORD = "ym.password"; ################## PropsValues ################## /** * Copyright (c) Liferay, Inc. All rights reserved. * * Permission is hereby granted, free of charge, to any person obtaining a copy * of this software and associated documentation files (the "Software"), to deal * in the Software without restriction, including without limitation the rights * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell * copies of the Software, and to permit persons to whom the Software is * furnished to do so, subject to the following conditions: * * The above copyright notice and this permission notice shall be included in * all copies or substantial portions of the Software. * * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE * SOFTWARE. */ package com.liferay.portal.util; import com.liferay.portal.kernel.util.getterutil; import com.liferay.portal.kernel.util.stringpool; import com.liferay.portal.kernel.util.stringutil; Marco Alfano 566/2817 Pagina 91 di 113

92 /** * <a href="propsvalues.java.html"><b><i>view Source</i></b></a> * Brian Wing Shun Chan * */ public class PropsValues { public static final String[] ADMIN_DEFAULT_GROUP_NAMES = StringUtil.split( PropsUtil.get(PropsKeys.ADMIN_DEFAULT_GROUP_NAMES), StringPool.NEW_LINE); public static final boolean OPEN_ID_AUTH_ENABLED = GetterUtil.getBoolean( PropsUtil.get(PropsKeys.OPEN_ID_AUTH_ENABLED)); public static final boolean OPEN_SSO_AUTH_ENABLED = GetterUtil.getBoolean( PropsUtil.get(PropsKeys.OPEN_SSO_AUTH_ENABLED)); public static final boolean OPEN_SSO_AUTO_CREATE_GROUP = GetterUtil.getBoolean( PropsUtil.get(PropsKeys.OPEN_SSO_AUTO_CREATE_GROUP)); public static final boolean OPEN_SSO_AUTO_CREATE_ROLE = GetterUtil.getBoolean( PropsUtil.get(PropsKeys.OPEN_SSO_AUTO_CREATE_ROLE)); public static final boolean OPEN_SSO_CONVERT_GROUP_TO_GROUP = GetterUtil.getBoolean( PropsUtil.get(PropsKeys.OPEN_SSO_CONVERT_GROUP_TO_GROUP)); public static final boolean OPEN_SSO_CONVERT_GROUP_TO_ROLE = GetterUtil.getBoolean( PropsUtil.get(PropsKeys.OPEN_SSO_CONVERT_GROUP_TO_ROLE)); public static final String OPEN_SSO_ _ADDRESS_ATTR = PropsUtil.get(PropsKeys.OPEN_SSO_ _ADDRESS_ATTR); public static final String OPEN_SSO_FIRST_NAME_ATTR = PropsUtil.get(PropsKeys.OPEN_SSO_FIRST_NAME_ATTR); public static final String OPEN_SSO_LAST_NAME_ATTR = PropsUtil.get(PropsKeys.OPEN_SSO_LAST_NAME_ATTR); public static final String OPEN_SSO_LOGIN_URL = PropsUtil.get(PropsKeys.OPEN_SSO_LOGIN_URL); public static final String OPEN_SSO_LOGOUT_URL = Marco Alfano 566/2817 Pagina 92 di 113

93 PropsUtil.get(PropsKeys.OPEN_SSO_LOGOUT_URL); public static final String OPEN_SSO_SCREEN_NAME_ATTR = PropsUtil.get(PropsKeys.OPEN_SSO_SCREEN_NAME_ATTR); public static final String OPEN_SSO_SERVICE_URL = PropsUtil.get(PropsKeys.OPEN_SSO_SERVICE_URL); public static final boolean OPENOFFICE_CACHE_ENABLED = GetterUtil.getBoolean( PropsUtil.get(PropsKeys.OPENOFFICE_CACHE_ENABLED)); public static final String WIKI_PAGE_TITLES_REMOVE_REGEXP = PropsUtil.get( PropsKeys.WIKI_PAGE_TITLES_REMOVE_REGEXP); static { if (!LAYOUT_USER_PRIVATE_LAYOUTS_ENABLED) { LAYOUT_USER_PRIVATE_LAYOUTS_AUTO_CREATE = false; LAYOUT_USER_PRIVATE_LAYOUTS_MODIFIABLE = false; if (!LAYOUT_USER_PUBLIC_LAYOUTS_ENABLED) { LAYOUT_USER_PUBLIC_LAYOUTS_AUTO_CREATE = false; LAYOUT_USER_PUBLIC_LAYOUTS_MODIFIABLE = false; Marco Alfano 566/2817 Pagina 93 di 113

94 APPENDICE C: Procedure Installazione Sistema Procedura Installazione Java Development Kit Scaricare il JDK 1.6.0_18 dal sito nella seguente directory /usr/local/, se il file scaricato non è eseguibile dare il comando chmod +x nome_file ed eseguire l'installazione con il comando./nome_file. A questo punto verrà creata la directory jdk1.6.0_18 contenente il JDK. Procedura di Installazione OpenSSO Scaricare Apache Tomcat versione dal sito decomprimere il file appena scaricato in /usr/local/tomcat/ utilizzando il comando tar -zxvf./apache-tomcat tar.gz. Aggiungere in /usr/local/tomcat/bin/catalina.sh la variabile d'ambiente JAVA_HOME contentente il path completo del JDK installato precedentemente: JAVA_HOME=/usr/local/jdk1.6.0_18. Se OpenSSO e Liferay si trovano sulla stessa macchina, o se è già presente un tomcat in ascolto sulla porta TCP 8080, bisogna modificare il file /usr/local/tomcat/conf/server.xml : <Server port="8005" shutdown="shutdown"> to <Server port="8006" shutdown="shutdown"> <Connector port="8080" protocol="http/1.1" connectiontimeout="20000" redirectport="8443" /> to <Connector port="8090" protocol="http/1.1" connectiontimeout="20000" redirectport="9443" /> <Connector port="8009" protocol="ajp/1.3" redirectport="8443" /> to <Connector port="8010" protocol="ajp/1.3" redirectport="9443" /> In questo modo Tomcat sarà in ascolto sulla porta TCP Ci sono alcune premesse da fare prima di installare OpenSSO: Marco Alfano 566/2817 Pagina 94 di 113

95 La configurazione di OpenSSO fallisce se il server è impostato su una lingua diversa dall'inglese. La configurazione di OpenSSO fallisce se non è stato agginto "-Xmx1G" in catalina.sh: JAVA_OPTS="$JAVA_OPTS -Xmx1G La configurazione di OpenSSO DEVE essere eseguita richiamando la pagina di configurazione da un browser utilizzando il nome completo del server. A questo punto, avviare tomcat richiamando lo script di avvio: /usr/local/tomcat/bin/startup.sh. Verificato il funzionamento di Tomcat in un browser, è possibile eliminare le applicazioni presenti nell'installazione di default, arrestando Tomcat con lo script: /usr/local/tomcat/bin/shutdown.sh ed eliminando tutto il contenuto della directory: /usr/local/tomcat/webapps/. A questo punto, scaricare opensso express versione 8 nel formato war dal sito e copiare il war scaricato in /usr/local/tomcat/webapps/ ; a questo punto avviare tomcat ed attendere il deploy automatico del war. Verificare il funzionamento di OpenSSO da un browser, andando all'indirizzo se appare il wizard per la prima configurazione, OpenSSO è installato correttamente. A questo punto è possibile procedere alla prima configurazione di OpenSSO. OpenSSO offre due modalità di configurazione utilizzando un Wizard di defaul, o uno personalizzato; con quello personalizzato è possibile specificare, già in questa fase, i parametri per il datastore utenti esterno, anche se in seguito devono comunque essere specificati altri parametri. Per i dettagli, si rimanda alla procedura di configurazione di OpenSSO. Marco Alfano 566/2817 Pagina 95 di 113

96 Inoltre, per configurare successivamente l'autenticazione mediante certificati X.509, bisogna inserire nel file server.xml la seguente configurazione: <Connector port="8001" maxthreads="150" strategy="ms" maxhttpheadersize="8192" emptysessionpath="true" protocol="http/1.1" SSLEnabled="true" scheme="https" secure="true" clientauth="want" keystorefile="/usr/local/tomcat/conf/server.ks" keystorepass="tomcat2009" sslprotocol="tls" keystoretype="jks" truststorefile="/usr/local/tomcat/conf/server.ks" truststorepass="tomcat2009" truststoretype="jks" URIEncoding="UTF-8" /> Per la creazione del file server.ks, si rimanda alla procedura di creazione dei certificati di test. Procedura di Installazione Liferay Scaricare dal sito il file liferay-portal-tomcat zip contenente Liferay e Apache Tomcat Decomprimere il file appena scaricato in /usr/local/liferay/ utilizzando il comando unzip. Rimuovere le directory "sevencogs-hook" e "sevencogs-theme" da /usr/local/liferay/tomcat /webapps, contenenti le comunity demo, prima del primo avvio di Liferay Aggiungere in /usr/local/liferay/tomcat /bin/catalina.sh la variabile d'ambiente JAVA_HOME contentente il path completo del JDK installato precedentemente: JAVA_HOME=/usr/local/jdk1.6.0_18. Arrivati a questo punto, si può fare una prova del corretto funzionamento di Liferay avviando lo script: /usr/local/liferay/tomcat /bin/startup.sh Marco Alfano 566/2817 Pagina 96 di 113

97 Si aprirà automaticamente il browser predefinito di sistema non appena il server tomcat si sarà avviato completamente. Eliminando le community di demo, l'utente predefinito aventi credenziali di Amministratore è: password=test. Adesso è possibile proseguire con la parte restante della configurazione che permette di preparare l'ambiente per la successiva integrazione con OpenSSO. Arrestare Liferay richiamando lo script: /usr/local/liferay/tomcat /bin/shutdown.sh ; controllare per sicurezza che tomcat si sia realmente arrestato con il comando ps -aef grep tomcat e nel caso fosse ancora in avviato, eseguire: kill -9 tomcat_pid, sostituiendo tomcat_pid con il pid del tomcat ancora in memoria per killare il processo. Per abilitare la pagina per l'utente guest con OpenSSO attivato commentare in /usr/local/liferay/tomcat /webapps/root/web-inf/web.xml : <!-- <filter-mapping> <filter-name>sso Open SSO Filter</filter-name> <url-pattern>/web/*</url-pattern> </filter-mapping> --> Aggiungere al file /usr/local/liferay/tomcat /webapps/root/web- INF/classes/portal-ext.properties, se non esiste ancora crearlo con il comando touch portal-ext.properties, le seguenti impostazioni: Marco Alfano 566/2817 Pagina 97 di 113

98 #Nasconde le portlet che non sono abilitate per l'utente corrente layout.show.portlet.access.denied=false #Imposta la pagina alla quale fare il redirect subito dopo il login #Questa direttiva è commentata perchè opzionale #default.landing.page.path=/web/20/1 #Disabilita la domanda per il recupero della password #Poichè le password saranno gestite da OpenSSO e non da Liferay, questa evita l'operazione superflua di specificare una domanda per il recupero della password. users.reminder.queries.enabled=false #Abilita la conversione da gruppi di OpenSSO a ruoli di Liferay open.sso.convert.role=true #Abilita la conversione da gruppi di OpenSSO a gruppi di Liferay open.sso.convert.group=false #Abilita la creazione automatica dei ruoli non presenti su Liferay open.sso.auto.create.role=true #Abilita la creazione automatica dei gruppi non presenti su Liferay open.sso.auto.create.group=false Adesso, prima di avviare Liferay, bisogna sostituire le classi modificate nel relativo package: scompattare il file update_opensso_agent.zip in /usr/local/liferay/tomcat /webapps/root/web-inf/lib/ e lanciare lo script di aggiornamento update.sh. Per permettere l'utilizzo di una connessione protetta tra Liferay ed OpenSSO, bisogna creare un truststore contenente il certificato della CA firmataria del Marco Alfano 566/2817 Pagina 98 di 113

99 certificato del server OpenSSO; per questa procedura si rimanda alla procedura di creazione dei certificati. I passaggi preliminari a questo punto sono completi, avviare Tomcat e verificare il corretto funzionamento di Liferay. Procedura configurazione Integrazione Liferay-OpenSSO Come detto precedentemente, Liferay offre un pannello di controllo basato sul web che permette l'impostazione delle informazioni necessarie all'utilizzo di OpenSSO. Autenticarsi con l'utente amministratore di Liferay test@liferay.com; andare nel pannello di controllo, selezionare il link setting nella sezione portal; successivamente selezionare authentication, a qusto punto verrà mostrata una schermata con tutti i sistemi di autenticazione configurabili, da questa selezionare OpenSSO; verrà visualizzata la seguente schermata di configurazione: Marco Alfano 566/2817 Pagina 99 di 113

100 Da questa, bisogna abilitare l'agent OpenSSO spuntando la voce enable; poi configurare correttamente i seguenti parametri: Login Url: Questo parametro indica a quale url Liferay deve ridirigere l'utente al momento dell'autenticazione: la stringa?goto= è un parametro che indica ad OpenSSO l'url al quale ridirigere l'utente una volta che l'autenticazione è avvenuta con successo; il redirect viene effettuato a c/portal/login di Liferay per permettere a quest'ultimo di svolgere le procedure di autenticazione mediante il sistema abilitato. Marco Alfano 566/2817 Pagina 100 di 113

101 Logout Url: per questo parametro vale quanto detto per il parametro precedente, tranne che per i redirect che vengono effettuati al momento del logout e non al login; l'url ha questo formato goto= in grassetto la variante rispetto al Login; il redirect a web/guest/home reindirizza l'utente alla pagina guest, dato che ha effettuato il logout. Service Url: indica a Liferay l'url al quale è presente il server OpenSSO, questo è utilizzato per altre richieste al server OpenSSO, ad esempio per richiedere i parametri relativi all'utente ( il parametro ha il seguente formato: Screen Name Attribute: specifica il nome dell'attributo contente il nome dell'utente utilizzato da OpenSSO; Liferay utilizza questo valore per mostrare il nominativo dell'utente connesso; nel caso specifico, OpenSSO utilizza come attributo UID. Address Attribute: specifica il nome dell'attributo contente l'indirizzo dell'utente utilizzato da OpenSSO; nel caso specifico, OpenSSO utilizza come attributo mail. First Name Attribute: specifica il nome dell'attributo contente il nome dell'utente utilizzato da OpenSSO; nel caso specifico, OpenSSO utilizza come attributo givenname. Last Name Attribute: specifica il nome dell'attributo contente il cognome dell'utente utilizzato da OpenSSO; nel caso specifico, OpenSSO utilizza come attributo sn. A questo punto la configurazione di Liferay è conclusa e l'integrazione tra Marco Alfano 566/2817 Pagina 101 di 113

102 OpenSSO e Liferay si può ritenere conclusa. Avviare Liferay e verificare il funzionamento della procedura di Login e della corretta gestione dei gruppi utente. Nota: per utilizzare l'autenticazione tramite certificati X.509, bisogna prima configurare le restanti parti in OpenSSO ed eseguire tutti i passi riguardanti la procedura di generazione dei certificati; e solo dopo modificare gli Url configurati per l'utilizzo del protocollo HTTPS: Login Url: Logout Url: Service Url: Procedura Configurazione OpenSSO Accedere come utente amministratore amadmin al pannello di gestione di OpenSSO, andare in Configuration Servers and Sites Defaul Server Settings Security, spuntare la voce Encode Cookie Value e salvare i cambiamenti; andare in access control /(Top Level Realm) data stores, si aprirà la schermata per la gestione dei data stores utenti. Selezionando il bottone New, si aprirà la seguente schermata: Marco Alfano 566/2817 Pagina 102 di 113

103 Illustrazione 19: Nuovo Data Store Step 1 Dall'illustrazione è evidente la possibilità di selezionare diverse tipologie di database; inoltre è possibile specificare l'utilizzo di un database generico basato su Ldap v3. Per OpenLdap, andremo a selezionare quest'ultimo, ed imposteremo un nome identificativo. Nella schermata successiva, si andranno a selezionare tutti parametri e le impostazioni per l'utilizzo del nuovo Ldap. Illustrazione 20: Nuovo Data Store Step 2 Segue una descrizione dei parametri che bisogna impostare per l'attuale integrazione: Ldap Server: è l'indirizzo del server Ldap con la porta utilizzata. Ldap Bind DN: è il DN dell'utente utilizzato per l'accesso al server Ldap. Ldap Bind Password: è la password dell'utente specificato in Bind DN. Marco Alfano 566/2817 Pagina 103 di 113

104 LDAP Organization DN: imposta da quale livello Ldap iniziare la ricerca; nel nostro caso: dc=unina,dc=it. LDAPv3 Plug-in Search Scope: indica lo Scope della ricerca, cioè fino a che livello bisogna arrivare nella ricerca; nel nostro caso verrà selezionato Scope_SUB, che permette ad OpenSSO di percorrere tutto l'albero Ldap a partire dal Organization DN impostato. LDAP Users Search Attribute: è l'attributo che indentifica in modo univoco un utente, come indirizzo , uid, etc.. nel nostro caso è stato selezionato l'attributo uid. LDAP Users Search Filter: è il filtro utilizzato per la ricerca degli utenti; in questo caso è stato lasciato il filtro di default: (objectclass=inetorgperson), che permette di filtrare solo gli oggetti in base all'objectclass. Attribute Name of User Status: è il nome dell'attributo contente lo status di un utente; nel nostro caso, per quanto detto all'inizio del paragrafo, è stato scelto gecos. LDAP Groups Search Filter: è il filtro utilizzato per la ricerca dei gruppi; in questo caso è stato lasciato il filtro di default: (objectclass=groupofuniquenames), che permette di filtrare solo gli oggetti corrispondenti a gruppi. Attribute Name for Group Membership: è l'attributo che identifica il gruppo di appartenenza di un utente; nel nostro caso è stato scelto pager. Authentication Naming Attribute: è l'attributo che verrà utilizzato come nome utente al momento del login, e deve essere uguale a quello specificato in LDAP Users Search Attribute. A questo punto la configurazione del Data Store è stata completata e gli utenti presenti nel database possono autenticarsi con le proprie credenziali. Marco Alfano 566/2817 Pagina 104 di 113

105 Se si vuole abilitare l'autenticazione mediante certificati X.509, bisogna eseguire anche questa configurazione: andare in access control /(Top Level Realm) Authentication, e creare un nuovo Modulo Instances Illustrazione 21: Nuovo Modulo Configurare il modulo appena creato impostando il parametro prelevato dal certificato che verrà utilizzato per la ricerca dell'utente sul datastore configurato; nel nostro caso l'uid: Certificate Field Used to Access User Profile: subject UID Si fa notare che il campo scelto deve essere uguale a quello selezionato nel datastore per la voce LDAP Users Search Attribute. Creare un nuovo Authentication Chaining con i seguenti parametri: Illustrazione 22: Nuova Authentication Chaining Fare attenzione all'ordine di inserimento, deve essere come mostrato in figura. Marco Alfano 566/2817 Pagina 105 di 113