Problematiche relative all'introduzione di un sistema di ... · 1 L'outsourcing: si riferisce genericamente alle pratiche adottate dalle imprese di ester-nalizzare alcune fasi del

Università degli Studi di Parma

Facoltà di Scienze Matematiche Fisiche e Naturali

Corso di Laurea in Informatica

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 Al�eri

Dott. Ing. Marco Panella

Anno Accademico 2006/2007

.

.

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 De�nizione 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

2.4.1 Authentication . . . . . . . . . . . . . . . . . . . . . . 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 Certi�cati SSL . . . . . . . . . . . . . . . . . . . . . . 53

3.3.12 Con�gurazione 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.1 Usando i pacchetti di installazione . . . . . . . . . . . . 72

Indice 5

4.2.2 Tool ant di con�gurazione 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 Con�gurazione . . . . . . . . . . . . . . . . . . . . . . . . . . 78

4.3.1 Con�gurazione Shibboleth IdP 1.3 . . . . . . . . . . . . 78

4.3.2 SSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

4.3.3 Con�gurazione di Tomcat 5.5 . . . . . . . . . . . . . . 80

5 Modi�che degli script 82

5.1 Script per l'inserimento di nuovi studenti . . . . . . . . . . . . 82

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

Conclusioni 87

Bibliogra�a 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 con�gurazione IdP: dist.idp.xml 113

F File completo idp.xml 116

G File completo resolver.xml 121

H Esempio di un Attribute Release Policy 124

Elenco delle �gure

2.1 Di�erenza 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 speci�ci sistemi di registrazione co-

stringe l'utente a fornire dati personali in diversi siti e spesso ad utilizzare

credenziali di accesso di�erenti. 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 di�cile e insicuro l'acces-

so a servizi online forniti da soggetti diversi della propria organizzazione di

appartenenza.

Il primo tentativo di fornire una de�nizione 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 identi�carlo�

Dietro questa semplice de�nizione si nasconde in realtà una grande com-

plessità che è legata alla de�nizione 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 con�ni 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 uni�care tra loro sistemi di Identity Management

precedentemente separati.

• l'aumento del ricorso all'outsourcing1 e o�shoring2 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.

1L'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.2L'o�shoring consiste nel trasferimento all'estero di una funzione aziendale, senza che

però venga necessariamente a�data a un'impresa esterna.

Introduzione 9

La �identità digitale federata� è il nuovo paradigma che nasce dall'ac-

cettazione di questi fatti:

• le persone si �spostano� attraverso i con�ni 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 identi�cato 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, sempli�candone 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 e�ettuata 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 con�gurazione 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 certi�cati delle CA valide);

- servizio di supporto tecnico per l'implementazione di un IdP e imple-

mentazione di riferimento open source;

- Certi�cation Authority e il servizio SCS(Service Certi�cate Server);

- GARR-CERT, gestione di eventuali incidenti di sicurezza.

Introduzione 11

I servizi per i quali è stata piani�cata 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 è gestito 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.

3http://nilde.bo.cnr.it/4http://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 speci�che publicate sul sito

http://idem.garr.it. Tramite tale IdP gli utenti locali potranno accede-

re ai servizi che saranno 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 speci�ca 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, in�ne, è

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 a�rontate 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 autorizzazione nelle problematiche di sicurezza avanzate, i modelli

5Esso consiste nella possibilità, per un utente, di accedere a servizi o�erti da più siti

web (su domini distinti) senza dover reiterare la fase di login.

Introduzione 13

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

vello applicativo, ad esempio per realizzare pro�li utente.

Capitolo 1

Progetto IDEM

In questo capitolo si de�nsice 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

con�dential 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 a�erenti all'IDEM sono:

• user provisioning, allocazione e revoca di privilegi, pro�li utente;

• delega di funzioni amministrative o di privilegi e pro�li utente;

• autenticazione;

• controllo di accesso ed autorizzazione;

• formato ed interoperabilità delle identià digitali;

• Single Sign On(SSO);

• servizi di directory ;

1Fonte: [Wikipedia], http://en.wikipedia.org/wiki/Identity_management.

1.1.1.1 Come avvicinarsi all'Identity Management 15

• 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 di�erenza 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 u�ciale di can-

cellarli dalla rete. E gli impiegati devono ricordare talmente tante password

che alla �ne si sentono autorizzati a sceglierne di troppo vulnerabili.

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

e nel trattamento dell'informazione, specie nelle grandi organizzazioni.


Ecco quindi elencati quattro punti importanti che in�uenzano qual-

siasi approccio all'identity management.

Vendere l'approccio

Come spesso accade, il punto principale sta nell'evidenziare i bene�ci

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 a�rontarlo 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 bene�ci 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 di�erenti.

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

3Il 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.4Sarbanes-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.5Decreto Legislativo per il trattamento dei dati personali


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, modi�care e visualizzare i

dati degli utenti; quale particolare evento dà il via libera alla creazione di

un nuovo pro�lo 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 con�gurazioni 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-


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 modi�che 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

6Organization for the Advancement of Structured Information Standards7La missione del progetto Liberty Alliance è quella di stabilire uno standard aperto per

l'identità federata sulla rete attraverso speci�che tecniche.


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 ine�cacia 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 veri�care 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 a�dabile. 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 bene�cio per il cliente �nale, indipendentemente

dalla scelta di sistemi e software adottati in azieda.

8Il cruscotto aziendale, consente di e�ettuare un'autoanalisi aziendale e, inoltre,

contiene una sezione dedicata agli obiettivi strategici dell'azienda.

1.1.1.2 De�nizione di identità digitale 20

1.1.2 De�nizione 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 a�erenti ad un

unico soggetto:

Network identity refers to the global set of attributes that are contained in an

individual's various accounts with di�erent 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 classi�cati in base alla

