Problematiche relative all'introduzione di un sistema di Identity and Access Management federato in una Università.

Università degli Studi di Parma

Facoltà di Scienze Matematiche Fisiche e Naturali

Tesi di Laurea in Reti di Calcolatori

Problematiche relative

all'introduzione di un sistema di

Identity and Access Management

federato in una Università.

Candidato:

Relatore:

Alberto Gioia

Chiar.mo Prof. Roberto Aleri

Dott. Ing. Marco Panella

.

A mio padre e a mia madre genitori insostituibili ed unici. Ad Anna Maria e Maria Chiara così lontane ma sempre vicine nel cuore. A Marina, che mi è stata sempre vicina.

Indice

Introduzione 7

1 Progetto IDEM 14

1.1 L'IDEntity Management . . . 14

1.1.1 Come avvicinarsi all'Identity Management . . . 15

1.1.2 Denizione di identità digitale . . . 20

1.1.3 Tassonomia dell'IDEntity Management . . . 20

1.2 Esempi progetti IDEM . . . 22

1.2.1 Banca Popolare di Sondrio . . . 22

2 Standards e tecnologie di rilievo 23 2.1 Standards sul formato e lo scambio di credenziali . . . 23

2.1.1 SAML . . . 24

2.1.2 X.509 . . . 24

2.2 SSO (Single Sign On) . . . 26

2.2.1 SSO su web . . . 26

2.2.2 Shibboleth . . . 28

2.3 CAS - Central Authentication Service . . . 36

2.3.1 Introduzione . . . 36

2.3.2 Funzionamento . . . 36

2.3.3 Schema . . . 38

2.3.4 Proxy . . . 38

2.3.5 Funzionamento . . . 40

2.4 AAA (Authentication Authorization Accounting) . . . 42

Indice 4

2.4.2 Authorization . . . 42

2.4.3 Accounting . . . 43

3 Installazione Shibboleth Service Provider 44 3.1 Introduzione . . . 44

3.2 Prerequisiti . . . 45

3.3 Installazione di Shibboleth SP 1.3 . . . 45

3.3.1 Utilizzo dei pacchetti debian . . . 45

3.3.2 Compilazione da sorgente . . . 46

3.3.3 Compilatore Debian C/C++ e Tool Building . . . 47

3.3.4 Installazione della libreria OpenSSL . . . 47

3.3.5 Installazione della libreria libcurl . . . 48

3.3.6 Compilazione e installazione della libreria log4cpp . . . 48

3.3.7 Compilazione e installazione di Xerces-C++ . . . 49

3.3.8 Compilazione e installazione di XML-Security C++ . . 50

3.3.9 Compilazione e installazione di OpenSAML . . . 51

3.3.10 Compilazione e installazione di Shibboleth SP 1.3 . . . 51

3.3.11 Certicati SSL . . . 53

3.3.12 Congurazione iniziale di Shibboleth SP 1.3 . . . 54

3.4 Installazione tramite sorgente . . . 65

3.4.1 Log4cpp . . . 65 3.4.2 Xerces-C . . . 65 3.4.3 Xml-Xalan . . . 66 3.4.4 Xml-Security-C . . . 66 3.4.5 CxxTest . . . 68 3.4.6 OpenSAML . . . 68 3.4.7 APR 0.9.13 . . . 68 3.4.8 APR-Util 0.9.13 . . . 69 3.4.9 Shibboleth-SP . . . 69

4 Installazione Shibboleth Identity Provider 71 4.1 Prerequisiti . . . 71

4.2 Installazione . . . 72

4.2.2 Tool ant di congurazione Apache . . . 72

4.2.3 Piattaforma Java 2, Standard Edition (J2SE) . . . 73

4.2.4 Container Tomcat 5.5 JSP/Servlt . . . 74

4.2.5 Registrazione dei log con log4j . . . 75

4.2.6 Shibboleth IdP 1.3 e Java CAS Client . . . 76

4.3 Congurazione . . . 78

4.3.1 Congurazione Shibboleth IdP 1.3 . . . 78

4.3.2 SSL . . . 78

4.3.3 Congurazione di Tomcat 5.5 . . . 80

5 Modiche degli script 82 5.1 Script per l'inserimento di nuovi studenti . . . 82

5.2 Script per l'aggiornamento degli attributi . . . 85

Conclusioni 87 Bibliograa 89 A Il GARR 95 A.1 Il GARR . . . 95

A.1.1 Storia del GARR . . . 95

A.1.2 La missione . . . 96

A.1.3 La comunità del GARR . . . 97

B File completo shibboleth.xml 98

C Script di avvio Tomcat 5.5 106

D Proprietà di log4j 109

E File di congurazione IdP: dist.idp.xml 113

F File completo idp.xml 116

G File completo resolver.xml 121

Elenco delle gure

2.1 Dierenza tra autenticazione web locale e autenticazione web

centralizzata . . . 28

2.2 Diagramma temporale delle interazioni per il SSO e lo scambio di attributi usando Shibboleth . . . 30

2.3 Componenti di un tipico IdP. . . 32

2.4 Componenti di un tipico SP. . . 33

2.5 Esempio di autenticazione con il CAS e senza il CAS . . . 36

2.6 Schema di funzionamento semplice . . . 37

2.7 Schema di funzionamento del CAS-proxy . . . 38

2.8 Schema di funzionamento dettagliato . . . 39

2.9 Schema di funzionamento CAS-proxy . . . 41

5.1 Intervalli temporali di implementazione, osservati e stimati, dei principali stadard di Identity Management. . . 88

Introduzione

L'obbiettivo di questa tesi è quello di trovare una soluzione alle proble-matiche relative alla gestione delle identità digitali degli utenti, nell'ambito di una federazione GARR.

La proliferazione di servizi web con specici sistemi di registrazione co-stringe l'utente a fornire dati personali in diversi siti e spesso ad utilizzare credenziali di accesso dierenti. Inoltre le entità digitali che l'utente deve uti-lizzare sono spesso soggette a regole di sicurezza e riservatezza diverse, su cui l'utente ha poco controllo. Questa situazione rende dicile e insicuro l'acces-so a servizi online forniti da l'acces-soggetti diversi della propria organizzazione di appartenenza.

Il primo tentativo di fornire una denizione completa del concetto di identità digitale è stato fatto da Hal Abelson e Lawrance Lessing del MIT nel white paper Digitale in Cyperspace:

L'insieme delle caratteristiche essenziali e uniche di un soggetto sono ciò che è in grado di identicarlo

Dietro questa semplice denizione si nasconde in realtà una grande com-plessità che è legata alla denizione di quelle che sono le sue caratteristiche uniche ed essenziali.

Introduzione 8 La gestione dell'indetità digitale è un tema rilevante sia per chi la gestisce che per chi ne è titolare:

• chi gestisce un sistema di Identity Management lo fa per mantenere il controllo e garantire la sicurezza degli accessi

• chi possiede una identità digitale desidera tutela sulla privacy dei propri dati, desidera garanzie sul corretto uso, desidera sicurezza contro il furto della propria identità.

Storicamente il punto di vista corporate ha avuto maggiore rilevanza di quello dell'individuo. Le organizzazioni si sono abituate a gestire le identità digitali dei propri membri e a considerare l'intero tema dell'identità digitale come un fatto interno.

La situazione è cambiata a partire dal 2002: le organizzazioni hanno visto aumentare in modo prima non prevedibile le necessità di lasciare uscire ed entrare le identità digitali attraverso i conni del proprio dominio.

Una nuova situazione si è venuta disegnando soprattutto a causa di tre fattori:

• a seguito della dot-com-crush del 2000 si è manifestata una tenden-za alle acquisizioni e fusioni tra imprese che ha portato alla neces-sità operativa di unicare tra loro sistemi di Identity Management precedentemente separati.

• l'aumento del ricorso all'outsourcing1 e oshoring2 ha portato a supe-rare la divisione dell'identità come fatto interno ad una sola organiz-zazione.

• più precisamente, l'emergere del cosidetto Web 2.0 ha messo a dispo-sizione un gran numero di nuovi servizi rivolti alle persone riconosciute individualemente grazie alla loro identità digitale.