speci�ca `�loso�a' di gestione del trust:

IDEM isolato. Corrisponde al modello di IDEM attualmente più di�uso. 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 sempli�ca 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 identi�catori utente

gestiti da un'altro insieme (non necessariamente distinto) di providers,

9http://www.projectliberty.org

1.1.1.3 Tassonomia dell'IDEntity Management 21

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 identi�catori 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 identi�care 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'identi�catore 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.

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

Yale Central Authentication Service.

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ù signi�cativo in termini di costi,

tempo e risorse.

La Banca ha perciò avvertito la necessità di conoscere e identi�care 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à�.

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

centralizzato, usando un'unica interfaccia web di amministrazione.

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

ri�ettono 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 certi�cato attestante l'iden-

tità o altre quali�che di un soggetto, è l'elemento informativo centrale nelle

problematiche di Identity Management. Qualsiasi soluzione di Identity Ma-

nagement - per de�nizione - 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 di�u-

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ù di�usa 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

de�nisce 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.

Crittogra�a a chiave asimmetrica. La crittogra�a a chiave simmetri-

ca, conosciuta anche come crittogra�a a coppia di chiavi, crittogra�a

a chiave pubblica/privata o anche sono L'elemento informativo di base

dello standard è il Public Key Certi�cate (PKC), ovvero il documento che

associa il nome di un soggetto alla sua chiave pubblica. I certi�cati sono

emessi e �rmati da una CA (Certi�cate 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 certi�cato emesso e �rmato da una CA di livello superiore

ad eccezione del root che utilizza un certi�cato auto �rmato. Le foglie dell'al-

2.2.1.2 X.509 25

bero sono i soggetti per i quali è stato emesso un certi�cato. 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, veri�cando che ogni

nodo intermedio abbia un certi�cato �rmato dal nodo padre.

In caso di compromissione del soggetto associato ad un certi�cato (può

accadere per esempio che la sua chiave privata venga scoperta), quest'ultimo

può essere revocato pubblicando in una Certi�cate Revocation List (CRL).

Nelle sue ultime evoluzioni, lo standard X.509 speci�ca un altro tipo di

certi�cato: l'AC (Attribute Certi�cate). 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 e�ettuato 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 e�ettuare 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 crittogra�a. Per il SSO di tipo federativo questo

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

Services.2In alcuni contesti si usa anche il termine Circle of Trust.

2.2.2.1 SSO su web 27

è vero a maggior ragione in quanto gli Identity Provider potrebbero

essere gli unici ad avere le informazioni necessarie ad e�ettuare 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 o�erta di servizi in termini di qualità,

quantità e diversi�cazione.

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

stanno aderendo a federazioni Shibboleth.

2.2.2.2 Shibboleth 28

Figura 2.1: Di�erenza 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 speci�ca 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 sempli�care il problema dell'ac-

cesso a contenuti didattici riservati da più campus universitari, ciascuno con


una di�erente 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 di�e-

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 speci�care rapporti di trust bilaterali tra singoli SP ed IdP. Quest'ultimo

4Tipicamente un browser web5Il contenuto informativo delle asserzioni può essere tuttavia di�erenziato in funzione

dell'utente o del SP ricevente.


approccio ha una scalabilità ridotta ma può risultare utile per piccole con-

�gurazioni o per speci�care rapporti di�erenziati 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

identi�cativo 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 identi�ca 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 pro�lo

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 e�ettua 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.


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 pro�lo SAML di SSO (passi

2/3, 4, 5). Questo componente costituisce il primo punto di contatto di un

6Derivata a sua volta da quella di SAML 1.1 e 2.0


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

Artifact Resolution Service. Utilizzato esclusivamente nei casi in cui

si utilizza il pro�lo 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 con�uiscono 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 di�erte a seconda

del pro�lo SAML che si usa. NEl caso del browser/POST estrae direttamente

le asserzioni dalla richiesta HTTP. Nel caso del browser/artifact, invece, deve

7Si tratta del caso più comune.


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 modi�care) 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à

di�uso 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 Pro�le. In Shib-proto9 si standardizza un

8Ricevuti sotto forma di parametri della query string9http://shibboleth.internet2.edu/docs/draft-mace-shibboleth-arch-protocols-10.pdf.


nuovo pro�lo per SAML detto Authentication Request Pro�le. Il suo compito

è quello di estendere i pro�li 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 pro�lo.

In sostanza l'Authentication Request Pro�le speci�ca 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 Pro�le. 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

pro�li siano supportati, gli endpoints forniti, i certi�cati 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 pro�lo per SAML 1.1, detto SAML 1.x Metadata Pro�le11,

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 pubblicano. Tali documenti posso-

no presentarsi anche in forma aggregata, ovvero descrivere tutti i providers

all'interno di una federazione.

10E�ettuata utilizzando il metodo GET11http://www.oasis-open.org/committees/download.php/13254/

sstc-saml1x-metadata-cd-01.pdf.

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

o�re 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 centralizzazione 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

2.2.3.2 Funzionamento 37

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ì de�nito ticket. CAS cerca

di creare un in-memory cookie de�nito 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 veri�ca 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.

Figura 2.6: Schema di funzionamento semplice

2.2.3.3 Schema 38

2.3.3 Schema

Il sistema a�ronta il problema della sicurezza in maniera ottima, infatti,

la password ed il nome utente, circolano solamente nel browser ed il ser-

ver attraverso 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 identi�cativo di sessione; l'applicazione riceve un �tic-

ket opaco� che non contiene informazioni personali. Questo ticket 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

2.2.3.4 Proxy 39

esterna), portali di posta elettronica (a cui un client autenticato richiede la

connessione ad un server IMAP 12 per visionare la propria posta elettronica)

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

Figura 2.8: Schema di funzionamento dettagliato

12Un 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ù a�ermato, 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.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 viene 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'identi�ca-

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 genera una connessione 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'identi�catore della persona e il proxy.

Figura 2.9: Schema di funzionamento CAS-proxy

2.2.4 AAA (Authentication Authorization Accounting) 42

2.4 AAA (Authentication Authorization Accounting)

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ò e�ettivamente utilizzare, dopo

aver eseguito l'accesso.AAA è un framework attraverso il quale noi possiamo

con�gurare 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 e�ettuare 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 identi�cazione degli utenti, attraverso moltepli-

ci modalità: login/password, challenge/response, encryption (a seconda del

protocollo scelto).

L'auntenticazione ci consente di identi�care 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 informazioni13Internet Operating System

2.2.4.3 Accounting 43

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 de�nsice queste azioni.

2.4.3 Accounting

Fornisce il servizio di invio di dati utilizzati per il billing14, l'auditing15,

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.

14Gestione dei costi15Veri�ca del sistema di controllo interno.

Capitolo 3

Installazione Shibboleth Service

Provider

3.1 Introduzione

Questa sezione descrive le speci�che di installazione di un Service Provi-

der Shibboleth 1.3 e con�gurazione per una Federazione 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

Il nome DNS della risorsa (Service Provider).

3.3.2 Prerequisiti 45

3.2 Prerequisiti

Come detto nell'introduzione, questa sezione si riferisce ad una Debian

3.1 (sarge), e contiene alcuni riferimenti a speci�ci 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 certi�cati 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

• Libxerces26-shib: Xerces-C++ è un validatore XML scritto in C++

3.3.3.2 Compilazione da sorgente 46

• libxmlsecurity: È una speci�ca 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 e�ettuare 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/

3.3.3.3 Compilatore Debian C/C++ e Tool Building 47

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 crittogra�che 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 certi�cati 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.

Compilazione e installazione della libreria log4cpp:

3.3.3.7 Compilazione e installazione di Xerces-C++ 49

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$

usr$ cd src/xercesc

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

speci�che 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

...

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

3.3.3.9 Compilazione e installazione di OpenSAML 51

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 progetto è:

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 con�gurazione 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 \

3.3.3.11 Certi�cati SSL 53

[Apache2.0] --enable-apache-20 --with-apxs2=/usr/bin/apxs2 \

--disable-mysql

...

usr$ make

...

usr$ make install

...

Il Shibboleth SP (Demone Shibboleth, modulo Apache, librerie, ...) sono ades-

so completamente installati in /usr/local/shib-sp.

3.3.11 Certi�cati SSL

Questa sezione menziona brevemente i passi necessari per avere un certi-

�cato per il server.

Generazione dei certi�cati

1. Generare una chiave privata nel formato PEM, non codi�cata (default

AES-256):

$ openssl genrsa -out /etc/pki/shibsp.unipr.it.key 1024

2. Creare un CSR (Certi�cate Signing Request):

$ openssl req -new -key /etc/pki/shibsp.unipr.it.key

-out /etc/pki/shibsp.unipr.it.csr

3. Il certi�cato sarà �rmato da Cypertrust Educational CA.

4. Attendere una risposta con il nuovo certi�cato pubblico. Tipicamen-

te occorre attendere un giorno o due. Una volta ricevuto, salvare il

certi�cato in /etc/pki/shibsp.unipr.it.crt

3.3.3.12 Con�gurazione iniziale di Shibboleth SP 1.3 54

3.3.12 Con�gurazione iniziale di Shibboleth SP 1.3

Cartelle Debian

(Nota: è possibile non e�ettuare questi seguenti comandi, se Shibboleth

SP è stato installato con i pacchetti Debian)

In Debian, tutti i �le di con�gurazione del sistema sono memorizzati

nella cartella /etc. Creare un link simbolico semplice alla con�gurazione

di Shibboleth.

root# ln -s /usr/local/shib-sp/etc/shibboleth /etc/shibboleth

La cartella dei log /var/log/shibboleth non esiste ancora e occorre crearla

da se. Si noti che è possibile speci�care la cartella dei log nel �le .logger.

Si è scelto di avere la cartella dei log direttamente in /var/log perché ci

possono essere altre partizioni per i log, e anche collegamenti simili dalla

home di Shibboleth. Il logger di preoccupa di girare i �le di log se necessario.

Solo l'utente root ha i diritti di lettura/scrittura su questa cartella.

root# mkdir /var/log/shibboleth

Poiché il modulo di Apache Shibboleth venga eseguito come l'utente www-data

su Debian, occorre dare i diritti di scrittura a questo utente sulla cartella dei

log. È opportuno scegliere un'altra cartella per questo. Si dovrebbe inoltre

creare questa cartella e impostare i permessi corretti.

root# mkdir /var/log/shibboleth/httpd

root# chown www-data /var/log/shibboleth/httpd

Chiavi e certi�cati

Assicurarsi che i permessi siano correttamente impostati. Solo l'utente che

esegue Apache deve essere in grado di leggere la chiave privata. Altri utenti

non hanno bisogno di accedere ai �le con la chiave, così il corretto settaggio

dei diritti di accesso è impostato in modo sensato.


shibboleth.xml

Scaricare il �le shibboleth.xml

(http://www.federation.org.au/twiki/pub/Federation/ManualInstallSP/shibboleth.xml)

e salvarlo in /etc/shibboleth/shibboleth.xml Questo è il �le di con�gu-

razione principale per il Service Provider.

Editare il �le /etc/shibboleth/shibboleth.xml e con�gurare SP 1.3:

• providerId: questo è un identi�catore univoco della risorsa con la fe-

derazione. Il suo valore dovrebbe essere �stabile�. Non dovrebbe cam-

biare. Per il �default� l'applicazione dovrebbe sceglie l'hostname (anche

se questo non è necessario se Shibboleth è già in esecuzione). Quando

si aggiungono più applicazioni speci�che, si dovrebbe scegliere l'URL

completo per l'applicazione speci�ca.

Settaggio a https://shibsp.unipr.it

Nella Appendice A Ã� possibile trovare il sorgente del �le shibboleth.xml.

AAP.xml

Si può scaricare questo �le di default Attribute Acceptance Policy: AAP.xml

(https://spaces.internet2.edu/display/SHIB/NewSPAttribute) e salvarlo in

/etc/shibboleth/AAP.xml.

Sono le regole attuate da un Fornitore di Servizi per decidere se autoriz-

zare l'accesso di un Utente in base al valore dei suoi Attributi ottenuti dalla

sua Organizzazione di Appartenenza.

Metadata della Federazione

Il Metadata su di un SP descrive tutti gli IdP che possono essere usati per

l'accesso ad una determinata risorsa. Molte volte c'è un nuovo IdP, e occorre

aggiornare il metadata con tutti gli SP inseriti. È possibile scaricare il �le

metadata metadata.xml da (https://www.federation.org.au/level-2/level-2-

metadata.xml), e salvarlo in /etc/shibboleth/metadata.xml.


Con�gurazione dei Logger

È possibile scaricare i �le di con�gurazione dei logger, ovvero: shibboleth.logger,

native.logger e shibd.logger, dal seguente indirizzo:

http://www.switch.ch/aai/docs/shibboleth/SWITCH/1.3/sp/ e salvarli nel-

la cartella /etc/shibboleth.

Il Shibboleth SP manterrà i log nella cartella /var/log/shibboleth. L'u-

ser Apache (tipicamente www-data) dovrà avere i permessi di scrittura su

questa cartella perchè il modulo apache mod_shib scriverà i native.log in

questa cartella.

Script di avvio del Demone Shibboleth

Il demone shibd di Shibboleth SP 1.3 devono essere eseguiti in parallelo

con Apache.

È possibile scaricare il sorgente dello script di shibd da (inserire indirizzo)

e salvarlo nella cartella /etc/init.d.

Il contenuto del �le /etc/init.d/shibd è il seguente:

#! /bin/sh

#

# /etc/init.d/shibd for Debian

#

# start/stop script for Shibboleth ServiceProvider 1.3 daemon

#

# HOWTO INSTALL:

# root:/etc/init.d# update-rc.d shibd defaults

PATH=/bin:/usr/bin:/sbin:/usr/sbin

#

# Shibboleth 1.3

#

SHIB_HOME=/usr/local/shib-sp


SHIB_ETC=$SHIB_HOME/etc/shibboleth

SHIB_CONFIG=$SHIB_ETC/shibboleth.xml

LD_LIBRARY_PATH=$SHIB_HOME/lib

DAEMON=$SHIB_HOME/sbin/shibd

NAME=shibd

DESC="Shibboleth 1.3 Daemon"

test -x $DAEMON || exit 0

set -e

case "$1" in

start)

echo -n "Starting $DESC: $NAME"

start-stop-daemon --start --quiet --pidfile /var/run/$NAME.pid \

--background --make-pidfile \

--exec $DAEMON -- -fc $SHIB_CONFIG

echo "."

;;

stop)

echo -n "Stopping $DESC: $NAME"

start-stop-daemon --stop --quiet --pidfile /var/run/$NAME.pid \

--exec $DAEMON

echo "."

;;

restart)

# Restart

$0 stop

sleep 1

$0 start

;;

configtest)


echo "Check config for $DESC: $NAME"

start-stop-daemon --start \

--exec $DAEMON -- -tc $SHIB_CONFIG

echo "Done."

;;

*)

N=/etc/init.d/$NAME

# echo "Usage: $N {start|stop|restart|reload|force-reload}" >&2

echo "Usage: $N {start|stop|restart|configtest}" >&2

exit 1

;;

esac

exit 0

Usare il tool update-rc.d per registrare lo script /etc/init.d/shibd

nei programmi avviati all'avvio del sistema.

root# update-rc.d shibd defaults 20 95

Adding system startup for /etc/init.d/shibd ...

/etc/rc0.d/K20shibd -> ../init.d/shibd



/etc/rc2.d/S20shibd -> ../init.d/shibd




Il demone di Shibboleth dovrà essere avviato prima di caricare il modulo

del webserver. Se il server non è in esecuzione, il server partirà con successo,

ma a tutte le richieste di Shibboleth verrà visualizzato un errore �no a quando

il demone non sarà avviato. Si può controllare la con�gurazione di

Shibboleth avviando il demone con la seguente modalità:

root# /usr/local/shib-sp/sbin/shibd -t

overall configuration is loadable, check console for non-fatal problems

shibd shutdown complete


È possibile anche eseguire shibd in modalità console:

root# /usr/local/shib-sp/sbin/shibd

loading new logging configuration from /etc/shibboleth/shibd.logger

New logging configuration loaded, check log destination for process status...

(Premere ctrl-c per terminare il processo del demone).

Per ultimo è possibile far partire il demone Shibboleth 1.3 in modalità

background con lo script init:

root# /etc/init.d/shibd start

Starting Shibboleth 1.3 Daemon: shibd.

Con�gurazione di Apache

Il modulo Shibboleth per Apache è un modulo DSO (Data Source Object)

implementato usando apxs. Il modulo prevede delle direttive necessarie per

la con�gurazione principale di Apache. Alcune di queste direttive possono

essere anche usate nei �le .htaccess.

Per far lavorare Shibboleth per il webserver Apache, questo modulo dovrà

essere caricato e con�gurato correttamente.

Script di avvio Apache

Sotto Debian il webserver Apache 1.3 viene fatto partire con lo script

/etc/init.d/apache.

Il webserver Apache SSL-1.3 viene fatto partire con /etc/init.d/apache-ssl.

Apache 2.0 viene fatto partire con /etc/init.d/apache2.

È possibile far partire questi script semplicemente modi�cando come mostra-

to di seguito:

#!/bin/bash

#

# apache Start the apache HTTP server.

#


# The variables below are NOT to be changed. They are there to make the

# script more readable.

NAME=apache

DAEMON=/usr/sbin/$NAME

PIDFILE=/var/run/$NAME.pid

CONF=/etc/$NAME/httpd.conf

APACHECTL=/usr/sbin/${NAME}ctl

# note: SSD is required only at startup of the daemon.

SSD=`which start-stop-daemon`

ENV="env -i LANG=C PATH=/bin:/usr/bin:/usr/local/bin"

SHIB_HOME=/usr/local/shib-sp

LD_LIBRARY_PATH=${SHIB_HOME}/libexec:${SHIB_HOME}/lib

export LD_LIBRARY_PATH

...

Con�gurazione Apache 1.3

Nota: Il pacchetto apache-ssl può usare tutti i moduli che si trovano nella

cartella di installazione di apache. Sarebbe su�ciente creare anche un link simbolico

alla cartella di installazione di apache (e NON nella cartella di installazione di

apache-ssl). Si noti che la con�gurazione di questo pacchetti è localizzata in

/etc/apache/ssl e che lo script di avvio è /etc/init.d/apache-ssl.

• Per prima cosa occorre creare un link simbolico alla cartella

/usr/lib/apache/1.3.

Questo link simbolico sarà necessario per il tool apache-modconf. Que-

sto tool cercherà la directory dei moduli di apache per il giusto modulo

ed il suo descrittore.

root# ln -s /usr/local/shib-sp/libexec/mod_shib_13.so

/usr/lib/apache/1.3/mod_shib_13.so

• Scaricare il descrittore del modulo di Shibboleth 500mod_shib_13.info

(http://www.switch.ch/aai/docs/shibboleth/SWITCH/1.3/sp/500mod_-

shib_13.info) per usarlo con apache-modconf e salvarlo nella directory

/usr/lib/apache/1.3.


Il contenuto del �le /usr/lib/apache/1.3/500mod_shib_13.info è il

seguente:

LoadModule: mod_shib /usr/lib/apache/1.3/mod_shib_13.so

Directives:

ShibConfig

ShibSchemaDir

ShibURLScheme

ShibDisable

ShibApplicationId

ShibBasicHijack

ShibRequireSession

ShibRequireSessionWith

ShibExportAssertion

ShibRequireAll

Description: Shibboleth Daemon for SP 1.3

• Registrare il modulo di Shibboleth mod_shib_13 in Apache 1.3 con il

tool Debian apache-modconf.

root# /usr/sbin/apache-modconf apache enable mod_shib_13

Replacing config file /etc/apache/modules.conf with new version

• Scaricare la con�gurazione del modulo di Shibboleth mod_shib.conf

(http://www.switch.ch/aai/docs/shibboleth/SWITCH/1.3/sp/mod_shib.conf)

e salvarlo nella cartella /etc/apache/conf.d.

Il contenuto del �le /etc/apache/conf.d/mod_shib.conf è il seguen-

te:

##

# Shibboleth SP 1.3

##

# Shibboleth SP 1.3 config

ShibSchemaDir /usr/local/shib-sp/share/xml/shibboleth

ShibConfig /usr/local/shib-sp/etc/shibboleth/shibboleth.xml

<Files *.sso>

SetHandler shib-handler

</Files>


# when using Debian's apache-ssl package the next directive is NECESSARY

# it makes the SAML post use SSL, even when HandlerSSL="false"

# when set HandlerSSL="true" without this directive, apache fails to

# load...

# see Shibboleth-internet2 mailinglist "apache-ssl 1.3.33 debian (Sarge)

# oddity"

ShibURLScheme https

#

# Used for example logo and style sheet in error templates.

#

#

# Alias /shibboleth-sp/main.css /usr/local/shib-sp/doc/shibboleth/main.css

# Alias /shibboleth-sp/logo.jpg /usr/local/shib-sp/doc/shibboleth/logo.jpg

#

<Location /secure>

AuthType shibboleth

ShibRequireSession On

require valid-user

</Location>

Riavviare il webserver Apache 1.3 per applicare i cambiamenti:

root# /etc/init.d/apache restart

Restarting apache.

Con�gurazione di Apache 2.0

Il webserver Apache 2.0 deve essere con�gurato per caricare il modulo di

Shibboleth SP 1.3.

• La con�gurazione del modulo di Shibboleth è inclusa nella distribuzione

di Shibboleth, può anche essere considerata una direttiva di include o

un collegamento a /usr/local/shib-sp/etc/shibboleth/apache2.config..

La con�gurazione deve essere salvata in

/etc/apache/conf.d/mod_shib.conf.


root# cp /usr/local/shib-sp/etc/shibboleth/apache2.config

/etc/apache2/conf.d/mod_shib.conf

Il contenuto del �le /etc/apache2/conf.d/mod_shib.conf è il seguen-

te:

# ADD THIS TO THE END OF YOUR APACHE'S HTTPD.CONF

######

## SHIB Config

######

#

# Load the SHIBBOLETH module

#

LoadModule mod_shib /usr/local/shib-sp/libexec/mod_shib_20.so

#

# Global Configuration

# This is the XML file that contains all the global, non-apache-specific

# configuration. Look at this file for most of your configuration

# parameters.

#

ShibSchemaDir /usr/local/shib-sp/share/xml/shibboleth

ShibConfig /usr/local/shib-sp/etc/shibboleth/shibboleth.xml

#

# Used for example logo and style sheet in error templates.

#

<IfModule mod_alias.c>

Alias /shibboleth-sp/main.css /usr/local/shib-sp/doc/shibboleth/main.css

Alias /shibboleth-sp/logo.jpg /usr/local/shib-sp/doc/shibboleth/logo.jpg

</IfModule>

#

# Configure the module for content

#


# You can now do most of this in shibboleth.xml using the RequestMap

# but you MUST enable AuthType shibboleth for the module to process

# any requests, and there MUST be a require command as well. To

# enable Shibboleth but not specify any session/access requirements

# use "require shibboleth".

#

<Location /secure>

AuthType shibboleth

ShibRequireSession On

require valid-user

</Location>

Riavviare il webserver Apache 2.0 per applicare il cambiamenti:

root# /etc/init.d/apache2 restart

Restarting apache.

Impostazioni del Firewall

• tra�co in entrata:

� webserver: le porta 80 e/o 443 sono usate da alcuni browser-user

• in uscita:

� demone Shibboleth (shibd): deve essere abilitata la connessio-

ne per ogni IdP remoto nella federazione sulla porta 8443 per il

prelevamento degli attributi� NTP (Network Time Protocol): una query da parte di un client è

rivolta ad un server-NTP remoto che gira sulla porta 123.

3.3.4 Installazione tramite sorgente 65

3.4 Installazione tramite sorgente

Al seguente indirizzo: http://shibboleth.internet2.edu/downloads/ è pos-

sibile reperire gli archivi di seguito utilizzati.

3.4.1 Log4cpp

root# wget http://shibboleth.internet2.edu/downloads/log4cpp-0.3.5rc1.tar.gz

root# tar xvzf log4cpp-0.3.5rc1.tar.gz

root# cd log4cpp-0.3.5rc1/

root# ./configure --disable-static --disable-doxygen

--prefix=/opt/shibboleth/shibboleth-sp

root# make

root# make install

...

Questa fase dell'installazione non dovrebbe dare messaggi di errori.

3.4.2 Xerces-C

root# wget http://shibboleth.internet2.edu/downloads/xerces-c-src_2_7_1.tar.gz

root# tar xvzf xerces-c-src_2_7_1.tar.gz

root# cd xerces-c-src_2_7_1/

root# export XERCESCROOT="/opt/shib-sp/xerces-c-src_2_7_1"

root# ./runConfigure -p linux -c gcc -x g++ -r pthread -b 32 -P

/opt/shib-sp/shibboleth-sp

root# make

root# make install

...


3.3.4.3 Xml-Xalan 66

3.4.3 Xml-Xalan

L'installazione di questo pacchetto è opzionale.

root# wget http://shibboleth.internet2.edu/downloads/Xalan-C_current-src.tar.gz

root# tar xvzf Xalan-C_current-src.tar.gz

root# cd xml-xalan/

root# export XALANCROOT="/opt/shib-sp/xml-xalan/c"

root# ./runConfigure -p linux -c gcc -x g++ -P /opt/shib-sp/shibboleth-sp/

root# make

root# make install

...


3.4.4 Xml-Security-C

root# wget http://shibboleth.internet2.edu/downloads/xml-security-c-1.3.1.tar.gz

root# tar xvzf xml-security-c-1.3.1.tar.gz

root# cd xml-security-c-1.3.1/

root# ./configure --without-xalan --prefix=/opt/shib-sp

oppure

root# ./configure --with-xalan --prefix=/opt/shib-sp

Provando a compilare la versione 1_3_1 si potrebbero riscontrare i se-

guenti errori, utilizzando sia �without-xalan sia �with-xalan:

../src/canon/XSECC14n20010315.cpp: In member function --int

XSECC14n20010315::XPathSelectNodes(const char*)--:

../src/canon/XSECC14n20010315.cpp:500: error: no matching function for

call to

--xalanc_1_10::XPathEvaluator::selectNodeList(xalanc_1_10::XercesDOMSupport&,

xalanc_1_10::XalanNode* const&, const xalanc_1_10::XalanDOMChar*&,

xalanc_1_10::XalanElement*&)--

/opt/shib-sp/shibboleth-sp//include/xalanc/XPath/XPathEvaluator.hpp:177:

note: candidates are: xalanc_1_10::NodeRefList&

3.3.4.4 Xml-Security-C 67

xalanc_1_10::XPathEvaluator::selectNodeList(xalanc_1_10::NodeRefList&,

xalanc_1_10::DOMSupport&, xalanc_1_10::XalanNode*, const

xalanc_1_10::XalanDOMChar*, const xalanc_1_10::XalanElement*)


note: xalanc_1_10::NodeRefList&



xalanc_1_10::XalanDOMChar*, const xalanc_1_10::PrefixResolver&)





xalanc_1_10::XPath&, const xalanc_1_10::XalanElement*)





xalanc_1_10::XPath&, const xalanc_1_10::PrefixResolver&)

Oppure utilizzando si potrebbe ottenere un altro tipo di errore:

../../include/xsec/canon/XSECC14n20010315.hpp:127: error: extra

qualification --XSECC14n20010315::-- on member --init--

make[1]: *** [../../lib/obj/XSECC14n20010315.o] Error 1

make[1]: Leaving directory `/opt/shib-sp/xml-security-c-1.3.0/src/canon'