1_{L'outsourcing: si riferisce genericamente alle pratiche adottate dalle imprese di}

ester-nalizzare alcune fasi del processo produttivo, cioè ricorrere ad altre imprese per il loro svolgimento.

2_{L'oshoring consiste nel trasferimento all'estero di una funzione aziendale, senza che}

La identità digitale federata è il nuovo paradigma che nasce dall'ac-cettazione di questi fatti:

• le persone si spostano attraverso i conni di diversi ambiti di respon-sabilità in modo sempre più frequente e continuerà ad essere così in futuro;

• non è proponibile che si possa giungere ad una identità digitale uni-cata, in qualunque ambito che non possa essere identicato con un solo dominio di responsabilità.

L'esigenza di una soluzione di Identity Management viene percepita da almeno tre punti di vista:

• il primo è quello di riuscire ad avere una visione omogenea e coerente dell'intero sistema di sicurezza dal punto di vista relazione tra individui e risorse alle quali consentire l'accesso.

• il secondo è quello di migliorare la qualità del servizio erogato agli utenti, semplicandone la navigazione attraverso le varie applicazioni alle quali avevano diritto di accedere.

• il terzo è strettamente correlato all'economia di gestione del sistema: si tratta di trovare una soluzione che assicuri prestazioni e che riduca i gradi di complessità e i punti di intervento per l'amministrazione dei privilegi, evitanto di dover intervenire di volta in volta sulle singole applicazioni e sui vari componenti del sistema.

GARR, come hanno già fatto enti omologhi (quali Haka in Finlandia, Re-dIRIS in Spagna, CRU in Francia, ecc...) intende favorire e supportare l'atti-vazione di una Federazione dei sistemi di autenticazione degli enti di ricerca, basata su rapporti di reciproca ducia, all'interno della quale sia accettata la validazione dell'utente eettuata dall'organizzazione di appartenenza.

Un processo analogo, dal punto di vista logico, a quanto accade per i cittadini dei paesi membri della comunità europea che accettano la carta di identità del paese di riferimento.

Nell'ambito dell'infrastruttura di identità federata i fornitori di servizi e le organizzazione di appartenenza degli utenti possono scambiare informazioni

Introduzione 10 sull'identità degli utenti in modo sicuro, coerente e rispettoso dei diritti di riservatezza e ciò consente:

- all'utente nale di utilizzare le credenziali fornite dal proprio ente di appartenenza per l'accesso ai servizi convenzionali con la Federazione e di essere informato sui dati comunicati al fornitore di servizi in quanto necessari per l'autorizzazione e/o personalizzazione;

- all'organizzazione di appartenenza dell'utente di mantenere il controllo sul processo di autenticazione e sull'accesso ai servizi remoti da parte dei propri utenti;

- al fornitore di servizi di evitare gli oneri di gestione delle credenziali personali e di disporre, per l'autorizzazione e la congurazione e/o per-sonalizzazione del servizio di informazioni (attributi) relative all'utente concordate con la Federazione e trasmesse a cura dell'organizzazione di appartenenza.

GARR ha individuato nell'architettura Shibboleth sviluppata da Inter-net2, la piattaforma tecnologica su cui basare la Federazione.

Il GARR fornisce alcuni servizi centrali; in particolare, per gli enti che aderiscono a IDEM, mette a disposizione:

- l'infrastruttura IT centrale (catalogo e Metadati dei servizi disponibili, server WAYF, elenco dei certicati delle CA valide);

- servizio di supporto tecnico per l'implementazione di un IdP e imple-mentazione di riferimento open source;

- Certication Authority e il servizio SCS(Service Certicate Server); - GARR-CERT, gestione di eventuali incidenti di sicurezza.

I servizi per i quali è stata pianicata l'abilitazione all'autenticazione federata, sono:

- NILDE (Network Inter-library Document Exchange), che permette alle biblioteche degli enti pubblici italiani di richiedere e di fornire documen-ti in maniera reciproca. il sistema è gesdocumen-tito dalla Biblioteca dell'Area di Ricerca di Bologna del CNR3_;

- Science Direct dell'editore Elsevier4

- Sistema di videoconferenza GARR.

Ulteriori servizi potranno essere resi disponibili, anche su iniziativa degli enti GARR interessati.

I fornitori dei servizi che parteciperanno a IDEM stipuleranno accordi mirati con GARR, impegnandosi a:

- adeguarsi agli standard tecnici richiesti;

- non comunicare a terzi alcun dato degli utenti di cui siano venuti in possesso tramite servizi della Federazione;

- limitare la richiesta di dati sugli utenti alle informazioni utili ai ni dell'erogazione del servizio;

- fornire ogni ragionevole collaborazione a GARR o a altri enti parte-cipanti qualora fossero necessari dati e/o approfondimenti su attività rilevate come insolite e su eventuali incidenti di sicurezza;

- mantenere traccia delle operazioni e fornire i dati utili al monitoraggio dell'andamento e alla valutazione della sperimentazione;

oltre, ovviamente, ad attenersi alle leggi in vigore per quanto riguarda il trattamento dei dati personali e la sicurezza informatica.

Università degli Studi di Parma ha aderito a IDEM che è il progetto pilota di autenticazione federata per gli Atenei e per gli enti di ricerca. Assieme all'Università degli Studi di Parma, hanno aderito come progetto pilota le seguenti Università:

• CNR(Consiglio Nazionale delle Ricerche) di Torino. • Università degli Studi di Modena e Reggio Emilia.

3_{http://nilde.bo.cnr.it/} 4_{http://sciencedirect.com/}

Introduzione 12 Partecipare al progetto pilota ha voluto dire:

• disponibilità nel fornire informazioni in merito al sistema di accredi-tamento e gestione degli utenti adottato, anche al ne di condivide-re esperienze e best pratice fra gli enti che aderiranno in futuro a tal progetto.

• realizzare ed attivare localmente un servizio di Identity Provider Shib-boleth, connesso al sistema di autenticazione dell'ente e all'infrastrut-tura centrale gestita dal GARR, secondo le speciche publicate sul sito http://idem.garr.it. Tramite tale IdP gli utenti locali potranno accede-re ai servizi che saranno accede-resi disponibili nell'abito del progetto pilota utilizzando credenziali reali.

Il contributo della tesi

Come accennato in apertura, questa tesi si è concentra sugli aspetti del-l'Identity Management. In particolare sono stati formalizzati gli standard e le tecnologie riguardanti le problematiche dell'Identity Management, a partire dall'analisi di un insieme di documenti di specica e progetti.

In base a tali requisiti è stata svolta un'attività di ricerca (capitolo 2) di soluzioni tecnologiche adatte, tutte conformi al paradigma dell'Open Source, le quali sono state successivamente integrate all'interno di una architettura comprensiva. Per dimostrare la valità dell'architettura progettata, inne, è stata realizzata (capitolo 3 e 4) un'installazione su di una macchina SuSE Linux 10.0 di un Service Provider e Identity Provider.

Le tematiche principali arontate nel lavoro di tesi sono state:

• Il Single Sign On (SSO) via web5: lo studio estensivo dei sistemi esitenti e delle possibilità di estendere le funzionalità, l'attitudine del modello federativo introdotto da questi sistemi.

• L'autorizzazione ed il controllo di accesso: separazione tra autenticazio-ne ed autorizzazioautenticazio-ne autenticazio-nelle problematiche di sicurezza avanzate, i modelli

5_{Esso consiste nella possibilità, per un utente, di accedere a servizi oerti da più siti}

di controllo di accesso distribuito (ovvero separazione tra controllo di accesso e decisione di autorizzazione).

• L'analisi di nuove potenzialità introdotte dall'uso della rma digitale. • L'utilizzo delle informazioni utilizzate per l'autorizzazione anche a

Capitolo 1

Progetto IDEM

In questo capitolo si densice l'IDEntity Management, il `contenitore te-matico' di questa tesi, e se ne inquadrano le possibili varianti all'interno di una semplice tassonomania.

1.1 L'IDEntity Management

IDEntity Management (IDEM) is an integrated system of business processes, policies and technologies that enable organizations to facilitate and control their

users access to critical online applications and resources - while protecting condential personal and business information from unauthorized users.1

L'IDEM è pertanto una vasta area tematica legata alla gestione dell'i-dentità digitale degli utenti, nel caso dell'e-Business, e dei cittadini nel caso dell'e-Government. Le principali problematiche aerenti all'IDEM sono:

• user provisioning, allocazione e revoca di privilegi, proli utente; • delega di funzioni amministrative o di privilegi e proli utente; • autenticazione;

• controllo di accesso ed autorizzazione;

• formato ed interoperabilità delle identià digitali; • Single Sign On(SSO);

• servizi di directory;

• gestione della privacy; • gestione del trust.

Inoltre, il termine IDEM viene spesso associato a sistemi informatici che integrano (anche parzialmente) al proprio interno le funzionalità appena elencate.

1.1.1 Come avvicinarsi all'Identity Management

La gestione delle identità digitali in azienda può essere un punto di forza ma troppo spesso diventa un punto di vulnerabilità. La dierenza sta nelle implementazioni.

La resistenza di una catena è quella del suo anello più debole. Nella cate-na della sicurezza informatica, l'anello più debole per la gran parte delle imprese sta nella gestione degli accessi e delle identità digitali.

Scenario ideale

Un'azienda dovrebbe avere in piedi un processo automatizzato per ga-rantire a ciascun suo utente l'accesso alle applicazioni di sua competenza, ma anche per eliminare immediatamente questo accesso non appena diventa inutile o dannoso, come ad esempio quando un dipendente lascia la società. Le identità digitali di tutti i dipendenti dovrebbero essere sincronizzate in tutti i sistemi e un'azienda dovrebbe avere le tecnologie necessarie a garantire l'identità dei fornitori, partner e altre realtà `terze' che comunque accedono ai sistemi interni.

Ma nella maggior parte dei casi la realtà è ben diversa da questo sce-nario. Accade sin troppo spesso che ex dipendenti possano accedere ancora alla rete aziendale, prima che l'IT2 _{manager riceva l'ordine uciale di}

can-cellarli dalla rete. E gli impiegati devono ricordare talmente tante password che alla ne si sentono autorizzati a sceglierne di troppo vulnerabili.

2_{L'IT, acronimo di Information Technology, indica l'uso della tecnologia nella gestione}

1.1.1.1 Come avvicinarsi all'Identity Management 16 Ecco quindi elencati quattro punti importanti che inuenzano qual-siasi approccio all'identity management.

Vendere l'approccio

Come spesso accade, il punto principale sta nell'evidenziare i beneci diretti e indiretti di un sistema di identity management.

Un CSO3 _{dovrebbe essere preparato a formare utenti interni ed esterni}

su cosa è l'identity management e perché è importante. Non è un tema sem-plice da comprendere per chi è fuori dall'IT, quindi non bisogna cedere alla tentazione di arontarlo dal punto di vista tecnico. Meglio lasciar perdere Single Sign On, smart card e quant'altro e cercare invece di spiegare cosa si vuole ottenere in termini più vicini al business, come si farebbe per qualsiasi altro progetto infrastrutturale.

Dopo aver capito di che si tratta, le controparti del responsabile della si-curezza tipicamente chiederanno perché l'identity management costa così tanto.

A questo punto è essenziale indicare i beneci indiretti di cui si diceva qualche riga fa: un sistema di identity management riduce i costi di gestione IT e dell'help desk, aumenta la sicurezza di tutta l'infrastruttura e anche la produttività degli utenti, che non perdono tempo a loggarsi in sistemi diversi con procedure dierenti.

Altro vantaggio importante, di questi tempi, è che un sistema di identity management aiuta a soddisfare le normative legate alla sicurezza aziendale, dalla Sarbanes-Oxley4 _{alla 196/03}5_.

3_{Il CSO - Consorzio Sviluppo Occupazione - è un'associazione senza ni di lucro, nata}

nel 1993, con lo scopo di promuovere iniziative che favoriscono l'ingresso dei laureati nel mondo del lavoro.

4_{Sarbanes-Oxley Act è una legge emanata nel luglio 2002 dal governo degli Stati Uniti}

d'America a seguito di diversi scandali contabili che hanno coinvolto importanti aziende americane.

Capire i processi

I problemi dell'identity management sono nei processi più che nelle tecnologie. Bisogna seguire e analizzare passo per passo i processi e le re-gole legati alla creazione delle identità digitali e ai diversi accessi alle risorse di rete, prima di convertire questi processi in codice e in procedure auto-matizzate. Va capito, tra l'altro, chi può creare, modicare e visualizzare i dati degli utenti; quale particolare evento dà il via libera alla creazione di un nuovo prolo di privilegi per un nuovo utente o per un utente che cambia ruolo all'interno dell'impresa; quale, all'opposto, richiede una cancellazione immediata dei privilegi. Si tratta in pratica di `seguire la logica' che sta dietro certe procedure aziendali, capire il perché certe cose sono fatte in un determinato modo.

In questa attività è meglio creare un team che non comprenda solo parte dello sta IT ma anche esponenti della gestione del personale e dei servizi nanziari.

Pronti a personalizzare

Bisogna essere preparati alla necessità di apportare personalizzazioni ai sistemi. Nella maggior parte dei casi un sistema di identity management non dà il massimo con le congurazioni di base. Lo sta IT dovrà quindi procedere a diverse customizzazioni, specialmente se le funzioni di gestio-ne automatizzata degli accessi devono essere estese ai sistemi legacy, alle applicazioni sviluppate in-house e ad altri sistemi non standard.

In alcuni casi può essere più conveniente limitare questa estensione. Se un sistema legacy o non standard, ad esempio, ha pochi utenti, conviene mantenere una gestione manuale dei loro privilegi anche se resta separata dalla gestione complessiva.

Seguire il mercato

Il mercato va consolidandosi, e questo va considerato. Il settore dell'i-dentity management sta evolvendo velocemente e questa evoluzione prevede anche il suo consolidamento, con produttori specializzati che vengono

acqui-1.1.1.1 Come avvicinarsi all'Identity Management 18 siti da aziende più grandi e più generaliste. La strategia per gestire questa incertezza sta nel realizzare i propri processi di identity management in una maniera standardizzata: se a un certo punto si è costretti a passare a una nuova tecnologia, almeno il peso delle modiche architetturali sarà ridotto al minimo.

Ciò comporta il capire se e quanto il proprio fornitore di riferimento stia seguendo i (non molti) standard che si stanno delineando nel settore e, di conseguenza, si deve dedicare un certo tempo a capire in che direzione si stiano muovendo le organizzazioni più o meno indipendenti come Oasis6 _{o la}

Liberty Alliance7_.

Settori richiedeti Identity Management

I settori che hanno sentito maggiormente la necessità di dotarsi di sistemi avanzati di identity management, sono stati:

• La pubblica amministrazione • Il settore energetico

• Il settore bancario-nanziario • Il settore delle telecomunicazioni.

Infatti, proprio per la delicatezza delle operazioni di business di tali setto-ri, è necesario un livello avanzato di controllo e documentazione dell'accesso ai sistemi.

Strumenti di prevenzione

Nella gestione del controllo degli accessi assume un valore strategico do-tarsi di strumenti automatici di correlazione tra eventi distinti, per poter allertare i sistemi di security di un eventuale tentativo di accesso non auto-rizzato in corso. Grazie a strumenti di questo tipo è possibile, per esempio, mettere in stato di preallerta il sistema nel caso in cui vengano registrati due

6_{Organization for the Advancement of Structured Information Standards}

7_{La missione del progetto Liberty Alliance è quella di stabilire uno standard aperto per}

tentativi di utilizzo errato di password in concomitanza con un altro evento insolito, riconducibile ad un tentavo di accesso non autorizzato, su un'altra applicazione del sistema. In molte situazioni i pericoli dipendono anche da un eccessivo spazio di manovra concesso ai dipendenti, e non dalla volontà dolosa degli stessi: anche senza volerlo, infatti, a volte si possono procurare danni anche ingenti per errore o per semplice inecacia o indisponibilità di questi controlli incrociati automatici.

Occorre avere un'ottica il più possibile sistemica dei sistemi informatici, inquadrandogli nel contesto del rischio operativo, con strumenti evoluti di auditing. La qualità di risposta del sistema di sicurezza è determinata dal-l'impiego intelligente di processi di correlazione con l'attivazione di precisi messaggi di alert. Il cruscotto delle aziende8 _{è costituito quindi dalla}

capa-cità di monitorare in tempo reale eventi che potrebbero creare problemi dal lato della sicurezza, correlando tanti eventi presi da tanti accesi o log dei vari sistemi per poter vericare la presenza di anomalie in tempo reale.

Piattaforma del sistema informatico aziendale

L'infrastruttura, cioè la piattaforma che regge il sistema informatico azien-dale, deve essere solida ed adabile. Per questo è necessario un maggiore dialogo tra infrastrutture già alla fonte, ovvero tra i sistemi operativi (che possono essere più di uno in una azienda), sono poi la base su cui poggia ogni applicazione informatica aziendale. Si tratta infatti, di contribuire ad una maggiore interoperabilità tra mondo windows e mondo open source, per-ché questo si traduce in un benecio per il cliente nale, indipendentemente dalla scelta di sistemi e software adottati in azieda.

8_{Il cruscotto aziendale, consente di eettuare un'autoanalisi aziendale e, inoltre,}

1.1.1.2 Denizione di identità digitale 20

1.1.2 Denizione di identità digitale

Dei concetti di identità digitale (digital identity),identità di rete (network identity) o identità elettronica (electronic identity) esistono molteplici inter-pretazioni, spesso contrastanti. Nel corso di questa tesi si userà l'eccezzione di identità digitale come insieme delle informazioni in rete aerenti ad un unico soggetto:

Network identity refers to the global set of attributes that are contained in an individual's various accounts with dierent service providers. These attributes include such information as name, phone numbers, social security numbers,

addresses, credit records, and payment information9_.

1.1.3 Tassonomia dell'IDEntity Management

I sistemi (o i modelli) di IDEM possono essere classicati in base alla specica `losoa' di gestione del trust:

IDEM isolato. Corrisponde al modello di IDEM attualmente più diuso. Ogni servizio ha un proprio bacino d'utenza indipendete ed ad ogni utente viene assegnata una credenziale distinta per ogni servizio a cui fa ac-cesso. questo approccio semplica l'IDEM per i Service Provider (SP), ma presenta seri problemi di usabilità per gli utenti all'aumentare dei servizi utilizzati.

Le istanze di trust coinvolte in questo modello sono piuttosto semplici: T1 Il SP tutela la privacy dell'utente.

T2 Il SP ha implementato procedure di registrazione e meccanismi di autenticazione adeguati.

T3 Il client gestisce responsabilmente le credenziali ricevute dal SP. IDEM federato. La federazione dell'identità (identity federation) si può

de-nire come l'insieme di tecnologie, standards ed accordi che permettono ad un insieme di SP di accettare come validi i identicatori utente gestiti da un'altro insieme (non necessariamente distinto) di providers,

detti Identity Provider (IdP). Tale comunità di providers (SP ed IdP) viene tipicamente denominata federazione o circle of trust.

La federazione dell'dentità viene realizzata collegando i diversi identi-catori utilizzati dai provider della federazione e relativi ad uno stesso utente. Un tale approccio implementa implicitamente il Single Sign On (SSO), ovvero la possiblità per un utente di autenticarsi presso uno qualsiasi dei providers della federazion e, successivamente, di accedere ai servizi di tutti gli altri.

Questo approccio all'IDEM introduce nuove topologie di trust, ed in particolare la presenza di accordi di trust tra providers. Le istanze T1, T2 e T3 valgono anche in questo caso, ma adesso T1 e T2 si applicano ai providers che fungono da IdP. I clients ed i providers devono inoltre supportare le seguenti istanze:

T4 All'origine di una richiesta di servizio (rispettivamente di identi-cazione) di un IdP (SP) nei confronti di un SP (IdP) vi deve essere sempre una esplicita richiesta dell'utente.

T5 La corrispondenza tra gli identicatori collegati in una federazione deve essere corretta, ovvero essi devono far tutti riferimento ad una stessa identità digitale.

T6 La circolarità tra i providers delle informazioni sull'utente deve essere regolata da opportune polices accettate da tutte le parti al momento della federazione dell'identità.

IDEM centralizzato. Questo modello di IDEM 'e costituito essenzialmente da un unico IdP che si occupa di identicare gli utenti per conto di una molteplicità di SP10_{. Le informazioni costituenti l'identità digitale di un}

utente possono anche in questo caso essere distribuite tra i providers, ma l'identicatore ad essa associato è unico e gestito dall'IdP. Come il precedente, anche questo modello permette il SSO.

Le istanze di trust applicabili all'IDEM centralizzato sono T1, T2, T3 e T6, di cui le prime due sono da applicarsi all'unico IdP.

10_{Alcuni dei sistemi che seguono questo modello: Kerberos, Microsoft .NET, Passport e}

1.1.2 Esempi progetti IDEM 22

1.2 Esempi progetti IDEM

1.2.1 Banca Popolare di Sondrio

Nell'ambito di un importante progetto di rinnovamento del sistema in-formativo, con particolare attenzione al mondo del software Open Source, la Banca Popolare di Sondrio ha avviato un progetto pilota che preveda l'u-tilizzo di RAP311_{, la suite di Identity & Access Management rilasciata da}

SysNet, per gestire e tenere sotto controllo l'accesso e l'identià di tutti i suoi utenti, siano essi dipendenti, clienti e partner.

Gestire l'aumento dei punti di accesso e la crescente interazione tra di-versi utenti determinata dall'avvento di Internet, e monitorare applicazioni e servizi sviluppati in tempi e ambienti diversi e senza standard di riferimento, comporta infatti un impegno ogni anno più signicativo in termini di costi, tempo e risorse.

La Banca ha perciò avvertito la necessità di conoscere e identicare tutte le risorse disponibili, umane, host, indirizzi, stampanti, applicativi, ecc., per utilizzare al meglio e soddisfare così le esigenze di un mercato in continua evoluzione nel totale rispetto dei vincoli legislativi sulla privacy previsti dal decreto legge 196/03.

Il responsabile dell'integrazione dei servizi di rete della Banca Popolare di Sondrio ha dichiarato:

Il software open source e la essibilità dei moduli che costituiscono RAP3, ha consentito di avere una soluzione a costi contenuti, perfettamente rispondente alle nostre esigenze. La gestione centralizzata di utenti, sistemi

e applicazioni e delle rispettive relazioni, resa disponibile dalla suite di SysNet, sia estremamente vantaggiosa in termini di riduzione dei csoti e di

aumento della produttività.

11_{Con Rap3 è possibile gestire le identità aziendali (utenti, host, indirizzi, etc.) in modo}

Capitolo 2

Standards e tecnologie di rilievo

In questo capitolo viene presentata una selezione degli standard e delle tecnologie riguardanti le problematiche dell'Identity Management. Gli stan-dard e le tecnologie di questo capitolo sono suddivisi in tre categorie che riettono altrettante problematiche fondamenti dell'area dell'Identity Mana-gement: il formato e lo scambio di credenziali, il Single Sign On ed il controllo di accesso, detto anche autorizzazione.

2.1 Standards sul formato e lo scambio di

cre-denziali

La credenziale, nell'eccezione di documento certicato attestante l'iden-tità o altre qualiche di un soggetto, è l'elemento informativo centrale nelle problematiche di Identity Management. Qualsiasi soluzione di Identity Ma-nagement - per denizione - si trova a dover gestire delle identità digitali, ed ognuna di queste ultime non può essere ritenuta tale senza un insieme di credenziali che la supporti.

Per tanto è evidente la necessità di una buona standardizzazione e diu-sione sul mercato delle tecnologie relative questo aspetto, prima ancora della qualità intrinseca di esse. È per questo motivo che uno standard, per molti aspetti legacy e limitato come X.509, è tuttora il più utilizzato in ambito Internet e non, per l'autenticazione forte di identità digitali.

2.2.1.1 SAML 24

2.1.1 SAML

Security Assertion Markup Language (SAML) è uno standard basato su XML per la creazione e la comunicazione di tokens di sicurezza. Esso è stato prodotto, a partire dal 2001, dal Security Services Technical Commitee di OA-SIS (Organization for the Advancement of Structured Information Standards, http://www.oasis-open.org/). La più diusa implementazione Open Source di SAML è OpenSAML (OpenSAML - an Open Source Security Assertion Language implementation, http://www.opensaml.org/.).

SAML ha come obiettivo principale la creazione di un framework di sup-porto per la problematica del SSO e, più in generale, dell'IDEM. Tuttavia, nel corso degli anni, sono emersi altri utilizzi dello standard come ad esem-pio la restrizione di deleghe in CAS (Central Authentication Service) o la sicurezza di messaggi SOAP (Simple Object Access Protocol).

2.1.2 X.509

X.509 è uno standard di ITU-T (International Telecommunication Union, Telecommunication standardization sector, http://www.itu.int/ITU-T/) che denisce una PKI (Public key infrastructure). Nel corso degli anni, grazie anche agli adattamenti apportati da IETF (Internet Engineering Task Force, http://www.ietf.org/), è diventato lo standard di fatto per quanto riguarda l'autenticazione forte in ambito Internet.

Crittograa a chiave asimmetrica. La crittograa a chiave simmetri-ca, conosciuta anche come crittograa a coppia di chiavi, crittograa a chiave pubblica/privata o anche sono L'elemento informativo di base dello standard è il Public Key Certicate (PKC), ovvero il documento che associa il nome di un soggetto alla sua chiave pubblica. I certicati sono emessi e rmati da una CA (Certicate Authority) su richiesta del soggetto ed hanno una validità temporale ssata.

Una PKI X.509 è tipicamente composta da più CA organizzate in una struttura ad albero, alla radice della quale si trova la root CA. Ciascuna CA è denotata di un certicato emesso e rmato da una CA di livello superiore ad eccezione del root che utilizza un certicato auto rmato. Le foglie

dell'al-bero sono i soggetti per i quali è stato emesso un certicato. Una struttura di questo tipo permette di avere garanzia dell'autenticità di un soggetto dan-dosi esclusivamente dell'autenticità della root CA. Chi ha bisogno di questa garanzia può infatti risalire all'albero no alla radice, vericando che ogni nodo intermedio abbia un certicato rmato dal nodo padre.

In caso di compromissione del soggetto associato ad un certicato (può accadere per esempio che la sua chiave privata venga scoperta), quest'ultimo può essere revocato pubblicando in una Certicate Revocation List (CRL).

Nelle sue ultime evoluzioni, lo standard X.509 specica un altro tipo di certicato: l'AC (Attribute Certicate). Anziché la chiave pubblica di un soggetto, un AC contiene privilegi e credenziali utili per una autorizzazione ad opera di un'opportuna autorità. Gli AC sono ammessi e rmati da una Attribute Authority (AA) e possono essere immagazzinati in un database LDAP (Ligthweight Directory Access Protocol).

2.2.2 SSO (Single Sign On) 26

2.2 SSO (Single Sign On)

Il Single Sign On (SSO) è una particolare forma di autenticazione (ad autorizzazione) che permette l'accesso a più risorse protette a partire da un'unica, iniziale, interazione di autenticazione da parte del soggetto fruito-re. Esistono varie tipologie di SSO in funzione di contesti applicativi e dei soggetti coinvolti. Quella che verrà presa in considerazione in questa sezione è denominata Single Sign On su web.

2.2.1 SSO su web

Il SSO su web si applica esclusivamente all'accesso autenticato a risorse web (statiche o dinamiche), tipicamente eettuato tramite un browser1_{. I}

soggetti che accedono ad una tale risorsa per la prima volta nell'arco di una stessa sessione, vengono dirottati presso un servizio di autenticazione, detto Identity Provider. Successivamente, se quest'ultima ha avuto successo, essi vengono rediretti nuovamente preso la risorsa iniziale, protetta da un Service Provider, a cui verranno comunicati gli aggiornamenti sullo stato di autenticazione di tali soggetti.

L'approccio al SSO (ed all'Identity Management in generale) è di tipo federativo in tutte le soluzioni presentate. Non viene imposta dall'alto l'a-dozione di un particolare Idenity Provider, ma vengono invece forniti gli strumenti per stringere legami di trust con una federazione2 _{di tali providers}

senza vincoli gerarchici precostituiti.

I vantaggi del SSO sul web in confronto alle soluzioni tradizionali, sono: Usabilità. Il soggetto fruitore deve eettuare meno interazioni per accedere

agli stessi servizi.

Sicurezza. Dato che un evento è raro, all'operazione di autenticazione può essere dedicata maggiore attenzione, eventualmente implementando tec-niche 'forti' su base di crittograa. Per il SSO di tipo federativo questo

1_{Esite anche la possibilità di estendere queste modalità di accesso al contesto dei Web}

Services.

è vero a maggior ragione in quanto gli Identity Provider potrebbero essere gli unici ad avere le informazioni necessarie ad eettuare tale operazioni sui propri soggetti.

Scalabilità Un soggetto che si autentica presso un certo Identity Provider può accedere a risorse protette da un Service Provider che non ha bi-sogno di mantenere internamente informazioni sul conto: può ottenerle dal Service Provider. tale fenomeno implica una maggiore scalabilità delle soluzioni SSO con il conseguente aumento dei soggetti servibili a parità d'investimento.

Incentivi alla federazione Un Service Provider è motivato ad aderire ad una federazione dal fatto che può accedere ad una bacino d'utenza più ampio3 _{(quello di tutti gli Identity Provider della federazione).}

Dall'al-tro canto un Identity Provider che entri in una federazione garantisce ai propri soggetti una migliore oerta di servizi in termini di qualità, quantità e diversicazione.

3_{Questo è il caso, ad esempio, di molti fornitori di contenuti didattici a pagamento che}

2.2.2.2 Shibboleth 28

Figura 2.1: Dierenza tra autenticazione web locale e autenticazione web centralizzata

2.2.2 Shibboleth

Shibboleth, è un progetto inter-universitario del gruppo Middleware Ar-chitecture Committee for Education (MACE), appartenente al consorzio In-ternet2. Le sue nalità sono la progettazione, la specica e l'implementazione Open Source di sistemi per la condivisione inter-istituzionale di risorse web soggette a controllo di accesso.

Questo progetto nasce inizialmente per semplicare il problema dell'ac-cesso a contenuti didattici riservati da più campus universitari, ciascuno con

una dierente infrastruttura di autenticazione. Shibboleth si può tuttavia applicare ad altri contesti - come quelli dell'e-Business e della PA (Pubbli-ca Amministrazione) - ed è probabilmente la più completa implementazione Open Source di un sistema di SSO su web. Bisogna anche notare, che a die-renza di altri sistemi analoghi, Shibboleth ha adottato n dall'inizio SAML per implementare gran parte dei suoi protocolli.

Architettura generale

Le entità coinvolte in un protocollo di SSO usando Shibboleth sono: Identity Provider (IdP): l'organizzazione in grado di autenticare l'utente

e fornire informazioni aggiuntive o attributi sul suo conto.

Service Provider (SP): l'ente presso il quale è gestita la risorsa web a cui l'utente fa richiesta e che ha il compito di proteggerla attraverso una qualche forma di policy di accesso.

User Agent (UA): è l'applicazione4 _{che, per conto dell'utente, innesca i}

protocolli di SSO richiedendo l'accesso ad una risorsa web protetta da un SP.

Where Are You From (WAYF): si tratta di un servizio gestito da una parte o dal SP stesso il cui compito è scoprire l'IdP di appartenenza dell'utente.

Non è prevista una gerarchia tra i providers: in ogni organizzazione è re-sponsabile dei propri utenti (nel caso degli IdP) e/o delle proprie risorse (nel caso dei SP). La rete di trust risultante è orizzontale ed in Shibboleth viene denominata federazione. Il SP che sceglie di aderire ad una federazione ac-cetta implicitamente un legame di trust con tutti i IdP che ne fanno parte. Simmetricamente, un IdP accetta di emettere asserzioni su richiesta di un qualsiasi5 _{SP della federazione. Shibboleth non vieta tuttavia la possibilità}

di specicare rapporti di trust bilaterali tra singoli SP ed IdP. Quest'ultimo

4_{Tipicamente un browser web}

5_{Il contenuto informativo delle asserzioni può essere tuttavia dierenziato in funzione}

2.2.2.2 Shibboleth 30 approccio ha una scalabilità ridotta ma può risultare utile per piccole con-gurazioni o per specicare rapporti dierenziati tra providers all'interno di una federazione preesistente.

Figura 2.2: Diagramma temporale delle interazioni per il SSO e lo scambio di attributi usando Shibboleth

Come mostrato in gura, per un generico protocollo di SSO, le interazioni tra le entità sono le seguenti:

1. Lo UA, per conto dell'utente, richiede l'accesso ad una risorsa web presso il SP. Sia assume che lo UA non abbia ancora una sessione attiva con il SP.

2. Il SP redirige lo UA verso il WAYF o direttamente presso l'IdP di appartenenza. Il contenuto della URL di destinazione costituisce una authentication request e contiene informazioni sulla risorsa richiesta, un identicativo del SP e l'endpoint presso il quale il SP intende ricevere l'asserzione di autenticazione.

3. Se interrogato, il WAIF processa la authentication request del SP (ma trasportata dallo UA) ed interagisce con l'utente per conoscere l'IdP presso il quale intende autenticarsi. Tale informazione viene memoriz-zata in una sessione a lungo termine tra il WAYF e lo UA (ad es. un cookie). Successivamente il WAYF redirige lo UA verso l'IdP scelto dall'utente.

4. L'IdP identica l'utente innescando un meccanismo di autenticazione o sfruttando una sessione ancora attiva. Shibboleth non considera il particolare meccanismo di autenticazione utilizzato.

5. L'IdP invia un'asserzione di autenticazione al SP utilizzando il prolo SAML browser/POST o browser/artifact.

6. Il SP invia una richiesta di attributi dell'utente all'IdP. 7. Se interrogato, IdP risponde alla richiesta di attributi del SP.

8. Sulla base delle informazioni sull'utente, il SP eettua la decisione per l'accesso dell'utente alla risorsa richiesta. In funzione dell'esito di tale decisione il SP invia una risposta HTTP opportuna allo UA.

2.2.2.2 Shibboleth 32 Componenti

Per supportare i protocolli di SSO, i providers coinvolti espongono un certo numero di funzionalità distinte. Nella terminologia di Shibboleth6_{, tali}

funzionalità vengono denominate ruoli. Un tipico IdP avrà un insieme di ruoli disgiunto da un tipico SP, ma non vanno esclusi i casi in cui uno stesso provider fornisca (alcune delle) funzionalià di IdP e SP contemporaneamente.

Le gure 2.3 e 2.4 sono state tratte da http://shibboleth.internet2.edu/docs/draft-mace-shibboleth-tech-overview-02.pdf, ed illustrano i tipici componenti di un

IdP e di un SP (rispettivamente), nonchè le principali interconnessioni tra di essi.

Figura 2.3: Componenti di un tipico IdP.

Authentication Authority. Si tratta di un servizio che emette asser-zioni SAML di autetnicazione dopo aver ottenuto conferma dell'identià del-l'utente dall'applicazione che esegue l'autenticazione vera e prorpia. Entra in azione al passo 4 del protocollo generico di SSO (visto in 2.2.2.2).

Nell'uso comune di di Shibboleth non è prevista l'invocazione diretta di que-sto servizio da parte del SP.

SSO Service. È un'applicazione web dell'IdP che riceve le richieste di autenticazione del SP ed innesca l'opportuno prolo SAML di SSO (passi 2/3, 4, 5). Questo componente costituisce il primo punto di contatto di un

IdP se il protocollo di SSO ha inizio presso il SP7_.

Artifact Resolution Service. Utilizzato esclusivamente nei casi in cui si utilizza il prolo SAML browser/artifact, costituisce il web service che tra-duce glia rtifacts in asserzioni. Viene innescato al passo 5 del protocollo in 2.2.2.2.

Attribute Authority (AA). Si tratta di un web service che fornisce asserzioni SAML di attributi utilizzando il SAML SOAP Binding. Gestisce i passi 6 e 7 del protocollo in 2.2.2.2 dal lato del IdP.

L'accesso agli attrbuti da parte dei singoli providers richiedenti è a sua volta soggetto a controllo di accesso, regolato da una policy detta Attribute Release Policy (ARP). In tale policy conuiscono esplicite esegenze di privacy espresse dall'utente e direttive generiche dall'IdP, il tutto in funzione del particolare provider richiedente.

Figura 2.4: Componenti di un tipico SP.

Assertion Consumer Service. È una applicazione web alla quale ven-gono inviate le asserzioni di autenticazione da parte dell'IdP. Implementa il passo 5 del protocollo in 2.2.2.2 dal lato SP.

L'Assertion Consumer Service ha un comportamento dierte a seconda del prolo SAML che si usa. NEl caso del browser/POST estrae direttamente le asserzioni dalla richiesta HTTP. Nel caso del browser/artifact, invece, deve

2.2.2.2 Shibboleth 34 risolvere gli artifacts8 _{in asserzioni interrogando l'Artifact Resolution Service.}

Attribute Requester. È un client web service che richiede attributi sAML alla AA come descritto nei passi 6 e 7 del protocollo generico di SSO. Simmetricamente nel caso della AA, l'Attribute Request è dotato di funzio-nalità di ltraggio degli attributi ricevuti. Essi infatti possono essere scartati in base ad una Attribute Acceptance Policy (AAP) o rinominati per una più agevole gestione da parte del provider richiedente.

Resource Manager (RM). Si tratta del componente che implementa i passi 1 e 8 del protocollo di SSO dal lato del SP. Il suo compito principale è quello di valutare la policy di accesso in funzione delle asserzioni ottenute. Esso può inltre cr4eare una sessione per la risorsa protetta, nel caso in cui questa sia dinamica (ovvero un'applicazione web). Sempre in quest'ultimo caso, il RM può delegare la decisione di accesso alla risora stessa, limitandosi ad innescare il protocollo di SSO ed a raccogliere le asserzioni.

Estensioni allo standard SAML

È evidente quanto l'interoperabilità sia la chiave di successo per i sistemi di questo tipo. Una federazione Shibboleth può coinvolgere enti che hanno necessità di interagire (e quindi modicare) Shibboleth con la propria infra-struttura di ICT(Information and Communication Technology). Può inoltre rendersi necessario per un provider mantenersi interoperabile con altri si-stemi di IDEM. Detto questo non stupisce l'attenzione riservata al gruppo di lavoro MACE (Middleware Architecture Committee for Education) alla standardizzazione di interface e protocolli, sotto forma di estensioni al già diuso e prometente standard SAML. Shibboleth può essere infatti visto co-me infrastruttura (minima) necessaria a rendere un'applicazione di SAML un sistema di SSO su web completo.

Authentication Request Prole. In Shib-proto9 _{si standardizza un} 8_{Ricevuti sotto forma di parametri della query string}

nuovo prolo per SAML detto Authentication Request Prole. Il suo compito è quello di estendere i proli per il SSO di SAML, hanno tutti inizio presso l'IdP dell'utente, in modo che possano iniziare presso il SP. I passi 1-3 del-l'esempio fornito nella sezione 2.2.2.2 seguono per l'appunto questo prolo. In sostanza l'Authentication Request Prole specica il foamto della richiesta HTTP10 _{del passo 2, l'introduzione del WAYF ed alcune regole di}

processa-mento da parte delle entità riceventi tale richiesta (IdP e WAYF).

Metadata Prole. Sia SAML che Shibboleth assumono l'esistenza di accordi, detti metadati, tra le entità partecipanti ai protocolli di SSO. Tali accordi riguardano i ruoli assunti, il formato dei nomi utenti, quali bindings o proli siano supportati, gli endpoints forniti, i certicati e le chiavi possedute, ecc.

I dettagli sulla forma ed il contenuto dei metadati sono tuttavia stan-dardizzati solo in SAML 2.0. Pertanto, il gruppo di lavoro di Shibboleth ha creato un nuovo prolo per SAML 1.1, detto SAML 1.x Metadata Prole11_,

che 'importa` alcune delle innovazioni presenti nella versione 2.0.

In pratica i metadati SAML 2.0 sono dei documenti XML che descrivo-no le peculariarità dei providers che li pubblicadescrivo-no. Tali documenti posso-no presentarsi anche in forma aggregata, ovvero descrivere tutti i providers all'interno di una federazione.

10_{Eettuata utilizzando il metodo GET}

11_{http://www.oasis-open.org/committees/download.php/13254/}

2.2.3 CAS - Central Authentication Service 36

2.3 CAS - Central Authentication Service

2.3.1 Introduzione

Il CAS è un sistema di autenticazione centralizzato sviluppato come pro-getto open source presso l'Università di Yale (http://www.yale.edu/) che ore un servizio di validazione delle credenziali utente. Esso è in grado di creare un ambiente di lavoro unico di tipo single sign-on per applicazioni web o per risorse che utilizzano le stesse (es. mail servers).

I motivi che portano alla scelta di un sistema basato sull'autenticazio-ne singola sono la convenienza e la sicurezza, infatti, gli utenti devono fare sempre di meno e le applicazioni sono protette da qualcuno altro. la cen-tralizzazione del servizio garantisce, inoltre, la cencen-tralizzazione dei contenuti insieme alla centralizzazione della autenticazione.

Figura 2.5: Esempio di autenticazione con il CAS e senza il CAS

2.3.2 Funzionamento

I funzionamento del CAS può essere illustrato nel seguente modo: • L'utente cerca di accedere ad una applicazione o ad una risorsa web

usando l'URL dalla stessa. Esso viene rediretto all'URL della pagina di login del CAS su di una connessione HTTPS, passando il nome del

servizio come parametro, e si trova di fronte ad una scheda contenente uno username e una password da inserire.

• Dopo l'inserimento dei campi richiesti il CAS tenta di autenticare l'u-tente. Se l'autenticazione fallisce l'applicazione a cui tentava di accedere l'utente non si accorge di nulla e questi rimane bloccato alla pagina di autenticazione del CAS.

• Se invece l'autenticazione viene portata a termine regolarmente l'utente viene rediretto alla risorsa che era stata richiesta in precedenza appen-dendo però all'URL di redirezione un così denito ticket. CAS cerca di creare un in-memory cookie denito ticket-granting cookie. Questo viene fatto per permettere la reautenticazione in seguito dall'utente o dove previsto la autenticazione a ulteriori servizi, se presente, infatti, il cookie indica che l'utente si è già autenticato con successo e questo evita di dover reinserire i suoi dati.

• L'applicazione richiamata dall'utente poi verica che il ticket sia cor-retto e che rappresenti un utente valido chiamando la funzione service-Validate URL aprendo una connessione HTTPS e passando il ticket e il nome del servizio come parametro. CAS controlla che il ticket inviato sia valido e associato con il servizio richiesto dopodichè se la validazione ha successo viene restituito al chiamante il nome utente.

2.2.3.3 Schema 38

2.3.3 Schema

Il sistema aronta il problema della sicurezza in maniera ottima, infatti, la password ed il nome utente, circolano solamente nel browser ed il ser-ver attraser-verso un canale criptato. Le reautenticazioni seguenti sono fatte in maniera del tutto trasparente all'utente previa accettazione da parte dello stesso di un cookie privato, solo il CAS può leggere e scrivere questo cookie che contiene solo un identicativo di sessione; l'applicazione riceve un tic-ket opaco che non contiene informazioni personali. Questo tictic-ket circola in chiaro no al browser, ha un breve tempo di vita e non utilizzabile da alcuna altra applicazione se non dalla applicazione che lo ha richiesto.

Figura 2.7: Schema di funzionamento del CAS-proxy

2.3.4 Proxy

Gli sviluppatori di CAS a Yale hanno pensato di introdurre nella versione 2.0 nuove caratteristiche tra le quali la possibilità di sviluppare un applicativo proxy.

L'utilizzo di queste nuove funzionalità permette di accedere ad una ap-plicazione remota utilizzando le stesse credenziali presentate dall'utente al sistema di autenticazione, agendo come client per conto dello stesso. Tut-to ciò trova impiego in vari ambiti tra i quali: portali web (presso il quale il client si è autenticato ed ha la necessità di interrogare una applicazione

esterna), portali di posta elettronica (a cui un client autenticato richiede la connessione ad un server IMAP12_{per visionare la propria posta elettronica)}

o accessi ad una applicazione web esterna al servizio di validazione.

Figura 2.8: Schema di funzionamento dettagliato

12_{Un server POP3 o IMAP, conosciuto anche come server di posta in ingresso, è quel}

server a cui il vostro client di posta elettronica si può collegare per scaricare la vostra posta. Nel mondo di internet, esistono principalmente due tipi di server di posta in ingresso: server IMAP e server POP3. IMAP è il protocollo più recente, più potente, complesso, essibile e lento. Si consiglia l'utilizzo del protocollo IMAP a soli utenti esperti. POP3 è il protocollo più aermato, meno potente e essibile dell'IMAP ma veloce e facile da usare. L'indirizzo del nostro server IMAP è: IMAP.nomedominio, mentre l'indirizzo del server POP3 è: POP3.nomedominio.

2.2.3.5 Funzionamento 40

2.3.5 Funzionamento

In una installazione multi-tier di CAS il proxy agisce come agente per conto dell'utente, i passi con cui si svolge l'azione di tale applicazione sono i seguenti:

1. Richiesta iniziale: il client accede ad una applicazione che necessita di una autenticazione, questa applicazione redirige la richiesta verso l'URL del server CAS attraverso il protocollo HTTPS.

2. Autenticazione: il server CAS autentica l'utente grazie a un meccanismo locale di autenticazione (LDAP, Kerberos,...) e redirige la richiesta ver-so l'applicazione iniziale; se il browser del client accetta i cookie viene fornito, come spiegato in precedenza, un ticket granting cookie. 3. Ritorno all'applicazione web: il client viene reindirizzato

all'applicazio-ne web e gli vieall'applicazio-ne fornito un Service Tiket.

4. Validazione: l'applicazione web accede dirottamente al server CAS tra-mite protocollo HTTP (url serviceValidate) e mette nell'url alcuni parametri quali l'ID del servizio, il service ticket, l'url di callback. Se il service ticket è valido il server ritorna come parametro l'identica-tivo dell'utente e un PGT-id (Questo non è il PGT ma un indice che permette di validarlo).

5. Invio del PGT (Proxy-Granting-Ticket): contemporaneamente all'azio-ne al punto precedente, il server CAS geall'azio-nera una conall'azio-nessioall'azio-ne HTTPS verso l'indirizzo contenuto nell'URL di callback dell'applicazione proxy inviando il PGT e il PGT-id.

Intanto l'applicazione web proxy-CAS dispone di un PGT relativo al-l'utente, grazie al quale richiedere al CAS la generazione dei PT (Proxy Ticket) che sono l'equivalente dell'ST (Service Ticket) ma per servizi di tipo proxy.

6. La richiesta di un PT : il proxy-CAS genera una richiesta HTTPS verso il server CAS passando come parametri il PGT ed il targetService che è l'url dell'applicazione di destinazione. Se il PGT è valido il proxy ritorna un PT.

7. Trasmissione del PT : il proxy-CAS passa il PT ai servizi che vuole utilizzare.

8. Validazione: il servizio utilizza il PT come un ST, accedendo diretta-mente al server CAS tramite HTTPS (url proxyValidate) passando il suo ID di servizio e il PT. Il server CAS si assicura della validità del ticket, ritorna l'identicatore della persona e il proxy.

2.2.4 AAA (Authentication Authorization Accounting) 42

2.4 AAA

Il controllo degli accessi è uno degli elementi fondamentali per l'infra-struttura di rete, in questo modo è possibile controllare chi può avere accesso alla rete e cosa può fare, quali servizi può eettivamente utilizzare, dopo aver eseguito l'accesso.AAA è un framework attraverso il quale noi possiamo congurare gli accessi sulla rete.

Nella maggioranza dei casi AAA utilizza protocolli come RADIUS, TA-CACS+, o Keberos per amministrare le sue funzioni di sicurezza. Se il router utilizzato, o access server, ha funzionalità di NAS (Network Access Server) AAA rappresenta la modalità attraverso la quale stabiliamo la comunicazione tra il NAS utilizzato e il RADIUS, TACACS+ o Kerberos security server.

AAA rappresenta il principale metodo per eettuare il controllo di ac-cesso, in ogni caso l'IOS13 _{fornisce altre funzionalità per tale scopo come}

le autenticazioni basate su local username, la line password e la enable password.

Il framework AAA si propone di fornire una via modulare all'esecuzione dei seguenti servizi:

2.4.1 Authentication

Fornisce il servizio di identicazione degli utenti, attraverso moltepli-ci modalità: login/password, challenge/response, encryption (a seconda del protocollo scelto).

L'auntenticazione ci consente di identicare l'utente prima che sia auto-rizzato all'accesso di rete o ai servizi.

2.4.2 Authorization

Fornisce il servizio per il controllo remoto degli accessi, autorizzazione per utente, autorizzazione per gruppo, autorizzazione per servizio.

Si basa sulla creazione di un insieme di attributi che descrivono le policy associate all'utente. Un database locale o remoto contenente le informazioni

per singolo utente servirà per comparare tale set di informazioni con quelle presenti al suo interno, il risultato sarà ritornato ad AAA che determinerà le azioni che l'utente può o non può compiere.

I server remoti, anche retti remote security server, autorizzano l'utente associandogli una coppia (A,V), attributo-valore, che densice queste azioni.

2.4.3 Accounting

Fornisce il servizio di invio di dati utilizzati per il billing14_{, l'auditing}15_,

il reporting, come identità, tempo di start-stop, comandi eseguiti, numero di pacchetti e numero di bytes.

In questo modo possiamo tracciare le attività dell'utente, come i servizi utilizzati e le risorse di rete consumate. Questo consente la possibilità di un'analisi a posterioro dei dati collezionati con scopi di auditing, bolling e network management.

14_{Gestione dei costi}

Capitolo 3

Installazione Shibboleth Service

Provider

3.1 Introduzione

Questa sezione descrive le speciche di installazione di un Service Provi-der Shibboleth 1.3 e congurazione per una FeProvi-derazione GARR. Riguarda l'installazione su Debian GNULinux 3.1 (Sarge) con Apache 1.3.

È possibile trovare informazioni più approfondite su Shibboleth Wiki di Internet2 (http://spaces.internet2.edu/display/SHIB/WebHome).

Il Service Provider Shibboleth (SP) 1.3 è implementato in C/C++ come un modulo di autenticazione di Apache mod_shib e un demone separato shibd.

I valori di esempio presi in questa sezione sono: shibsp.unipr.it

3.2 Prerequisiti

Come detto nell'introduzione, questa sezione si riferisce ad una Debian 3.1 (sarge), e contiene alcuni riferimenti a specici strumenti di Debian.

Apache + mod_ssl

Versione di Apache raccomandata >= 1.3.33, Debian Package: apache

Versione mod_ssl raccomandata >= 2.8.22, Debian Package: libapache-mod-ssl WebServer Apache dovrà usare mod_ssl per la gestione delle connessioni HTTPS. oppure Versione Apache-ssl >= 1.3.33, Debian Package: apache-ssl

oppure Apache2

Debian Package: apache2-mpm-worker. OpenSSL

Versione raccomandata >= 0.97, Debian Package: openssl

I tool OpenSSL verranno utilizzati per gestire i certicati dei server.

3.3 Installazione di Shibboleth SP 1.3

3.3.1 Utilizzo dei pacchetti debian

Sono disponibili dei pacchetti debian precompilati, necessari per l'instal-lazione di Shibboleth Service Provider 1.3.

Si può semplicemente installarli usando apt-get.

Occorre aggiungere ai repository della propria source list di apt: /etc/apt/sources.list

...

deb http://shib.kuleuven.be/debian-repository binary/ ...

Questo repository contiene 6 pacchetti: • liblog4cpp: Una libreria C++ per i log

3.3.3.2 Compilazione da sorgente 46 • libxmlsecurity: È una specica di implementazione della Firma Digitale

XML

• libopensaml: È una implementazione della Security Assertion Markup Language

• Shibboleth-sp: Shibboleth Service Provider con modulo Apache

Dopo aver aggiunto il repository occorre aggiornare la lista dei pacchetti: root# apt-get update

È Possibile avere alcune informazioni (versione, descrizione, dipendenze, ...), su di un determinato pacchetto, nel seguente modo:

root# apt-cache show <package name>

Vi è anche la possibilità di installare i pacchetti separatamente o instal-lare soltanto l'ultimo pacchetto nella gerarchia delle dipendenze. Tutte le dipendenze sull'ultimo pacchetto verranno risolte automaticamente.

root# apt-get install shibboleth-sp

I pacchetti saranno mantenuti in modo tale da essere aggiornati quando ci saranno nuovi aggiornamenti disponibili. È possibili eettuare gli aggiorna-menti tramite i seguenti comandi:

root# apt-get update root# apt-get upgrade

3.3.2 Compilazione da sorgente

Per l'installazione da sorgente, occorre compilare Shibboleth Service Pro-vider 1.3 e alcune librerie. Quindi, occorre installare i tools building necessari e le librerie di sviluppo sulla propria macchina.

Il Shibboleth SP sarà installato in: /opt/shib-sp/shibboleth-sp/ Tramite il seguente comando, viene settato il valore di una variabile: root# export SHIB_HOME=/opt/shib-sp/shibboleth-sp/

Occorre includere le seguenti linee in: /etc/profile: SHIB_HOME=/opt/shib-sp/shibboleth-sp/

export SHIB_HOME

3.3.3 Compilatore Debian C/C++ e Tool Building

Per compilare le librerie richieste e Shibboleth SP 1.3 occorre avere alme-no il compilatore gcc 3.0.

Il compilatore di default della Debian 3.1 è gcc/g++ versione 3.3.5. Questo compilatore è stato utilizzato per compilare tutti i pacchetti Debian, quindi, è altamente raccomandato l'uso di questo compilatore di default.

Occorre usare apt-get per installare gcc, g++: root# apt-get install gcc g++ make

...

Nell'installazione verranno anche installati molti altri pacchetti dovuti alle dipen-denze.

3.3.4 Installazione della libreria OpenSSL

OpenSSL è un'implementazione open source dei protocolli SSL (Secure Socket Layer) e TLS (Transport Layer Security). Le librerie di base (scrit-te in linguaggio C) eseguono le funzioni crittograche principali. Nei diversi linguaggi di programmazione sono disponibili procedure che permettono di accedere alle funzioni della libreria OpenSSL.

La libreria OpenSSL di default di Debian 3.1 è la versione 0.9.7, questa libreria fa fronte alle richieste di Shibboleth SP 1.3. Occorre anche installare dei pacchetti di sviluppo per poter compilare ulteriori librerie richieste.

Occorre usare apt-get per installare i pacchetti di sviluppo libssl 0.9.7 e libssl:

3.3.3.5 Installazione della libreria libcurl 48 root# apt-get install libssl0.9.7 libssl-dev

...

Nell'installazione verranno anche installati molti altri pacchetti dovuti alle dipen-denze.

3.3.5 Installazione della libreria libcurl

cURL è un tool per il trasferimento dei le con sintassi URL, supporta i certicati HTTPS, HTTP POST, HTTP PUT, uploading FTP, kerberos, HTTP form basata su upload, ... . La homepage del progetto è la seguente: http://curl.haxx.se/libcurl

La versione di default di libcurl per Debian 3.1 è la 7.15.1, questa libre-ria fa fronte alle richieste di Shibboleth SP 1.3. Occorre anche installare dei pacchetti di sviluppo per poter compilare ulteriori librerie richieste.

Occorre usare apt-get per installare i pacchetti di sviluppo libcurl 7.15.1 e libcurl

root# apt-get install libcurl3 libcurl3-dev ...

Nell'installazione di questi pacchetti verranno anche installati molti altri pacchetti di dipendenza.

3.3.6 Compilazione e installazione della libreria log4cpp

Log4cpp è una libreria opensource delle classi C++ per il log sui le, syslog, IDSA e altre destinazioni. L'homepage del progetto è:

http://log4cpp.sourceforge.net/

Shibboleth SP 1.3 richiede le librerie speciali log4cpp versione 0.3.5rc1 disponibile per Internet2.

user$ wget http://shibboleth.internet2.edu/downloads/log4cpp-0.3.5rc1.tar.gz ...

user$ tar xvzf log4cpp-0.3.5rc1.tar.gz ...

user$ cd log4cpp-0.3.5rc1

user$ ./configure --prefix=$SHIB_HOME --disable-static --disable-doxygen ...

user$ make ...

user$ make install ...

make install installarà la libreria condivisa in /usr/local/shib-sp. Oc-corre inoltre che si abbiano i diritti di scrittura su questa directory.

3.3.7 Compilazione e installazione di Xerces-C++

Xerces-C++ è un validatore analizzatore XML opensource, scritto in C++. Xerces-C++ rende più semplice la lettura e la scrittura di dati XML da parte delle applicazioni. L'homepage del progetto è:

http://xml.apache.org/xerces-c/

Shibboleth SP 1.3 richiede la speciale libreria Xerces-C++ versione 2.6.1 disponibile su Internet2.

Occorre assicurarsi di aver settato la variabile d'ambiente XERCESROOT. Compilazione e installazione della libreria Xerces-C++:

usr$ wget http://shibboleth.internet2.edu/downloads/xerces-c-src_2_6_1.tar.gz ...

usr$ tar xvzf xerces-c-src_2_6_1.tar.gz ...

usr$ cd xerces-c-src_2_6_1 usr$ export XERCESCROOT='pwd' usr$

3.3.3.8 Compilazione e installazione di XML-Security C++ 50 usr$ ./runConfigure -p linux -c gcc -x g++ -r pthread -P $SHIB_HOME ...

usr$ make ...

usr$ make install ...

La libreria condivisa Xerces-C++ è adesso installata in /usr/local/shib-sp.

3.3.8 Compilazione e installazione di XML-Security C++

La libreria XML Security C++ è una implementazione opensource delle speciche della Firma Digitale XML. L'homepage del progetto è:

http://xml.apache.org/security/.

Shibbolethe Sp 1.3 richiede la versione 1.2.1 della libreria di Sicurezza XML. Occorre inoltre settare come prima la variabile d'ambiente XERCESROOT.

Compilazione e installazione della libreria XML Security C++: user$ export XERCESCROOT=`pwd`/xerces-c-src_2_6_1

user$

user$ wget http://xml.apache.org/dist/security/c-library/ xml-security-c-1.2.1.tar.gz

...

user$ tar xvzf xml-security-c-1.2.1.tar.gz ...

user$ cd xml-security-c-1.2.1/src

user$ ./configure --prefix=$SHIB_HOME --without-xalan ...

user$ make ...

user$ make install ...

3.3.9 Compilazione e installazione di OpenSAML

SAML (Security Assertion Markup Language) è uno standard per la for-mazione e scambio di autenticazione, attributi e dati di autorizzazione su XML. OpenSAML è una libreria opensource che può essere usata per compi-lare e trasportare messaggi parsati SAML 1.0 e 1.1. Permette di memorizzare diversi campi di informazioni del messaggio SAML, compilazione della cor-retta rappresentazione XML, e parsare nuovamente XML dentro i diversi campi, prima di rispedirlo. OpenSAML supporta il SOAP che viene utilizza-to per lo scambio di richieste e risposte SAML. L'homepage del progetutilizza-to è: http://www.opensaml.org/

Shibboleth SP 1.3 richiede la libreria OpenSAML 1.1.a. Compilazione e installazione della libreria OpenSAML:

user$ wget http://shibboleth.internet2.edu/downloads/opensaml-1.1a.tar.gz ...

user$ tar xvzf opensaml-1.1a.tar.gz ...

user$ cd opensaml-1.1

user$ ./configure --prefix=$SHIB_HOME --with-log4cpp=$SHIB_HOME -C ...

user$ make ...

user$ make install ...

La libreria condivisa OpenSAML è adesso installata in /usr/local/shib-sp.

3.3.10 Compilazione e installazione di Shibboleth SP

1.3

Il Shibboleth SP 1.3 è un modulo di Apache caricabile dinamicamente. Quindi, deve essere lincato su di un server Apache e richiede il tool di Apache apxs o di Apache2 apxs2 anche come i le headers di Apache.

3.3.3.10 Compilazione e installazione di Shibboleth SP 1.3 52 Sviluppo dei pacchetti Apache

• Se si ha installato di default il server web Apache 1.3 di Debian, allora occorre installare i pacchetti di sviluppo contenente apxs e i le headers di Apache.

Utilizzare apt-get per installare il pacchetto Apache 1.3: root# apt-get install apache-dev

...

• Se si ha installato il web server Apache 2.0 di Debian, allora occorre installare i pacchetti contenente apxs2 e i le headers di Apache2. Usare apt-get per installare i pacchetti di Apache2:

root# apt-get install apache2-threaded-dev ...

Installando questi pacchetti, verranno installati anche altri pacchetti, do-vuti alle dipendenze.

Shibboleth SP 1.3

Compilare il demone Shibboleth shibd, i moduli di Apache, e le librerie condivise è più o meno come compilare OpenSAML.

Se si ha installati il web server Apache2, allora aggiungere la seguente opzione alla congurazione dello script:

enable-apache-20 with-apxs2=/usr/bin/apxs2.

Compilazione e installazione di Shibboleth Service Provider:

usr$ wget http://shibboleth.internet2.edu/downloads/shibboleth-sp-1.3a.tar.gz ...

usr$ tar xvzf shibboleth-sp-1.3a.tar.gz ...

usr$ cd shibboleth-1.3

usr$ ./configure --prefix=$SHIB_HOME --with-log4cpp=$SHIB_HOME \ [Apache1.3] --enable-apache-13 --with-apxs=/usr/bin/apxs \