make: *** [compile] Error 2

Questo errore è dovuto al g++ 4.1 come viene illustrato al seguente link:

http://mail.kde.org/pipermail/kexi-devel/2006-March/000060.html , perchè

nei prototipi delle funzioni in alcuni �le .hpp si ripete il nome della classe

e quindi basta togliere il nome della classe da quei �le e tutto si compila

correttamente.

root# make

root# make install

3.3.4.5 CxxTest 68

3.4.5 CxxTest

L'installazione di questo pacchetto è opzionale.

root# wget http://shibboleth.internet2.edu/downloads/cxxtest-3.10.1.tar.gz

root# tar xvzf cxxtest-3.10.1.tar.gz

root# cd cxxtest-3.10.1/

root# ./runConfigure

root# make

root# make install

...


3.4.6 OpenSAML

root# wget http://shibboleth.internet2.edu/downloads/opensaml-1.1b.tar.gz

root# tar xvzf opensaml-1.1b.tar.gz

root# cd opensaml-1.1/

root# ./configure --with-log4cpp=/opt/shib-sp/shibboleth-sp

--prefix=/opt/shib-sp/shibboleth-sp -C --with-cxxtest=/opt/shib-sp/cxxtest

root# make

root# make install

...

Occorre adesso installare apache-devel, ovvero il pacchetto che contiene

i sorgenti di Apache.

3.4.7 APR 0.9.13

root# wget http://shibboleth.internet2.edu/downloads/apr-0.9.13.tar.gz

root# tar xvzf apr-0.9.13.tar.gz

root# cd apr-0.9.13/

root# ./configure --prefix=/opt/shib-sp/shibboleth-sp -C

--with-apr=/opt/shib-sp/shibboleth-sp

root# make

root# make install

...

3.3.4.8 APR-Util 0.9.13 69

3.4.8 APR-Util 0.9.13

root# wget http://shibboleth.internet2.edu/downloads/apr-util0.9.13.tar.gz

root# tar xvzf apr-util-0.9.13.tar.gz

root# cd apr-util-0.9.13/

root# ./configure --prefix=/opt/shib-sp/shibboleth-sp -C

--with-apr=/opt/shib-sp/shibboleth-sp

root# make

root# make install

...

3.4.9 Shibboleth-SP

root# wget http://shibboleth.internet2.edu/downloads/shibboleth-sp-1.3f.tar.gz

root# tar xvzf shibboleth-sp-1.3f.tar.gz

root# cd shibboleth-sp-1.3/

root# ./configure --with-saml=/opt/shib-sp/shibboleth-sp

--with-log4cpp=/opt/shib-sp/shibboleth-sp --enable-apache-20

--with-apxs2=/usr/sbin/apxs2 --prefix=/opt/shib-sp/shibboleth-sp -C

...

Problema: configure: error: Unable to locate apr-config, may need

�with-apr option

Il �le apr-config non si trova in alcuna directory. È un progetto Apache.

Ci sono varie versioni, anche per quanto riguarda Shibboleth si può usare

apr-config oppure apt-1-config. Questo si riferisce al fatto di usare una

versione 0.x oppure 1.y: in particolare le ultime versioni disponibili sono la

0.9.13 e la 1.2.8.

Utilizzando la seguente linea di codice per la compilazione, funziona:

root# ./configure --with-saml=/opt/shibboleth/shibboleth-sp

--with-log4cpp=/opt/shibboleth/shibboleth-sp --enable-apache-22

--with-apxs22=/usr/sbin/apxs2 --with-apr=/opt/shibboleth/shibboleth-sp/

--prefix=/opt/shibboleth/shibboleth-sp -C

...

Eseguendo adesso l'istruzione di make viene visualizzato il seguente mes-

saggio di errore:

3.3.4.9 Shibboleth-SP 70

In file included from /usr/include/apache2/httpd.h:43,

from mod_apache.cpp:39,

from mod_shib_22.cpp:57:

/usr/include/apache2/ap_config.h:26:23: error: apr_hooks.h: No such file

or directory

/usr/include/apache2/ap_config.h:27:32: error: apr_optional_hooks.h: No

such file or directory

In file included from mod_apache.cpp:39,


/usr/include/apache2/httpd.h:54:25: error: apr_buckets.h: No such file

or directory

/usr/include/apache2/httpd.h:723:21: error: apr_uri.h: No such file or

directory

In file included from mod_apache.cpp:42,


/usr/include/apache2/http_main.h:29:26: error: apr_optional.h: No such

file or directory

Per risolvere questo errore occorre creare dei symlink (link simbolici) in

/opt/shib-sp/sibboleth-sp/include verso i �le non trovati. I link simbo-

lici saranno nella seguente forma:

ln -s apr-0/'nome libreria non trovata'

Capitolo 4

Installazione Shibboleth Identity

Provider

Questa sezione descrive la procedura di installazione per un Shibboleth

Identity Provider 1.3.

4.1 Prerequisiti

Di seguito sono elencati i pacchetti che saranno necessari per questa

installazione e dove possono essere reperibili:

• jdk (1.5.0) http://java.sun.com/j2se/1.5.0/download.jsp

• Apache Tomcat (5.5) http://tomcat.apache.org/download-55.cgi

• Apache commons-logging (1.0)

http://jakarta.apache.org/site/downloads/downloads_commons-logging.cgi

• log4j (1.2) http://logging.apache.org/site/binindex.cgi

• Apache ant (1.6) http://ant.apache.org/bindownload.cgi

• JA-SIG CAS3 server (3.0) http://www.ja-sig.org/products/cas/downloads/

• Yale CAS client Java �lter (2.1) http://www.ja-sig.org/products/cas/downloads/

• Shibboleth IdP (1.3) http://shibboleth.internet2.edu/downloads/

NTP

I server che avviano Shibboleth devono avere il proprio orologio di sistema

sincronizzato. I messaggi tra i componenti hanno infatti un tempo di

vita limitato per motivi di sicurezza.

4.4.2 Installazione 72

4.2 Installazione

4.2.1 Usando i pacchetti di installazione

Questa sezione contiene le istruzioni per installare manualmente tutti i

componenti. Questa sezione contiene inoltre indicazioni sulla disposizione dei

�le sul disco locale.

Estrarre il pacchetto scaricato in /usr/src/shibboleth (Questo percorso

nel documento sarà chiamato $INSTALLER_HOME). Dopo questo è possibile

avviare lo script shell install. Questo script con�gurerà l'ambiente e avvierà

la compilazione per l'installazione di tutti i componenti. Viene assunto di

avere un JDK installato in /usr/local/java.

$ mkdir /usr/src/shibboleth

$ cd /usr/src/shibboleth

$ wget https://shib.kuleuven.be/download/idp/1.3/shibboleth-idp13c-cas304-xx.zip

$ unzip shibboleth-idp13c-cas304-xxxxxx.zip

$ chmod +x install

$ ./install

4.2.2 Tool ant di con�gurazione Apache

Ant è un tool di compilazione che è rilasciato dalla Apache Software Foun-

dation. Gestisce vari generi di task di installazione. Alcuni dei componenti

che verranno installati richiederanno questo tool per l'installazione.

Scaricare il �le binario di Ant da http://ant.apache.org/bindownload.cgi.

• Estrarre in /usr/local/ant/

• Impostare la variabile d'ambiente ANT_HOME con /usr/local/ant.

$ export ANT_HOME=/usr/local/ant

• Adesso è possibile aggiungerla alla variabile del percorso.

$ export PATH=$PATH:$ANT_HOME/bin

4.4.2.3 Piattaforma Java 2, Standard Edition (J2SE) 73

4.2.3 Piattaforma Java 2, Standard Edition (J2SE)

La piattaforma Java fornisce una Virtual Machine (VM) che è in grado

di interpretare programmi compilati in �bytecode� di Java. Poichè si può

installare la VM su qualsiasi piattaforma, allora è possibile avviare il bytecode

binario su qualsiasi piattaforma.

Dal momento che tutte le componenti sono basate su Java (JSP/Servlets),

è necessaria una Java VM e un servlets container (es. Tomcat) per eseguire

il codice. Per questo tipo di installazione è inoltre necessario un compilatore

per il codice di molti componenti (a partire dalla versione 5.5.0 di Tomcat

non ha bisogno di eseguire un JDK(Java Development Kit) perché include un

compilatore eclipse JDT per Jasper). Il pacchetto che contiene tutti questi

tool JAVA è chiamato �Java SDK� (Software Development ToolKit).

1. Scaricare J2SE Development Kit (JDK) 1.5 per linux da

http://java.sun.com/ (es: jdk-1_5_0_<versione>-linux-i586.bin).

Il JDK è un insieme di programmi che consente di far girare applicazioni

scritte nel linguaggio Java. I programmi più importanti sono il compi-

latore Java (programma javac )che traduce il sorgente Java in codi-

ce eseguibile dalla macchina virtuale Java, e l'esecutore (programma

java), che implementa la vera e propria macchina virtuale.

2. Installare Java 1.5 nella directory /usr/local ed impostare i link sim-

bolici appropriati e le variabili d'ambiente.

$ cd /usr/local

$ chmod +x jdk-1_5_0_<version>-linux-i586.bin

$ ./jdk-1_5_0_<version>-linux-i586.bin

$ ln -s /usr/local/jdk1.5.0_<version> /usr/local/java

$ export JAVA_HOME=/usr/local/java

Occorre anche includere le seguenti linee in /etc/profile:

JAVA_HOME=/usr/local/java

export JAVA_HOME

4.4.2.4 Container Tomcat 5.5 JSP/Servlt 74

4.2.4 Container Tomcat 5.5 JSP/Servlt

I Servlets e il linguaggio JSP si posizionano nelle applicazioni sulla rete.

Tuttavia questi �programmi� non possono funzionare da soli, necessitano di

un container Servlet che li gestisca e che gestisca le loro richieste. Tomcat è

l'implementazione di riferimento per un �Servlet Container�. È un progetto

di Apache Software Fountation (Jakarta project)

1. Prelevare Tomcat 5.5 da http://tomcat.apache.org/download-55.cgi nel-

l'ultima versione stabile. Non usare le release alpha e beta.

2. Installare Tomcat 5.5 nella directory /usr/local ed impostare i link

simboli appropriati e le variabili d'ambiente.

$ cd /usr/local

$ tar xzf apache-tomcat-5.5.<version>.tar.gz

$ ln -s /usr/local/apache-tomcat-5.5.<version> /usr/local/tomcat

$ ln -s /usr/local/apache-tomcat-5.5.<version>/logs /var/log/tomcat

$ ln -s /usr/local/apache-tomcat-5.5.<version>/conf /etc/tomcat

$ export CATALINA_HOME=/usr/local/tomcat

Aggiungere uno script di avvio per Tomcat 5.5 in: /etc/init.d/tomcat.

È possibile reperire il sorgente dello script, nell'Appendice B.

Aggiungere questo script al default runlevel:

$ update-rc.d tomcat defaults

E avviare Tomcat come segue:

$ /etc/init.d/tomcat start

3. Considerare la possibilità di rimuovere tutte le applicazioni web non

necessarie da $CATALINA_HOME/webapps

0Il gestore delle applicazioni è installato, ma di default non è l'utente pre-

de�nito che può accedervi (leggere il seguente HowTo per maggiori informazioni:

http://tomcat.apache.org/tomcat-5.5-doc/manager-howto.html).

4.4.2.5 Registrazione dei log con log4j 75

Se si lascia avviato Tomcat, si può testare l'installazione richiedendo la pagina

index http://localhost:8080/ (Tomcat è in ascolto sulla porta 8080 di default,

è possibile cambiarla quando si installa SSL per Tomcat, per adesso assumia-

mo di prendere in ascolto l'8080 senza SSL). Nella pagina dovrebbe esserci

scritto quanto segue: �you've setup Tomcat successfully!�. Se non è così, con-

trollare i log di Tomcat ($CATALINA_HOME/logs/catalina.YYYY-MM-DD.log)

o se è già installato log4j ($CATALINA_HOME/logs/tomcat.log).

4.2.5 Registrazione dei log con log4j

I Log forniscono una vista di cosa sta accadendo all'interno di un pro-

gramma. Questo è estremamente importante quando si utilizza Shibboleth

o qualsiasi altro software. Questo sfortunatamente causa anche molto ove-

rhead. Ecco perchè log4j prova a minimizzare l'overhead e a massimizzare

la �essibilità. Log4j è un framework per la registrazione dei log. Per varie

ragioni è consigliato di utilizzare log4j. Occorre anche un �commons-logging�:

che è una sorta di colla tra il codice interno di Tomcat e log4j (o qualsiasi

altra implementazione di commons-logging).

È possibile trovare altre informazioni ai seguenti link:

http://jakarta.apache.org/commons/logging/ e

http://logging.apache.org/log4j/docs/index.html.

IMPORTANTE: Non bisognerebbe installare log4j sia nel servlet

container che in una speci�ca web application. È consigliato l'instal-

lazione e con�gurazione di log4j in un servlet container. Ciò signi�ca la ne-

cessità di RIMUOVERE la libreria log4j da qualsiasi web application che la

include.

1. Prelevare il pacchetto binario commons-loggin-1.0.x da

http://jakarta.apache.org/site/downloads/downloads_commons-logging.cgi

ed estrarlo. Copiare commons-logging-1.0.x/commons-logging.jar

in $CATALINA_HOME/common/lib/

2. Prelevare il pacchetto di log4j da http://logging.apache.org/site/binindex.cgi

ed estrarlo.

4.4.2.6 Shibboleth IdP 1.3 e Java CAS Client 76

Copiare logging-log4j-1.2.xx/dist/lib/log4j-1.2.xx.jar in

$CATALINA_HOME/common/lib/.

3. Creare un �le log4j.properties in $CATALINA_HOME/common/classes/

Aggiungere il sorgente presente nella Appendice C, in log4j.properties.

4. Riavviare Tomcat 5.5 e abilitare il registratore di log log4j.

$ /etc/init.d/tomcat restart

Dopo aver riavviato Tomcat ci sarà un nuovo �le $CATALINA_HOME/logs/tomcat.log

che contiene tutte le informazioni di log di Tomcat del Servlets container da

questo punto in avanti. Si noti che questa con�gurazione di log4j è de�nita

per 2 altri log�le: per un IdP e per il sistema CAS.

4.2.6 Shibboleth IdP 1.3 e Java CAS Client

Ci sono due approcci per includere il CAS client in Shibboleth. Il primo è

di includere la libreria jar precompilata di casclient in Shibboleth, il secondo

approccio è quello di includere l'intero progetto CAS Java client come una

estensione di Shibboleth. Quando si include la risorsa come una estensione

dovrà essere (ri)compilata insieme al sorgete di Shibboleth.

1. Creare una nuova cartella nella directory custom del pacchetto di in-

stallazione di Shibboleth, es:

$SHIB-IDP_SOURCE/custom/cas-client-java-2.1.1

2. Copiare tutto il contenuto dalla cartella root di CAS client nella nuova

directory di Shibboleth (includendo tutte le sottodirectory):

$CASCLIENT_SOURCE/*=> $SHIB-IDP_SOURCE/custom/cas-client-java-2.1.1/

3. Creare un nuovo �le

$SHIB-IDP_SOURCE/custom/cas-client-java-2.1.1/build.properties

che include il CAS client nel processo di compilazione di Shibboleth,

questo �le dovrà contenere:

0nota: Se si vuole includere la libreria casclient.jar come libreria precompilata, allora

occorre editare $SHIB-IDP_SOURCE/conf/idp-lib.include come il jar che dovrà essere

incluso nella compilazione dell'IdP.

4.4.2.6 Shibboleth IdP 1.3 e Java CAS Client 77

ext.name=casclient

gen.ext.docs=false

4. Editare il �le $SHIB-IDP_SOURCE/webAppConfig/dist.idp.xml così

da usare come �ltro CAS client per il SSO servlet. Questo �le ne-

cessita il proprio hostname come parametro di con�gurazione. Nell'e-

sempio di sotto occorre solo cambiare $CASHOSTNAME e $IDPHOSTNAME.

($IDPHOSTNAME è rimpiazzato da Shibboleth nel processo di compila-

zione). Nella maggior parte delle installazioni l'hostname per il server

CAS dovrebbe essere lo stesso per il Shibboleth IdP. È possibile trovare

il �le sorgente dell'IdP nell'Appendice D.

Compilazione e installazione di Shibboleth IdP

1. Come spiegato nell'installazione del log4j, non bisogna avere una li-

breria log4j per una web application speci�ca in modo da dover ri-

muovere la libreria log4j dall'IdP. Per questa ragione bisogna edita-

re $SHIB-IDP_SOURCE/conf/idp-lib.include: per rimuovere le linee

dove compare log4j-1.2.5.jar

2. Si potrebbe installare una pagina speciale all'interno di Shibboleth che

distrugga la sessione locale e reindirizzi CAS al termine dell'attività

dell'utente all'interno di un sistema AAI/SSO. Gli IdP dovrebbero in-

formare l'SP della posizione di questa pagina in modo da poter mettere

un link sul bottone di logout per l'user corrente.

3. Le librerie di Shibboleth si appoggeranno sulle librerie di Java. Copiare

i �le jar nella cartella di appoggio del pacchetto estratto ($SHIB-IDP_-

SOURCE/endorsed/) in $CATALINA_HOME/common/lib/

Altre estensioni del �le .jar in $CATALINA_HOME/common/lib/ potreb-

bero andare in con�itto con i nuovi, in rare occasioni. Rimuovere i

vecchi �le .jar in questo caso.

4. Modi�care il contatto E-Mail per il supporto in

$SHIB-IDP_SOURCE/webApplication/IdPError.jsp

4.4.3 Con�gurazione 78

4.3 Con�gurazione

4.3.1 Con�gurazione Shibboleth IdP 1.3

1. La principale con�gurazione dell'Identity Provider è localizzata in

$IDP_HOME/etc/idp.xml. È possibile trovare il sorgente dell' IdP nel-

l'appendice E.

2. Con�gurare i propri attributi nel �le sorgente $IDP_HOME/etc/resolver.xml.

L'esempio mostra una con�gurazione limitata del resolver per un repo-

sitory LDAP. È possibile trovare il sorgente del resolver nell'appendice

F.

3. Si è determinato che per ciascun attributo viene rilasciato con uno spe-

ci�co target. Si può fare modi�cando il �le $IDP_HOME/etc/arps/arp.site.xml.

Questo �le dipende dal backend e dovrebbe quindi essere ottimizzato

per combaciare con il proprio resolver.xml.

È possibile trovare esempio di un Attribute Release Policy nell'appen-

dice G.

4.3.2 SSL

Il Shibboleth Identity Provider, CAS e Tomcat si preoccupano di usare

una Public Key Infrastructure. Di conseguenza abbiamo bisogno di una cer-

ti�cato pubblico e di una chiave privata. I seguenti passi potrebbero essere

di aiuto:

• generare una nuova chiave privata

• creare un CSR di corrispondenza in modo da poter chiedere un certi�-

cato �rmato da un CA di �ducia.

Generazione di una nuova coppia chiave/certi�cato

Verrà usato il keytool per generare un keystore nel formato JKS. Quel

programma e quel formato sono stati scelti perché keytool è incluso con

il JDK. Si noti che il connettore APR per Tomcat NON è supportato dal

formato JKS.

4.4.3.2 SSL 79

1. Controllare che keytool sia nel percorso giusto, il programma è loca-

lizzato in $JAVA_HOME/bin/.

2. Creare un chiave privata per l'Identity Provider, in un JKS keystore.

$ keytool -genkey -v -keyalg RSA -alias "tomcat"

-keystore idp.jks -storepass "secret" -validity 365

What is your first and last name?

[Unknown]: idp.example.it

What is the name of your organizational unit?

[Unknown]: GARR

What is the name of your organization?

[Unknown]: UNIPR

What is the name of your City or Locality?

[Unknown]: PARMA

What is the name of your State or Province?

[Unknown]: PARMA

What is the two-letter country code for this unit?

[Unknown]: IT

Is CN=idp.example.it, OU=GARR, O=UNIPR, L=PARMA, ST=PARMA, C=IT?

[no]: yes

Generating 1.024 bit RSA key pair and self-signed certificate (MD5WithRSA)

for: CN=idp.example.it, OU=GARR, O=UNIPR, L=PARMA, ST=PARMA, C=IT?

Enter key password for

(RETURN if same as keystore password):

[Storing idp.jks]

3. Creare un Certi�cate Signing Request per la nuova chiave privata:

$ keytool -certreq -v -alias "tomcat"

-keystore idp.jks -storepass "secret" -file idp.csr

4. Per la messa in produzione di questo certi�cato occorre che sia �rmato

da un Certi�cation Authority u�ciale.

Visitare il seguente link

https://www.globalsign.net/digital_certi�cate/serversign/ e inviare il

4.4.3.3 Con�gurazione di Tomcat 5.5 80

�le idp.csr che combacia con la propria chiave privata.

In seguito (questo potrebbe richiedere un paio di giorni) GlobalSi-

gn invierà un certi�cato �rmato che potrà essere usato dall'Identity

Provider.

4.3.3 Con�gurazione di Tomcat 5.5

Con�gurazione di HTTP per Tomcat in $CATALINA_HOME/conf/server.xml

• una che supporta SSL senza autenticazione del client

• una che supporta SSL con autenticazione del client

È più semplice utilizzare la stessa coppia chiave/certi�cato per entrambi, e

non c'è motivo per non farlo.



<Connector port="443" maxHttpHeaderSize="8192" maxThreads="150"

minSpareThreads="25" maxSpareThreads="75"

enableLookups="false" disableUploadTimeout="true"

acceptCount="100" scheme="https" secure="true"

clientAuth="false" sslProtocol="TLS"

keystoreType="jks"

keystoreFile="/etc/pki/idp.jks"

keystorePass="secret" />



<Connector port="8443" maxHttpHeaderSize="8192" maxThreads="150"

minSpareThreads="25" maxSpareThreads="75" enableLookups="false"

disableUploadTimeout="true"

acceptCount="100" scheme="https" secure="true" clientAuth="true"

sslProtocol="TLS"

keystoreType="jks"

keystoreFile="/etc/pki/idp.jks"

keystorePass="secret" />

4.4.3.3 Con�gurazione di Tomcat 5.5 81



Riavviare Tomcat 5.5 e caricare la nuova con�gurazione.

$ /etc/init.d/tomcat restart

Impostazioni del Firewall

• tra�co in entrata:

� webserver: è utilizzata la porta 443 per molti browser-user sia per

IdP sia per il CAS.� ogni SP di Shibboleth deve collegarsi all'IdP sulla porta 8443

• in uscita:

� server CAS connette il proprio backend di autenticazione (es LDAP

sulla porta 389 o LDAPS sulla porta 636)� IdP connette i propri repository degli attributi per prelevare gli

attributi (es LDAP sulla porta 389 o LDAPS sulla porta 636)� NTP: le interrogazioni da un client è rivolta su di un NTP-server

remoto che è stato avviato sulla porta 123.

Capitolo 5

Modi�che degli script

In questo capitolo verranno illustrate le modi�che apportate ad alcu-

ni script perl1, utilizzati per mantenere aggiornati il database degli utenti

dell'Università degli Studi di Parma.

5.1 Script per l'inserimento di nuovi studenti

Il seguente script PERL serve per caricare da �le gli eventuali nuovi stu-

denti. Lo script carica da �le di testo le credenziali di un determinato utente,

controlla che i campi siano corretti e stampa a video gli attributi necessari

per il riconoscimento del nuovo schema EduPerson.

#!/usr/bin/perl

@attributeName = ('sn','givenName','matricola','facolta','corsolaurea','anno',

'datafine','annocorso','tipo','codcomune','provincia','cittadinanza','stato',

'mail','userPasswordOrig','codiceFiscale','cn','uid','uidNumber',

'shadowLastChange','ou','postalAddress','localityName','postalCode',

'luogoNascita','dataNascita','codcomnascita','annoPrimaImm');

($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) = localtime (time);

1Perl è un linguaggio di programmazione ad alto livello, dinamico, procedurale e in-

terpretato, creato nel 1987 da Larry Wall. Perl ha un singolare insieme di funzionalità

ereditate da C, scripting shell Unix (sh), awk, sed e in diversa misura da molti altri

linguaggi di programmazione, compresi alcuni linguaggi funzionali.

5.5.1 Script per l'inserimento di nuovi studenti 83

@Mesi3 = ("gen","feb","mar","apr","mag","giu","lug","ago","set","ott",

"nov","dic");

$date = $mday + 0;

$year = 1900 + $year;

$data = $date." ".$Mesi3[$mon]." ".$year;

open (FILE,'NUOVI_2.txt');

while ($line = readline(*FILE)) {

@attributevalues=split(/:/,$line);

print STDERR "".$attributevalues[16]."\n";

if (length ($attributevalues[12]) == 0) {

$attributevalues[12]='--';

}

$attributevalues[19] += 360;

print "dn:cn=".$attributevalues[16].",ou=Studenti,ou=People,dc=unipr,dc=it\n";

print "objectclass: sambaSAMAccount\n";

print "objectclass: posixAccount\n";

print "objectclass: shadowAccount\n";

print "objectclass: studenteUniPR\n";

print "objectClass: eduPerson\n";

print "o: Universita degli Studi di Parma\n";

print "homeDirectory: /home/studenti/".$attributevalues[17]."\n";

print "categoria: studente\n";

print "uPortalDefLayout: s\n";

print "description: creazione (".$data.")\n";

print "gidNumber: 100\n";

print "shadowMin: 0\n";

print "shadowMax: 360\n";

print "shadowWarning: 30\n";

print "shadowExpire: 14000\n";

print "gecos: ".$attributevalues[1]." ".$attributevalues[0]."\n";

print "displayName: ".$attributevalues[1]." ".$attributevalues[0]."\n";

5.5.1 Script per l'inserimento di nuovi studenti 84

print "loginShell: /bin/bash\n";

print "sambaSID: boh\n";

print "sambaNTPassword: ";

system ("/usr/sbin/mkntpwd -N ".$attributevalues[14]);

print "sambaLMPassword: ";

system ("/usr/sbin/mkntpwd -L ".$attributevalues[14]);

$attributevalues[14]="{crypt}".crypt($attributevalues[14],

substr($attributevalues[2],4,2));

print "sambaPwdLastSet: ";

system ("date +'%s'");

print "sambaLogonTime: 0\n";

print "sambaLogoffTime: 2147483647\n";

print "sambaKickoffTime: 2147483647\n";

print "sambaPwdCanChange: 1000000000\n";

print "sambaPwdMustChange: 2147483647\n";

print "sambaAcctFlags: [U]\n";

print "c: Italy\n";

for ($i = 0; $i < 27; $i++) {

if (length($attributevalues[$i])>0) {

print $attributeName[$i].": ".$attributevalues[$i]."\n";

}

}

print "userPassword: ".$attributevalues[14]."\n";

print "eduPersonOrgDN: o=Universita degli Studi di Parma, dc=unipr, dc=it\n";

print "eduPersonOrgUnitDN: ou=".@attributevalues[20].",

o=Universita degli Studi di Parma,dc=unipr,dc=it\n";

print "eduPersonScopedAffiliation: student\@unipr.it\n";

print "eduPersonScopedAffiliation: member\@unipr.it\n";

print "eduPersonScopedPrimaryAffiliation: student\n";

print "eduPersonNickname: ".@attributevalues[1]."\n";

print "eduPersonPrincipalName: ".@attributevalues[13]."\n";

print "annoPrimaImm: ".$attributevalues[27]."\n";

print "\n";

}

close (FILE);

5.5.2 Script per l'aggiornamento degli attributi 85

5.2 Script per l'aggiornamento degli attributi

Il seguente script PERL serve invece per aggiornare gli attributi di uno

studente. Ad esempio, per la convezione adottata nell'EduPerson schema,

uno studente che non risulta essere ancora laureato alla laurea triennale ri-

sulta essere student e member, altrimenti risulta essere alumn e member. È

possibile e�ettuare questo controllo grazie all'attributo data�ne, il quale se

risulta essere vuoto allora lo studente deve ancora laurearsi, altrimenti è già

laureato.

#!/usr/bin/perl

@attributeName = ('sn','givenName','matricola','facolta','corsolaurea','anno',

'datafine','annocorso','tipo','codcomune','provincia','cittadinanza','stato',

'mail','userPasswordOrig','codiceFiscale','cn','uid','uidNumber',

'shadowLastChange','ou','postalAddress','localityName','postalCode',

'luogoNascita','dataNascita','codcomnascita','annoPrimaImm');

($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) = localtime (time);

@Mesi3=("gen","feb","mar","apr","mag","giu","lug","ago","set","ott","nov","dic");

$date = $mday + 0;

$year = 1900 + $year;

$data = $date." ".$Mesi3[$mon]." ".$year;

open (FILE,'AGGIORNATI_2.txt');

while ($line = readline(*FILE)) {

@attributevalues=split(/:/,$line);

print "dn: cn=".$attributevalues[16].",ou=Studenti,ou=People,dc=unipr,dc=it\n";

print "description: modifica (".$data.")\n";

for ($i = 2; $i < 13; $i++) {




}

}

#

if (length($attributevalues[15])>0) {

print $attributeName[15].": ".$attributevalues[15]."\n";

}

#

for ($i = 20; $i < 27; $i++) {



}

}

print "eduPersonOrgDN: o=Universita degli Studi di Parma, dc=unipr, dc=it\n";

print "eduPersonOrgUnitDN: ou=".@attributevalues[20].",

o=Universita degli Studi di Parma,dc=unipr,dc=it\n";

if(length($attributevalues[6] > 0 )){

print "eduPersonScopedAffiliation: alumn\@unipr.it\n";


print "eduPersonScopedPrimaryAffiliation: alumn\n";

}

else {

print "eduPersonScopedAffiliation: student\@unipr.it\n";


print "eduPersonScopedPrimaryAffiliation: student\n";

}

print "eduPersonNickname: ".@attributevalues[1]."\n";

print "eduPersonPrincipalName: ".@attributevalues[13]."\n";

print $attributeName[27].": ".$attributevalues[27]."\n";

print "\n";

}

close (FILE);

Conclusioni

Risultati raggiunti

In questa tesi sono stati analizzati alcuni dei più importanti requisiti

(Capitolo 1) dell'Identity Management ai quali si è cercato di dare soluzione

utilizzando le teconologie e gli standard attualmente sul mercato (Capitolo

2). Tale soluzione è costituita da un disegno architetturale generale, che per-

mette di integrare le varie tecnologie scelte, e dall'implementazione (capitolo

3 e capitolo 4) di alcune delle funzionalità più interessanti dell'architettura

stessa.

Oltre al soddisfacimento dei requisiti, l'adozione di tali tecnologie, stan-

dards e patterns architetturali concorre a creare nuove potenzialità applica-

tive, ritenute utili ed interessanti ma �nora poco o per nulla esplorate dagli

Enti Pubblici.

Sviluppi Futuri

È possibile indeti�care senz'altro, un percorso evolutivo nella direzione

intrapresa da questa tesi. Da un la to è possibile perfezionare il disegno archi-

tetturale e completarne l'implementazione, dall'atro è interessante esplorare

nuove possiblità, sia in termini di scelte tecnologiche, sia per quanto riguarda

ulteriori modelli architetturali.

Futuro delle tecnologie basate su SAML

Come accennato nel capitolo 2, la versione 2.0 dello standard SAML,

include molte delle innovazioni apportate da Liberty Alliance a SAML 1.1.


SAML 2.0 include anche caratteristiche proprie di Shibboleth, e quest'ultimo

a sua volta implementerà a breve SAML 2.0.

È pertanto ipotizzabile, col passare del tempo, una sempre maggiore in-

tegrazione di queste tre iniziative, che potrebbe a detta di molti sfociare in

una convergenza.

Figura 5.1: Intervalli temporali di implementazione, osservati e stimati, dei

principali stadard di Identity Management.

Figura tratta da Rouault2.

2http://devresource.hp.com/drc/resources/fed_land/federation_landscapeHP.pdf

Bibliogra�a

[1] Apache HTTP Server Project, -

http://httpd.apache.org/.

[2] Sun Microsystems Java Applets,

http://java.sun.com/applets/.

[3] Eduserv Athens,

http://www.athensams.net/.

[4] Apache Axis SOAP Server,

http://ws.apache.org/axis/.

[5] OASIS Web Services Business Process Execution Language Technical

Committee.

http://www.oasis-open.org/committees/documents.php?wg_ab-

brev=wsbpel.

[6] Bassanini F. Cinque anni di riforma della Amministrazione Pubblica ita-

liana 1996-2001.

http://www.bassanini.it/docs/5anni/index.html.

[7] Bassanini F., ed. L'ammodernamento del sistema amministrativo italiano,

Note per un programma di governo. Luglio 2005.

http://www.bassanini.it/docs/dossier_ammodernamento.pdf.

[8] Pearlman, L. et al. The Community Authorization Service: Status and

Future. CHEP03. March 2003.

http://www.globus.org/alliance/publications/papers/CAS_update_-

CHEP_03-�nal.pdf.

Bibliogra�a 90

[9] Menezes, A. et al. Handbook of Applied Cryptography. CRC Press, 1996.

http://www.cacr.math.uwaterloo.ca/hac/.

[10] Macromedia Flash,

http://www.macromedia.com/software/�ash/.

[11] Welch, V. ed. Globus Toolkit Version 4 Grid Security Infrastructure: A

Standards Perspective. Version 3. July 2005.

http://www.globus.org/toolkit/docs/4.0/security/GT4-GSI-

Overview.pdf.

[12] GUIDE Project,

http://www.guide-project.org/.

[13] The Globus Alliance,

http://www.globus.org/.

[14] Foster, I. Kesselman, C. The Grid: Blueprint for a New Computing

Infrastructure. Morgan Kaufmann, 1999. ISBN 1-558-60475-8

[15] Welch, V. X.509 proxy certi�cates for dynamic delegation. 3rd Annual

PKI R&D Workshop, April 2004.

http://www.globus.org/alliance/publications/papers/pki04-welch-

proxy-cert-�nal.pdf.

[16] Microsoft Internet Information Services,

http://www.microsoft.com/iis.

[17] Internet2 - Home,

http://www.internet2.edu/.

[18] Sun Microsystems' JDBC Technology,

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

[19] Sun Microsystems, Java Web Start Technology,

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

Bibliogra�a 91

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

CITI Technical Report 95-8, July 1995.

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

[21] Cantor, S. Kemp, J. Champagne, D. eds. Liberty ID-FF Bindings and

Pro�les Speci�cation, Version 1.2-errata-v2.0, Liberty Alliance Project

(12 September 2004).

http://www.projectliberty.org/specs/draft-liberty-id�-bindings-pro�les-

1.2-errata-v2.0.pdf.

[22] Liberty Alliance Project - Conformant Products,

http://www.projectliberty.org/activities/conformant_products.php.

[23] Cantor, Scott, Kemp, John, eds. Liberty ID-FF Protocols and Schema

Speci�cation, Version 1.2-errata-v3.0, Liberty Alliance Project (12

September 2004).

http://www.projectliberty.org/specs/draft-liberty-id�-protocols-schema-

1.2-errata-v3.0.pdf

[24] Eric Ti�any ed., Liberty ID-FF 1.2 Static Conformance Requirements,

Liberty Alliance Project.

http://www.projectliberty.org/specs/liberty-id�-1.2-scr-v1.0.pdf.

[25] Liberty Alliance / Project Liberty,

http://www.projectliberty.org.

[26] Microsoft Corporation Microsoft .NET Passport Review Guide. January

2004.

http://download.microsoft.com/download/a/f/4/af49b391-086e-4aa2-

a84b-ef6d916b2f08/passport_reviewguide.doc.

[27] Understanding JavaServer Pages Model 2 architecture,

http://www.javaworld.com/javaworld/jw-12-1999/jw-12-ssj-

jspmvc.html.

[28] Open PERMIS,

http://sec.isi.salford.ac.uk/openPermis/.

Bibliogra�a 92

[29] Rouault, J. Making sense of the federation protocol landscape. Hewlett-

Packard, July 2005.

http://devresource.hp.com/drc/resources/fed_land/federation_land-

scapeHP.pdf.

[30] E. Maler et al., Bindings and Pro�les for the OASIS Security Assertion

Markup Language (SAML). OASIS, September 2003. DocumentID

oasis-sstc-saml-bindings-pro�les-1.1.

http://www.oasis-open.org/committees/download.php/3405/oasis-sstc-

saml-bindings-1.1.pdf.

[31] E. Maler et al., Assertions and Protocol for the OASIS Security Asser-

tion Markup Language (SAML). OASIS, September 2003. Document ID

oasis-sstc-saml-core-1.1.

http://www.oasis-open.org/committees/download.php/3406/oasis-sstc-

saml-core-1.1.pdf.

[32] OASIS Security Services (SAML) Technical Committee,

http://www.oasis-open.org/committees/security/.

[33] Nielsen, H. F. et al. eds. SOAP 1.2 Attachment Feature. W3C Working

Group Note, 8 June 2004.

http://www.w3.org/TR/soap12-af/.

[34] Gudgin, M. et al. eds. SOAP Version 1.2 Part 1: Messaging Framework.

W3C Recommendation, 24 June 2003.

http://www.w3.org/TR/soap12-part1/.

[35] Servlet API,

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

[36] G. Whitehead and S. Cantor, Metadata Pro�le for the OASIS Security

Assertion Markup Language (SAML) V1.x. OASIS SSTC Committee

Draft 01, March 2005. Document ID sstc-saml1x-metadata-cd-01.

http://www.oasis-open.org/committees/download.php/13254/sstc-

saml1x-metadata-cd-01.pdf.

Bibliogra�a 93

[37] S. Cantor et al., Shibboleth Architecture: Technical Overview.

Internet2-MACE Working Draft 02, June 2005. Document ID draft-

mace-shibboleth-techoverview-02.

http://shibboleth.internet2.edu/docs/draft-mace-shibboleth-tech-

overview-02.pdf.

[38] S. Cantor et al., Shibboleth Architecture: Protocols and Pro�les.

Internet2-MACE Working Draft 10, August 2005. Document ID draft-

mace-shibboleth-arch-protocols-10.

http://shibboleth.internet2.edu/docs/draft-mace-shibboleth-arch-

protocols-10.pdf.

[39] Shibboleth Project - Internet2 Middleware,

http://shibboleth.internet2.edu/.

[40] Apache Tomcat,

http://jakarta.apache.org/tomcat/.

[41] P. Hallam-Baker et al., Web Services Security: SOAP Message Security

1.0. OASIS, August 2003. Document ID WSS: SOAP Message Security -

1.0.

http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-

message-security-1.0.pdf.

[42] P. Hallam-Baker et al., Web Services Security: SAML Token Pro�le.

OASIS, December 2004. Document ID oasis-wss-saml-tokenpro�le- 1.0.

http://docs.oasis-open.org/wss/ oasis-wss-saml-token-pro�le-1.0.pdf.

[43] Wikipedia,

http://www.wikipedia.org/.

[44] ITU-T Recommendation X.509 (1997 E): Information Technology

- Open Systems Interconnection - The Directory: Authentication

Framework, June 1997.

Bibliogra�a 94

[45] Bray, T. et al. eds. Extensible Markup Language (XML) 1.1. W3C Re-

commendation, February 2004.

http://www.w3.org/TR/xml11/.

[46] Eastlake D. et al. eds. XML Encryption Syntax and Processing. W3C

Recommendation, December 2002.

http://www.w3.org/TR/xmlenc-core/.

[47] Fallside, D. C. et al. eds. XML Schema Part 0: Primer Second Edition.

W3C Recommendation. October 2004.

http://www.w3.org/TR/xmlschema-0/.

[48] Eastlake D. et al. eds. XML-Signature Syntax and Processing. W3C

Recommendation, February 2002.

http://www.w3.org/TR/xmldsig-core/.

[49] Yale Central Authentication Service,

http://www.yale.edu/tp/auth/

[50] Yale Shibboleth Service Provider Java implementation,

http://tp.its.yale.edu/shib/tiki-index.php.

Appendice A

Il GARR

A.1 Il GARR

Il Consortium GARR è l'ideatore e gestore della rete telematica nazionale

per l'Istruzione, l'Università e la Ricerca Scienti�ca.

Fanno parte del GARR tutte le Entità che rappresentano la Comunità Ac-

cademica e della Ricerca Scienti�ca in Italia.

A.1.1 Storia del GARR

Il GARR (Gruppo per l'Armonizzazione delle Reti della Ricerca) viene

costituito alla �ne degli anni '80 con lo scopo di rappresentare organicamente

la comunità scienti�ca delle Università e degli Enti Pubblici di Ricerca ita-

liani nelle attività di realizzazione, gestione e ricerca delle reti informatiche.

Il suo compito è quello di razionalizzare ed armonizzare le strutture di reti

esistenti che presentavano duplicazioni d'infrastrutture e protocolli di comu-

nicazione solo parzialmente compatibili tra loro. Grazie al lavoro di questo

Gruppo e al co-�nanziamento di 5 miliardi di lire del Ministero dell'Univer-

sità e della Ricerca Scienti�ca e Tecnologica (MURST), viene alla luce la

prima Rete Unitaria dell'Università e della Ricerca che diviene una delle più

veloci reti della Ricerca in Europa e nel mondo.

Nel 2001 nasce il Consortium GARR. È una associazione senza �ni di

A.A.1.2 La missione 96

lucro fondata da CRUI, CNR, ENEA e INFN con il patrocinio del Ministero

dell'Istruzione, dell'Università e della Ricerca (MIUR). Contemporaneamen-

te parte il progetto GARR-Giganet (GARR-G) che entra in funzione alla �ne

del 2003, consentendo l'accesso a larghissima banda e il supporto di una vasta

gamma di servizi avanzati a bene�cio della comunità degli utenti GARR.

Il lavoro del GARR rappresenta un contributo signi�cativo per l'attività

della comunità scienti�ca ed accademica italiana e per il progresso tecnologico

ed industriale del nostro Paese.

A.1.2 La missione

La missione del Consortium GARR consiste nella implementazione,

gestione ed ampliamento della rete telematica nazionale ad altissima velocità

per l'istruzione, l'accademia e la ricerca scienti�ca, interconnessa con tutte

le reti della ricerca europee e mondiali.

Secondo lo Statuto del Consortium GARR, per conseguire il suo scopo il

Consortium, nella sua veste di responsabile della gestione della rete, ha per

oggetto lo sviluppo delle seguenti funzioni:

a. programma lo sviluppo della rete e dei servizi sulla base delle esigenze

degli associati;

b. stabilisce le linee di sviluppo della rete e le forme organizzative delle infra-

strutture di rete; de�nisce le speci�che, le soluzioni tecniche, i protocolli

di rete e le norme di accesso;

c. de�nisce e coordina la con�gurazione degli apparati di accesso alla rete;

d. valuta lo sviluppo tecnico ed economico di reti ad alto contenuto innova-

tivo in funzione del perseguimento degli obiettivi;

e. realizza e�caci strumenti di informazione e documentazione sul funziona-

mento della rete;

f. stabilisce le condizioni di accesso alla rete e le relative modalità.

A.A.1.3 La comunità del GARR 97

A.1.3 La comunità del GARR

La Comunità delle Università e della Ricerca Scienti�ca che a�erisce al

GARR è composta da:

1. gli Enti fondatori del Consortium GARR (CNR, ENEA, INFN e la

Fondazione CRUI in rappresentanza delle Università italiane);

2. gli organismi di ricerca vigilati dal MIUR, tra cui ASI, INAF, INGV e

altri;

3. i Consorzi Interuniversitari per il Calcolo (CASPUR, CILEA, CINE-

CA);

4. le università e istituzioni culturali e/o scienti�che straniere con sede in

Italia e per le quali esistono accordi con il Governo italiano;

5. organismi culturali e di ricerca a�erenti ad altri Ministeri, quali MiBAC

e Salute;

6. associazioni o consorzi tra organismi di cui alle categorie 1 e 2;

7. centri di ricerca e istituzioni culturali e/o scienti�che italiane di rile-

vante interesse per la comunità scienti�ca nazionale e centri di ricerca.

Appendice B

File completo shibboleth.xml

<SPConfig xmlns="urn:mace:shibboleth:target:config:1.0"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="urn:mace:shibboleth:target:config:1.0

shibboleth-targetconfig-1.0.xsd"

clockSkew="180"

logger="/etc/shibboleth/shibboleth.logger">



<Extensi ons>

<Library path="/usr/local/shib-sp/libexec/xmlproviders.so" fatal="true"/>

</Extensions>



<Global logger="/etc/shibboleth/shibd.logger">



<UnixListener address="/var/run/shibd.sock"/>



<MemorySessionCache cleanupInterval="300" cacheTimeout="3600"

AATimeout="30" AAConnectTimeout="15"

defaultLifetime="1800" retryInterval="300"

strictValidity="false" propagateErrors="false"/>

</Global>



<Local logger="/etc/shibboleth/native.logger" localRelayState="true">



<RequestMapProvider type="edu.internet2.middleware.shibboleth.sp.provider.

NativeRequestMapProvider">

<RequestMap applicationId="default">



<Host name="shibsp.unipr.it">

<Path name="secure" authType="shibboleth" requireSession="true"

exportAssertion="true">





</Path>

</Host>

</RequestMap>

</RequestMapProvider>

</Local>



<Applications id="default"

providerId="https://shibsp.unipr.it"

homeURL="https://shibsp.unipr.it/"

xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion"

xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata">

101



<Sessions lifetime="7200" timeout="3600" checkAddress="false"

handlerURL="/Shibboleth.sso" handlerSSL="true"

idpHistory="true" idpHistoryDays="7">





<SessionInitiator id="https://shibidp.unipr.it" isDefault="true"

Location="/WAYF/LSIP"

Binding="urn:mace:shibboleth:sp:1.3:SessionInit"

wayfURL="https://shibboleth.unimore.it/WAYF"

wayfBinding="urn:mace:shibboleth:1.0:profiles:AuthnRequest"/>

102







<md:AssertionConsumerService Location="/SAML/POST" index="1"

isDefault="true"

Binding="urn:oasis:names:tc:SAML:1.0:profiles:browser-post"/>

<md:AssertionConsumerService Location="/SAML/Artifact" index="2"

Binding="urn:oasis:names:tc:SAML:1.0:profiles:artifact-01"/>



<md:SingleLogoutService Location="/Logout"

Binding="urn:mace:shibboleth:sp:1.3:Logout"/>

</Sessions>



<Errors session="/etc/shibboleth/sessionError.html"

metadata="/etc/shibboleth/metadataError.html"

rm="/etc/shibboleth/rmError.html"

access="/etc/shibboleth/accessError.html"

supportContact="root@localhost"

logoLocation="/shibboleth-sp/logo.jpg"

styleSheet="/shibboleth-sp/main.css"/>



<CredentialUse TLS="defcreds" Signing="defcreds">

</CredentialUse>



<AAPProvider type="edu.internet2.middleware.shibboleth.aap.provider.XMLAAP"

uri="/etc/shibboleth/AAP.xml"/>

<MetadataProvider type="edu.internet2.middleware.shibboleth.metadata.

provider.XMLMetadata"

uri="/etc/shibboleth/metadata.xml"/>



<TrustProvider type="edu.internet2.middleware.shibboleth.common.provider.

ShibbolethTrust"/>



<saml:Audience>urn:urn:mace:inqueue</saml:Audience>





</Applications>



<CredentialsProvider type="edu.internet2.middleware.shibboleth.

common.Credentials">

105

<Credentials xmlns="urn:mace:shibboleth:credentials:1.0">

<FileResolver Id="defcreds">

<Key>

<Path>/etc/pki/shibsp.unipr.it.key</Path>

</Key>

<Certificate>



<Path>/etc/pki/shibsp.unipr.it.crt</Path>

</Certificate>

</FileResolver>

</Credentials>

</CredentialsProvider>



<AttributeFactory AttributeName="urn:oid:1.3.6.1.4.1.5923.1.1.1.10"

type="edu.internet2.middleware.shibboleth.common.provider.i

TargetedIDFactory"/>

</SPConfig>

Appendice C

Script di avvio Tomcat 5.5

#!/bin/sh

#

# Startup script for Tomcat5.5

NAME=tomcat

JAVA_HOME=/usr/local/java

export JAVA_HOME

CATALINA_HOME=/usr/local/tomcat

export CATALINA_HOME

if [ -z "${JAVA_HOME}" -a -d "$JAVA_HOME" ]; then

echo "JAVA_HOME was not set properly: $JAVA_HOME"

exit 1

fi

if [ -z "${CATALINA_HOME}" -a -d "$CATALINA_HOME" ]; then

echo "CATALINA_HOME was not set properly: $CATALINA_HOME"

exit 1

fi

start() {

echo "Starting tomcat: "

107

if [ -x "$CATALINA_HOME/bin/startup.sh" ]; then

su -p -c $CATALINA_HOME/bin/startup.sh

echo "done."

else

echo "Cannot find $CATALINA_HOME/bin/startup.sh,

or it isn't executable"

exit 1

fi

}

stop() {

echo "Shutting down tomcat: "

if [ -x "$CATALINA_HOME/bin/shutdown.sh" ]; then

su -p -c $CATALINA_HOME/bin/shutdown.sh

sleep 1

##kill all remaining processes (happens often)

ps u | grep catalina | grep -v grep | awk '{print $2}' |

xargs kill -9

echo "done."

else

echo "Cannot find $CATALINA_HOME/bin/shutdown.sh,

or it isn't executable"

exit 1

fi

}

# See how we were called

case "$1" in

start)

start

;;

stop)

stop

;;

restart)

stop

108

start

;;

*)

echo "Usage: $0 {start|stop|restart}"

esac

exit 0

Appendice D

Proprietà di log4j

#### Configures Log4j as the Tomcat system logger ####

#NOTE: this file is probably monitored by Spring, running inside

#CAS3 and should therefore be automatically reloaded on changes

#(if CAS3 is not configured correctly to do this: restart Tomcat

#for the changes to take effect)

# Configure the rootLogger, this is the logger that will receive

# all output

log4j.rootLogger=INFO, TOMCAT_APPENDER

log4j.logger.org.apache=INFO

#log4j.logger.org.apache.catalina.core.ContainerBase.[Catalina]=DEBUG

#log4j.logger.org.apache.catalina.core=DEBUG

#log4j.logger.org.apache.catalina.session=DEBUG

#log4j.logger.org.apache.jasper.compiler.JspRuntimeContext=DEBUG

#log4j.logger.org.apache.catalina.realm=DEBUG

#log4j.logger.org.apache.struts=DEBUG

#log4j.logger.org.apache.struts=INFO

### cas-client ###

110

log4j.logger.edu.yale.its.tp.cas.client=INFO, SHIB_APPENDER

#log4j.logger.edu.yale.its.tp.cas=DEBUG, SHIB_APPENDER

### Shibboleth-IdP ###

log4j.logger.org.apache.xml.security=INFO, SHIB_APPENDER

#log4j.logger.org.apache.xml.security=DEBUG, SHIB_APPENDER

log4j.logger.edu.internet2.middleware.shibboleth=INFO, SHIB_APPENDER

#log4j.logger.edu.internet2.middleware.shibboleth.xml=DEBUG

#log4j.logger.edu.internet2.middleware.shibboleth.idp=DEBUG

#log4j.logger.edu.internet2.middleware.shibboleth.idp.IdPResponder=DEBUG

#log4j.logger.edu.internet2.middleware.shibboleth.idp.IdPConfigLoader=DEBUG

#log4j.logger.edu.internet2.middleware.shibboleth.aa=DEBUG

#log4j.logger.edu.internet2.middleware.shibboleth.aa.attrresolv=DEBUG

#reduce logging when in DEBUG

#log4j.logger.edu.internet2.middleware.shibboleth.aa.arp.ArpEngine=INFO

### cas-server ###

log4j.logger.org.jasig.cas=INFO, CAS_APPENDER

#log4j.logger.org.jasig.cas.authentication=DEBUG

#log4j.logger.org.jasig.cas.web.flow.TicketGrantingTicketCheckAction=DEBUG

#log4j.logger.org.jasig.cas.services=DEBUG

#log4j.logger.org.jasig.cas.services.DefaultServiceRegistry=DEBUG

#log4j.logger.org.jasig.cas.ticket=DEBUG

#log4j.logger.org.jasig.cas.adaptors.x509=DEBUG

#log4j.logger.org.jasig.cas.adaptors.ldap=DEBUG

#log4j.logger.org.jasig.cas.adaptors.radius=DEBUG

log4j.logger.org.esupportail.cas.server.GenericHandler=INFO, CAS_APPENDER

log4j.logger.org.springframework=WARN, CAS_APPENDER

#log4j.logger.org.springframework.web.servlet.view=DEBUG

#log4j.logger.org.springframework.web.servlet.i18n=DEBUG

log4j.logger.org.quartz=INFO, CAS_APPENDER

111

# Configuration for a rolling log file ("tomcat.log").

log4j.appender.TOMCAT_APPENDER=org.apache.log4j.DailyRollingFileAppender

log4j.appender.TOMCAT_APPENDER.DatePattern='.'yyyy-MM-dd

# Edit the next line to point to your logs directory.

# The last part of the name is the log file name.

log4j.appender.TOMCAT_APPENDER.File=${catalina.home}/logs/tomcat.log

log4j.appender.TOMCAT_APPENDER.layout=org.apache.log4j.PatternLayout

#

# Print the date in ISO 8601 format

log4j.appender.TOMCAT_APPENDER.layout.ConversionPattern=%d [%t] %-5p

%c - %m%n

# Configuration for a rolling log file ("shibboleth-idp.log").

log4j.appender.SHIB_APPENDER=org.apache.log4j.DailyRollingFileAppender

log4j.appender.SHIB_APPENDER.DatePattern='.'yyyy-MM-dd



log4j.appender.SHIB_APPENDER.File=${catalina.home}/logs/shibboleth-idp.log

log4j.appender.SHIB_APPENDER.layout=org.apache.log4j.PatternLayout

#


log4j.appender.SHIB_APPENDER.layout.ConversionPattern=%d{HH:mm:ss,SSS}

[%p] %m - %c [%t; %d]%n

# Configuration for a rolling log file ("cas3-server.log").

log4j.appender.CAS_APPENDER=org.apache.log4j.DailyRollingFileAppender

log4j.appender.CAS_APPENDER.DatePattern='.'yyyy-MM-dd



log4j.appender.CAS_APPENDER.File=${catalina.home}/logs/cas3-server.log

log4j.appender.CAS_APPENDER.layout=org.apache.log4j.PatternLayout

112

#


log4j.appender.CAS_APPENDER.layout.ConversionPattern=%d{HH:mm:ss,SSS}

[%p] %m - %c [%t; %d]%n

Appendice E

File di con�gurazione IdP:

dist.idp.xml

<?xml version="1.0" encoding="ISO-8859-1"?>

<!DOCTYPE web-app

PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"

"http://java.sun.com/dtd/web-app_2_3.dtd">

<web-app>

<context-param>

<param-name>IdPConfigFile</param-name>

<param-value>$IDP_HOME$/etc/idp.xml</param-value>

</context-param>

<filter>

<filter-name>CASFilter</filter-name>

<filter-class>edu.yale.its.tp.cas.client.filter.CASFilter

</filter-class>



<init-param>

<param-name>edu.yale.its.tp.cas.client.filter.loginUrl

</param-name>

<param-value>https://$CASHOSTNAME$/cas/login

114

</param-value>

</init-param>



<init-param>

<param-name>edu.yale.its.tp.cas.client.filter.validateUrl

</param-name>

<param-value>https://$CASHOSTNAME$/cas/serviceValidate

</param-value>

</init-param>



<init-param>

<param-name>edu.yale.its.tp.cas.client.filter.serverName

</param-name>

<param-value>$IDPHOSTNAME$</param-value>

</init-param>



<init-param>

<param-name>edu.yale.its.tp.cas.client.filter.wrapRequest

</param-name>

<param-value>true</param-value>

</init-param>

</filter>

<filter-mapping>

<filter-name>CASFilter</filter-name>

<url-pattern>/SSO/*</url-pattern>

</filter-mapping>



<servlet>

<servlet-name>IdP</servlet-name>

<display-name>Shibboleth Identity Provider</display-name>

<servlet-class>edu.internet2.middleware.shibboleth.idp.IdPResponder

</servlet-class>

115

</servlet>

<servlet-mapping>


<url-pattern>/SSO</url-pattern>

</servlet-mapping>

<servlet-mapping>


<url-pattern>/AA</url-pattern>

</servlet-mapping>

<servlet-mapping>


<url-pattern>/Artifact</url-pattern>

</servlet-mapping>

<servlet-mapping>


<url-pattern>/Status</url-pattern>

</servlet-mapping>

<mime-mapping>

<extension>css</extension>

<mime-type>text/css</mime-type>

</mime-mapping>

</web-app>

Appendice F

File completo idp.xml

<?xml version="1.0" encoding="ISO-8859-1"?>

<IdPConfig

xmlns="urn:mace:shibboleth:idp:config:1.0"

xmlns:cred="urn:mace:shibboleth:credentials:1.0"

xmlns:name="urn:mace:shibboleth:namemapper:1.0"


xsi:schemaLocation="urn:mace:shibboleth:idp:config:1.0

../schemas/shibboleth-idpconfig-1.0.xsd"

AAUrl="https://idp.example.it:8443/shibboleth-idp/AA"

resolverConfig="file:/usr/local/shib-idp/etc/resolver.xml"

defaultRelyingParty="urn:mace:shibp.unipr.it"

providerId="urn:mace:shibsp.unipr.it:shib:example.it">



<RelyingParty name="urn:mace:shibsp.unipr.it:shib"

signingCredential="default_cred">



117

<NameID nameMapping="shm"/>



</RelyingParty>



<ReleasePolicyEngine>

<ArpRepository implementation="edu.internet2.middleware.

shibboleth.aa.arp.provider.FileSystemArpRepository">

<Path>file:/usr/local/shib-idp/etc/arps/</Path>

</ArpRepository>

</ReleasePolicyEngine>



<--

<Logging>

<ErrorLog level="WARN"

location="file:/usr/local/shib-idp/logs/shib-error.log" />

<TransactionLog level="INFO"

location="file:/usr/local/shib-idp/logs/shib-access.log" />

</Logging>

-->



<Logging>

<Log4JConfig

location="file:/usr/local/tomcat/common/classes/log4j.properties" />

</Logging>

118



<NameMapping

xmlns="urn:mace:shibboleth:namemapper:1.0"

id="shm"

format="urn:mace:shibboleth:1.0:nameIdentifier"

type="SharedMemoryShibHandle"

handleTTL="28800"/>



<ArtifactMapper implementation="edu.internet2.middleware.shibboleth.

artifact.provider.MemoryArtifactMapper" />





<Credentials xmlns="urn:mace:shibboleth:credentials:1.0">

<KeyStoreResolver Id="default_cred" storeType="JKS">

<Path>file:/etc/pki/idp.jks</Path>

<KeyAlias>tomcat</KeyAlias>

<CertAlias>tomcat</CertAlias>

<StorePassword>secret</StorePassword>

<KeyPassword>secret</KeyPassword>

</KeyStoreResolver>

119



</Credentials>



<ProtocolHandler implementation="edu.internet2.middleware.shibboleth.

idp.provider.ShibbolethV1SSOHandler">

<Location>https?://[^:/]+(:(443|80))?/shibboleth-idp/SSO</Location>



</ProtocolHandler>


idp.provider.SAMLv1_AttributeQueryHandler">

<Location>.+:8443/shibboleth-idp/AA</Location>

</ProtocolHandler>


idp.provider.SAMLv1_1ArtifactQueryHandler">

<Location>.+:8443/shibboleth-idp/Artifact</Location>

</ProtocolHandler>


idp.provider.Shibboleth_StatusHandler">

<Location> https://[^:/ ]+(:443)?/shibboleth-idp/Status</Location>

120

</ProtocolHandler>



<MetadataProvider type="edu.internet2.middleware.shibboleth.

metadata.provider.XMLMetadata"

uri="file:/usr/local/shib-idp/etc/metadata-unipr-sp.xml"/>

</IdPConfig>

Appendice G

File completo resolver.xml

<AttributeResolver xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xmlns="urn:mace:shibboleth:resolver:1.0"

xsi:schemaLocation="urn:mace:shibboleth:resolver:1.0

shibboleth-resolver-1.0.xsd">

<SimpleAttributeDefinition

id="urn:mace:dir:attribute-def:eduPersonAffiliation">

<DataConnectorDependency requires="directory"/>

</SimpleAttributeDefinition>

<SimpleAttributeDefinition id="urn:mace:dir:attribute-def:cn">



<SimpleAttributeDefinition id="urn:mace:dir:attribute-def:sn">




id="urn:mace:dir:attribute-def:givenName">



122

<SimpleAttributeDefinition id="urn:mace:dir:attribute-def:mail">



<SimpleAttributeDefinition id="urn:mace:dir:attribute-def:uid">




id="urn:mace:dir:attribute-def:eduPersonPrimaryAffiliation">






id="urn:mace:dir:attribute-def:eduPersonScopedAffiliation"

smartScope="example.it">

<AttributeDependency

requires="urn:mace:dir:attribute-def:eduPersonAffiliation"/>



id="urn:mace:dir:attribute-def:eduPersonPrincipalName"

smartScope="example.it" sourceName="uid">






123

id="urn:mace:shibsp.unipr.it:dir:attribute-def:logoutURL">

<DataConnectorDependency requires="static"/>


<StaticDataConnector id="static">

<Attribute name="logoutURL">

<Value>

https://idp.example.it/shibboleth-idp/logout.jsp

</Value>

</Attribute>

</StaticDataConnector>

<JNDIDirectoryDataConnector id="directory" cacheTime="60">

<Search filter="mail=%PRINCIPAL%">

<Controls searchScope="SUBTREE_SCOPE"

returningObjects="false" />

</Search>

<Property name="java.naming.factory.initial"

value="com.sun.jndi.ldap.LdapCtxFactory" />

<Property name="java.naming.provider.url"

value="ldap://ldap.example.it/ou=people,

dc=shibsp.unipr,dc=it" />

<Property name="java.naming.security.principal"

value="[email protected],ou=people,

dc=shisp.unipr,dc=it" />

<Property name="java.naming.security.credentials"

value="test" />

</JNDIDirectoryDataConnector>

</AttributeResolver>

Appendice H

Esempio di un Attribute Release

Policy

<?xml version="1.0" encoding="UTF-8"?>

<AttributeReleasePolicy


xmlns="urn:mace:shibboleth:arp:1.0"

xsi:schemaLocation="urn:mace:shibboleth:arp:1.0

shibboleth-arp-1.0.xsd" >

<Description>SHIBBOLETH unipr simple example ARP</Description>



<Rule>

<Target>

<AnyTarget/>

</Target>

<Attribute

name="urn:mace:dir:attribute-def:eduPersonAffiliation">

<AnyValue release="permit"/>

</Attribute>

<Attribute

name="urn:mace:dir:attribute-def:eduPersonScopedAffiliation">

125


</Attribute>

<Attribute

name="urn:mace:dir:attribute-def:eduPersonOrgDN">


</Attribute>

<Attribute

name="urn:mace:dir:attribute-def:eduPersonOrgUnitDN">


</Attribute>

<Attribute

name="urn:mace:shib.unipr.it:dir:attribute-def:logoutURL">


</Attribute>

</Rule>



<Rule>

<Target>

<Requester matchFunction="urn:mace:shibboleth:

arp:matchFunction:regexMatch">^https://[^/]*EXAMPLE\.be.*</Requester>

</Target>

<Attribute

name="urn:mace:dir:attribute-def:eduPersonPrincipalName">


</Attribute>

<Attribute name="urn:mace:dir:attribute-def:uid">


</Attribute>

</Rule>

126

<Rule>

<Target>

<Requester matchFunction="urn:mace:shibboleth:arp:

matchFunction:exactShar">

https://shib.unipr.it/secure/allAttributes</Requester>

</Target>

<Attribute

name="urn:mace:dir:attribute-def:eduPersonPrincipalName">


</Attribute>

<Attribute name="urn:mace:dir:attribute-def:cn">


</Attribute>

<Attribute name="urn:mace:dir:attribute-def:sn">


</Attribute>

<Attribute name="urn:mace:dir:attribute-def:givenName">


</Attribute>

<Attribute name="urn:mace:dir:attribute-def:mail">


</Attribute>

<Attribute

name="urn:mace:dir:attribute-def:telephoneNumber">


</Attribute>

127

<Attribute name="urn:mace:dir:attribute-def:postalAddress">


</Attribute>

<Attribute name="urn:mace:dir:attribute-def:ou">


</Attribute>

</Rule>

</AttributeReleasePolicy>

Documents

Problematiche relative all'introduzione di un sistema di ... · 1 L'outsourcing: si riferisce genericamente alle pratiche adottate dalle imprese di ester-nalizzare alcune fasi del