Progetto di gestione dell`Accesso in un sistema di Identity and

Università degli studi di Parma
Facoltà di Scienze Matematiche Fisiche Naturali
Corso di Laurea in Informatica
Tesi di Laurea in
Reti di Calcolatori
Progetto di gestione dell’Accesso in un
sistema di Identity and Access Management
di Ateneo
Relatore
Candidato
Prof. Roberto Alfieri
Andrea Zanelli
Corelatore
Ing. Marco Panella
Anno Accademico 2008/2009
A mia madre Gabriella
e a mio padre Sandro.
Indice
1 Obiettivo del progetto
11
2 IAM (Identity and Access Management)
15
2.1
Cos’è un sistema IAM . . . . . . . . . . . . . . . . . . . . . .
15
2.2
IAM federato . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
2.3
Identità e ciclo di vita dell’identità . . . . . . . . . . . . . . .
20
2.3.1
Identità . . . . . . . . . . . . . . . . . . . . . . . . . .
21
2.3.2
Ciclo di vita delle identità . . . . . . . . . . . . . . . .
22
Accesso: autenticazione e autorizzazione . . . . . . . . . . . .
23
2.4.1
Autenticazione degli utenti . . . . . . . . . . . . . . .
23
2.4.2
Autorizzazione . . . . . . . . . . . . . . . . . . . . . .
24
Implementare un server IAM . . . . . . . . . . . . . . . . . .
24
2.5.1
LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
2.5.2
Database e DBMS . . . . . . . . . . . . . . . . . . . .
31
2.4
2.5
3 Gestione dell’accesso
35
3.1
Cosa significa gestire l’accesso . . . . . . . . . . . . . . . . . .
35
3.2
Le risorse informatiche . . . . . . . . . . . . . . . . . . . . . .
36
3.2.1
WiFi . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
3.2.2
VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
3.2.3
Posta elettronica . . . . . . . . . . . . . . . . . . . . .
40
3.2.4
Risorse web . . . . . . . . . . . . . . . . . . . . . . . .
41
3.2.5
Postazioni computer . . . . . . . . . . . . . . . . . . .
41
Soluzioni e tecnologie per l’accesso . . . . . . . . . . . . . . .
42
3.3.1
Username e password
. . . . . . . . . . . . . . . . . .
42
3.3.2
Single Sign On . . . . . . . . . . . . . . . . . . . . . .
43
3.3.3
RADIUS . . . . . . . . . . . . . . . . . . . . . . . . . .
44
3.3
5
3.3.4
Kerberos . . . . . . . . . . . . . . . . . . . . . . . . . .
47
3.3.5
Public Key Infrastructure . . . . . . . . . . . . . . . .
50
4 Situazione attuale nell’Università di Parma
4.1
4.2
53
Il contesto . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
53
4.1.1
Risorse disponibili agli utenti . . . . . . . . . . . . . .
53
Attuale gestione dell’accesso . . . . . . . . . . . . . . . . . . .
54
4.2.1
Struttura del server LDAP
. . . . . . . . . . . . . . .
55
4.2.2
Accesso alle risorse informatiche . . . . . . . . . . . . .
56
4.2.3
Problematiche della gestione attuale . . . . . . . . . .
57
5 Progetto: gestione centralizzata dell’accesso
59
5.1
Vincoli progettuali . . . . . . . . . . . . . . . . . . . . . . . .
60
5.2
Architettura generale . . . . . . . . . . . . . . . . . . . . . . .
61
5.3
LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
62
5.3.1
Quale server LDAP . . . . . . . . . . . . . . . . . . . .
62
5.3.2
Struttura e schema . . . . . . . . . . . . . . . . . . . .
64
5.3.3
Attributi per l’identità . . . . . . . . . . . . . . . . . .
67
5.3.4
Attributi per l’accesso . . . . . . . . . . . . . . . . . .
72
5.3.5
Esempio di una entry LDAP
. . . . . . . . . . . . . .
78
Gestione cetralizzata dell’accesso con LDAP . . . . . . . . . .
80
5.4.1
RADIUS e LDAP . . . . . . . . . . . . . . . . . . . . .
80
5.4.2
WiFi . . . . . . . . . . . . . . . . . . . . . . . . . . . .
81
5.4.3
VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . .
87
5.4.4
Risorse web . . . . . . . . . . . . . . . . . . . . . . . .
88
5.4.5
Posta elettronica . . . . . . . . . . . . . . . . . . . . .
91
5.4.6
Windows e Linux . . . . . . . . . . . . . . . . . . . . .
92
5.4.7
Schema del progetto . . . . . . . . . . . . . . . . . . .
95
5.5
Trasmissione sicura dei dati riservati . . . . . . . . . . . . . .
96
5.6
Gestione del carico: affidabilità e performance . . . . . . . . .
97
5.6.1
Heartbeat . . . . . . . . . . . . . . . . . . . . . . . . .
98
5.6.2
Linux Virtual Server . . . . . . . . . . . . . . . . . . .
99
5.6.3
Architettura per il bilanciamento del carico . . . . . . 100
5.4
5.7
IDEM: federazione della rete GARR . . . . . . . . . . . . . . 101
5.7.1
Attributi IDEM . . . . . . . . . . . . . . . . . . . . . . 101
6 Conclusioni
105
6
A Schema LDAP
107
Bibliografia
123
7
8
Elenco delle figure
2.1
Ogni risorsa gestisce gli accessi in modo autonomo. . . . . . .
16
2.2
Gestione centralizzata degli accessi. . . . . . . . . . . . . . . .
16
2.3
Federazione senza AAI.
. . . . . . . . . . . . . . . . . . . . .
20
2.4
Federazione con AAI. . . . . . . . . . . . . . . . . . . . . . . .
21
2.5
Ciclo di vita dell’identità. . . . . . . . . . . . . . . . . . . . .
23
2.6
Server IAM. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
2.7
Esempio di un albero delle entry (DIT). . . . . . . . . . . . .
26
2.8
Distinguished name (DN) di una entry. . . . . . . . . . . . . .
27
2.9
Possibile struttura di una entry. . . . . . . . . . . . . . . . . .
27
3.1
Schema di una rete wireless collegata ad una rete wired
. . .
38
3.2
Roaming tra access point . . . . . . . . . . . . . . . . . . . .
39
3.3
Remote Access VPN su rete Internet . . . . . . . . . . . . . .
39
3.4
Scambio di ticket per l’autenticazione con kerberos. . . . . . .
48
5.1
Architettura generale del progetto. . . . . . . . . . . . . . . .
61
5.2
Schema logico dell’architettura del progetto. . . . . . . . . . .
62
5.3
Esempio di infrastruttura per l’autenticazione al WiFi con
PPPoE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.4
84
Schema di una infrastruttura per l’autenticazione al WiFi con
802.1x . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
85
5.5
Autenticazione ad una risorsa web tramite CAS. . . . . . . .
89
5.6
Schema di funzionamento di Shibboleth. . . . . . . . . . . . .
91
5.7
Clients Windows configurati per autenticare gli utenti tramite
il server SAMBA, che a sua volta prende gli attributi degli
5.8
utenti dal server LDAP. . . . . . . . . . . . . . . . . . . . . .
93
Connessioni sicure con SAMBA. . . . . . . . . . . . . . . . . .
94
9
5.9
Autenticazione di client Linux sfruttando direttamente il server
LDAP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
94
5.10 Schema di tutte le risorse illustrate in precedenza, con uno
sguardo anche ai protocolli di sicurezza utilizzati. . . . . . . .
10
95
Capitolo 1
Obiettivo del progetto
In una qualunque organizzazione dove vi sono risorse informatiche, come
la posta elettronica, postazioni computer oppure anche una rete locale, ed
un buon numero di utenti che utilizzano queste risorse, diventa necessario (e
a volte anche obbligatorio) gestire in modo appropriato le identità digitali
degli utenti e le credenziali di accesso alle risorse informatiche per tali utenti.
È evidente che una qualunque università fa parte di questa categoria di
organizzazioni, quindi richiede una gestione delle identità e dell’accesso.
Un sistema di Identity and Access Management (brevemente IAM) è
l’insieme di tutte le componenti, le procedure e le tecnologie che servono
a gestire le identità e l’accesso. Attraverso un sistema IAM centralizzato,
nel quale ogni persona ha una e una sola identità digitale, ed a cui tutte
le risorse informatiche fanno riferimento per gestire l’accesso, si riesce ad
ottenere una situazione che offre diversi vantaggi: ogni utente avrà infatti
sempre le stesse credenziali di accesso, evitando così di doversi ricordare
una password diversa per ogni risorsa che vuole utilizzare, ma anche dal
punto di vista amministrativo le cose migliorano, gli utenti vengono gestiti
in un’unica infrastruttura alla quale le risorse informatiche si riferiscono per
gestire l’accesso, semplificando l’intero processo di amministrazione degli
utenti.
Attualmente, nell’Università di Parma, le identità digitali sono mantenute
separate in base al ruolo ricoperto all’interno dell’università, in questo modo
se una persona ricopre più ruoli (ad esempio uno studente-ricercatore) si
trova ad avere più identità digitali. Inoltre si ha una gestione degli accessi per
la quale si possono avere chiavi di accesso diverse a seconda della risorsa che
11
si vuole utilizzare. Questa situazione è quindi ben diversa a quella accennata
poco sopra, con uno IAM centralizzato.
Lo scopo di questo progetto è proprio studiare e progettare una soluzione
reale per un sistema di Identity and Access Management per l’Università di
Parma, in cui ogni persona avrà un’unica identità digitale, ed in cui l’accesso
alle risorse avverrà utilizzando sempre le stesse credenziali. In particolare si
ci concentrerà sulla gestione dell’accesso, ovvero di come creare un sistema in
cui tutte le risorse informatiche dell’università possano fare riferimento ad
un’infrastruttura comune per gestire l’accesso, e di come si può implemetare
questa infrastruttura che si deve interfacciare con le risorse e deve contenere
le identità digitali degli utenti e le loro credenziali di accesso. Altro problema,
che però non viene affrontato in questo testo, è invece come creare e mantenere
le identità digitali, partendo dalle fonti, cioè da dove arrivano le informazioni
sugli utenti, e come gestire il loro ciclo di vita.
La gestione dell’accesso dovrà tenere conto anche di una serie di vincoli
tecnici assolutamente non trascurabili: sicurezza, affidabilità ed efficenza,
vincoli che in generale si trovano in una qualunque infrastruttura centralizzata,
dove vi è evidentemente un punto critico. Dovendo gestire dati riservati (come
le password) la sicurezza del sistema assume un ruolo fondamentale, si vuole
infatti evitare che utenti malintenzionati possano venire a conoscenza di
dati riservati di altri utenti o addirittura di riuscire ad accedere a risorse
normalmente non accessibili. Gli altri vincoli da rispettare sono chiaramente
l’efficenza e l’affidabilità: il sistema dovrà essere in grado di rispondere in
tempi accettabili anche a fronte di un numero elevato di richieste e, soprattutto,
dovrà essere sempre presente cercando di minimizzare i tempi di downtime
in caso di guasti o incidenti.
Nei prossimi capitoli vediamo meglio cos’è un sistema IAM, accennando,
senza entrare troppo nei particolari, allo IAM federato, e specificando cosa
intendiamo per identità digitale, ciclo di vita dell’identità, ed accesso ad una
risorsa informatica. Subito dopo vengono descritti quali strumenti si possono
utilizzare per implementare realmente un server IAM, cioè un server per la
gestione delle identità e dell’accesso, tenendo presente che uno degli obiettivi
del progetto è proprio implementare un server di questo tipo. Siccome si
parte dal presupposto che le identità degli utenti siano, in qualche modo,
opportunamente create e mantenute nel server IAM, non si entra nei dettagli
di come questo avviene, ed invece si illustra, nel capitolo 3, la gestione
12
dell’accesso ad un livello generale, descrivendo le risorse informatiche in
genere presenti in una università e gli strumenti che si possono utilizzate per
la gestione dell’accesso. Dopo tutta l’introduzione dei concetti generali, si
entra nel dettaglio dell’Università di Parma, descrivendo prima la situazione
attuale dell’accesso alle risorse informatiche, mettendone in evidenza i limiti e i
problemi, per arrivare infine al progetto che punta a risolvere tali problemi ed a
introdurre diversi vantaggi nella gestione dell’accesso alle risorse informatiche.
13
14
Capitolo 2
IAM (Identity and Access
Management)
2.1
Cos’è un sistema IAM
Il problema del riconoscimento dell’utente e dell’attribuzione dei relativi
permessi è un problema tipico di tutte quelle situazioni in cui vengono fornite
particolari risorse informatiche (risorse web, accesso a Internet, postazioni
computer, posta elettronica, ecc.) che richiedono autenticazione e autorizzazione. Queste problematiche sono gestite da un sistema di Identity and
Access Management (IAM) che lo si può quindi definire come l’intero
processo (applicazione di policy appropriate ed impiego di strumenti tecnologici) volto a gestire le informazioni riguardanti le identità degli utenti e
controllarne l’accesso alle risorse informatiche.
Esistono due diverse metodologie per affrontare tale problema:
1. Ogni risorsa gestisce in modo autonomo l’autenticazione e l’autorizzazione ai servizi offerti (figura 2.1).
2. La gestione degli accessi è centralizzata (figura 2.2).
Nella realtà si possono avere anche casi misti, in cui alcune risorse hanno
una gestione degli accessi centralizzata ed esistono risorse che gestiscono gli
accessi in proprio; questo caso lo si può chiaramente ricondurre al primo
punto in quanto non si ha una vera e propria centralizzazione degli accessi,
ma sottoinsiemi di risorse che gestiscono automamente l’autenticazione e
l’autorizzazione in modo autonomo.
15
Figura 2.1: Ogni risorsa gestisce gli accessi in modo autonomo.
Figura 2.2: Gestione centralizzata degli accessi.
Il primo metodo comporta evidentemente diversi problemi, dal punto di
vista del gestore delle risorse:
• le informazioni delle identità sono replicate per ogni risorsa;
• l’aggiunta di una nuova risorsa comporta l’aggiunta di un’intera infrastruttura di accesso;
• la replica delle informazioni su molti sistemi significa dover gestire la
sicurezza in molti punti, quindi si ha un minor controllo sulla sicurezza;
e dal punto di vista dell’utente:
• ogni utente si trova ad avere credenziali di accesso diverse a seconda
della risorsa a cui vuole accedere;
• a causa delle numerose password che si ritrova, è più facile che un utente
scelga password troppo semplici o addirittura le annoti su foglietti, il
che implica una minor sicurezza per i suoi dati.
Allora il secondo metodo sembra quasi una soluzione a tutti i problemi
del primo, infatti l’amministrazione degli utenti viene fatta solo nell’infrastruttura centralizzata, eliminando tutti i problemi del fornitore di servizi,
16
e, siccome gli utenti sono mantenuti in un’unica infrastruttura, si ha una
sola chiave di accesso per ogni utente, evitando così la proliferazione delle
password. Nonostante questo si introducono però problemi non trascurabili,
tipici dei sistemi centralizzati: performance e affidabilità. Portando in una
sola infrastruttura tutta la gestione degli accesi è necessario innanzitutto
stimare il carico di richieste a cui sarà sottoposto, quindi dimensionare opportunamente l’intero sistema in modo che riesca a rispondere a tutte le richieste
in tempi sempre accettabili; l’altra problematica da prevedere e da risolvere
opportunamente è l’affidabilità, ovvero fare in modo che l’infrastruttura sia
sempre presente anche in caso di guasti accidentali o compromissione del
sistema.
Solitamente accade che da una situazione in cui ogni risorsa gestisce
autonomamente le identità e gli accessi si passi ad un sistema centralizzato
per via dei vantaggi all’intero sistema che porta quest’ultima soluzione. Uno
dei problemi di questo passaggio è il consolidamento delle identità digitali,
poiché può essere che le informazioni sugli utenti arrivino da più fonti. È
necessario prevedere allora una serie di meccanismi che unificano tutte le
informazioni in un’unica struttura, facendo particolare attenzione a quelle
identità digitali le cui informazioni possono arrivare da più fonti. Vediamo
allora quali sono i passi, in generale, da compiere per il consolidamento delle
identità:
1. Analizzare i database esistenti e vedere quali sono autoritativi.
2. Decidere quali informazioni prendere, mantenere ed eventualmente
aggiungere.
3. Consolidare (una persona può essere presente in più fonti) per creare
quella che chiamiamo identità digitale.
4. Tenere aggiornato automaticamente il database unificato.
.
I benefici ottenuti dal sistema dopo il consolidamento dell’identità sono
molteplici:
• I decision makers possono attivare cambiamenti più velocemente (per
esempio aggiungere una nuova risorsa, oppure modificare i privilegi di
accesso ad un gruppo di risorse).
17
• L’evoluzione dei requisiti si riflette nei cambiamenti che devono essere
fatti solo in un posto.
• Secondo EduCause (http://www.educause.edu) i costi di implementazione di nuove risorse sono ridotti del 30 per cento.
• Le decisioni prese si applicano in un punto e si vedono i risultati e le
conseguenze delle decisioni stesse.
• Il logging è consolidato pertanto si possono applicare regole di privacy,
di conservazione dei dati di auditing, si possono fare dei report, si
monitora la sicurezza in modo efficace.
• Si elimina il problema del deprovisioning (disattivazione) relativo alla
gestione delle identità in sistemi disgiunti.
• Si riduce il numero di credenziali da conoscere da parte dell’utente.
• L’organizzazione può modificare più velocemente i diritti di accesso
basandosi sui ruoli.
• Nel processo di garantire che una persona è “quello che dice di essere”
l’istituzione incrementa il suo livello di riservatezza.
Nell’Università di Parma attualmente si ha una situazione in cui alcune
risorse gestiscono in modo centralizzato gli accessi, ma in generale non si ha
una sistema centralizzato, poiché vi sono alcuni sistemi che che hanno una
gestione autonoma degli accessi. I dettagli della situazione attuale vengono
illustrati nel capitolo 4.
L’obiettivo finale dichiarato di una qualsiasi soluzione di IAM è comunque
quello di aumentare la produttività e la facilità d’uso del sistema informatico
da parte degli utenti finali, aumentare il livello generale della sicurezza,
diminuendo i costi associati alla gestione degli utenti e delle loro identità,
dei loro attributi e delle loro credenziali. In sintesi, si vuole fornire uno
strumento che supporti il processo che stabilisce chi ha accesso a quali risorse,
l’assegnazione delle autorizzazioni, la loro modifica o revoca quando necessario,
nonché la gestione del processo stesso ed il monitoraggio delle attività, nel
rispetto delle politiche di sicurezza.
18
2.2
IAM federato
Con il termine federazione si ci riferisce ad un insieme di organizzazioni,
enti o erogatori di servizi che decidono di creare delle relazioni di fiducia
tra loro per potersi scambiare informazioni sulle identità. Spesso si vuole
permettere ad utenti che appartengono ad una certa organizzazione di poter
accedere a servizi di altre organizzazioni che fanno parte di una federazione
comune, per fare questo le organizzazioni devono condividere meccanismi
per lo scambio di informazioni sugli utenti e per la gestione degli accessi
alle risorse che si vogliono condividere all’interno di una federazione. Con
IAM federato intendiamo la gestione delle identità e degli accessi a livello
di federazione, quindi non più limitata ad una singola organizzazione ma una
gestione che prevede il coinvolgimento di un insieme di organizzazioni.
Una AAI1 federata è una infrastruttura che permette ad un utente,
appartenente ad una organizzazione che fa parte di una federazione, di potersi
autenticare e poter accedere ai servizi offerti da altre organizzazioni (oltre
ovviamante alla sua di afferenza) interne alla federazione, utilizzando sempre
le stesse credenziali di accesso. Nella figura 2.3 è illustrata una federazione
senza una AAI: un utente ha una chiave d’accesso differente per ogni servizio
che richieda l’autenticazione, ed ogni organizzazione gestisce l’autenticazione
ai suoi servizi anche per utenti esterni, perciò diventa obbligata a gestire
in proprio anche le identità di utenti di altre organizzazioni, oltre ai suoi.
Con una AAI federata, illustrata in figura 2.4, il processo di autenticazione
viene gestito dalla AAI, in tal modo ogni utente possiede una chiave di
accesso unica valida per ogni servizio, e se un utente deve accedere ad un
servizio di un’organizzazione esterna, il processo di autenticazione viene
gestito dalla AAI, che preleva le informazioni necessarie dall’organizzazione
di appartenenza dell’utente.
Attraverso una AAI federata si riescono ad ottenere vari vantaggi:
• Possibilità di utilizzare sempre le credenziali della propria organizzazione.
• Maggiore privacy e controllo dei propri dati personali, poiché vengono
gestiti solamente dall’organizzazione di afferenza.
• Informazioni sempre aggiornate.
1
AAI: Authentication and Authorization Infrastructure
19
Figura 2.3: Federazione senza AAI.
• Minore carico amministrativo per la gestione delle identità e delle
credenziali.
• Più controllo sui sistemi di autenticazione e autorizzazione, quindi
maggior sicurezza.
• Scambio di informazioni e contenuti tra i “soci” più semplice.
• Accesso alle risorse online da ovunque all’interno della federazione.
Un sistema software, sempre più diffuso, che permette di implementare
una AAI federata è Shibboleth (che verrà ripreso più avanti), che però è
limitato solamente ad applicazioni WEB.
2.3
Identità e ciclo di vita dell’identità
Vediamo ora una definizione dettagliata di identità e cos’è il ciclo di
vita dell’identità.
20
Figura 2.4: Federazione con AAI.
2.3.1
Identità
L’identità digitale è l’insieme delle informazioni mantenute nel sistema
informatico che rappresentano un’entità che accede alle risorse concesse dal
sistema informatico stesso. Un’identità digitale è composta da:
• Dati anagrafici, ovvero le informazioni che descrivono l’entità associata e la identificano rispetto alla realtà. Queste informazioni possono
subire cambiamenti, ma in modo indipendente dai cambiamenti dell’entità rispetto all’organizzazione. Dati anagrafici possono essere cognome,
nome, data di nascita.
• Attributi, ovvero l’insieme delle informazioni sull’entità relative all’organizzazione, suddivisibili in:
– Ruoli istituzionali
– Incarichi
– Attributi per l’accesso (privilegi)
– Appartenenza a gruppi
21
• Credenziali di accesso, per esempio username e password, oppure
un certificato digitale. Utilizzate per accedere alle risorse informatiche,
possono cambiare per volontà dell’utente (ad esempio il cambio della
password) o in casi straordinari (ad esempio lo smarrimento di tali
credenziali).
Dalla definizione di identità data in precedenza si può notare che non è
escluso che utente possa avere più di un’identità digitale all’interno di un
sistema informatico, poiché il termine “entità” è molto generico ed un utente
potrebbe rappresentare più entità. La non univocità comporta, dal punto
di vista dell’utente, più account, quindi più credenziali, ma soprattutto, da
parte del sistema, comporterebbe una disastrosa gestione delle informazioni
riguardanti gli utenti in termini soprattutto di coerenza dei dati, per esempio
le modifiche apportate ad una identità dovrebbero essere propagate a tutte le
altre identità di quell’utente. Diviene quindi fondamentale trovare un gruppo
di attributi che da soli possano identificare senza ambiguità ogni utente, in
modo da potersi riferire a tale utente sempre attraverso tali attributi detti
chiave, creando in questo modo un’identità digitale unica per ogni utente.
2.3.2
Ciclo di vita delle identità
Un’identità, una volta entrata nel sistema, non rimane immutata per
sempre, ma può, ed in un sistema come quello universitario molto rapidamente,
subire dei cambiamenti a causa di alcune operazioni:
• Creazione di nuovi utenti ed assegnazione delle credenziali.
• Modifiche delle credenziali.
• Modifiche degli attributi a causa di promozioni, trasferimenti o in
generale cambi di ruoli.
• Cancellazione account.
La gestione del ciclo di vita delle identità comprende i processi e le
tecnologie che consentono l’implementazione, l’annullamento dell’implementazione, la gestione e la sincronizzazione di identità digitali. La riuscita della
gestione delle identità e dell’accesso si basa soprattutto sull’efficienza della
gestione del ciclo di vita delle identità digitali.
22
Figura 2.5: Ciclo di vita dell’identità.
L’insieme delle operazioni di amministrazione che portano alla definizione
degli account utente e all’attribuzione dei diritti di accesso in base al ruolo,
prende il nome di User Provisioning; una buona soluzione di IAM introduce
un sistema di gestione centralizzata di tutto il processo di amministrazione.
2.4
Accesso: autenticazione e autorizzazione
La gestione dell’accesso alle risorse è l’argomento principale di questo
testo, definiamo allora con precisione il significato di accesso. Con accesso
ad una risorsa si indica l’insieme delle operazioni di autenticazione e autorizzazione effettuate dal sistema informatico che permettono ad un utente
di utilizzare una risorsa resa disponibile dal sistema stesso.
Si presume quindi che un utente, per effettuare l’accesso ad una risorsa,
si identifichi presso il gestore di tale risorsa, il quale registra l’utente e gli
fornisce delle credenziali. L’utente utilizzerà le credenziali fornitegli per
accedere alla risorsa.
2.4.1
Autenticazione degli utenti
L’autenticazione è il processo che verifica l’identità di un utente in
modo da poter correttamente permettere o negare l’accesso a risorse condivise
e protette. Di fatto, tramite l’autenticazione, si associa un’utente con la
sua identità digitale presente nel sistema. Le tecniche di autenticazione
possono spaziare dal semplice login con username e password a meccanismi
più complessi e forti come token, certificati digitali a chiave pubblica o sistemi
23
biometrici. Una soluzione di IAM deve pertanto essere indipendente dal
meccanismo di autenticazione utilizzato in modo da potersi adattare ad ogni
specifica realtà tecnologica.
2.4.2
Autorizzazione
L’autorizzazione è il passo successivo dopo che un utente è stato autenticato. È il processo che consente l’accesso alle risorse solamente a coloro che
hanno i diritti di usarle. Durante l’autorizzazione vengono quindi valutati i
privilegi dell’identità digitale associata all’utente autenticato e viene consentito, limitato oppure impedito l’accesso alla risorsa, applicando opportune
regole stabilite in precedenza. In ambito universitario si può pensare, a
titolo d’esempio, ad una applicazione WEB per gestire gli esami: studenti
e professori si possono autenticare entrambi a questa risorsa, ma durante il
processo di autorizzazione si distinguono studenti da professori, ed i primi
potranno effetturare l’iscrizione agli esami, mentre i secondi potranno aggiungere, modificare o eliminare gli esami inseriti, ma chiaramente non dev’essere
possibile il contrario.
2.5
Implementare un server IAM
Nel paragrafo 2.1 abbiamo parlato di sistema IAM centralizzato,
descrivendo cos’è, a cosa serve e quali vantaggi porta, ma non ci siamo
soffermati su come sia possibile implementarlo realmente. Trattandosi di un
sistema centralizzato è evidente che sia necessaria una infrastruttura centrale
alla quale riferirsi, questa infrastruttura, indipendentemente da come poi
venga implementata, è il server IAM.
Un server IAM è una infrastruttura che permette di gestire e mantenere le
informazioni sulle identità digitali degli utenti in un unico punto centralizzato,
ed alla quale si riferiscono le risorse ed i servizi che fanno uso di queste
informazioni, ad esempio per gestire l’autenticazione e l’autorizzazione. Un
server IAM deve avere una serie di caratteristiche basilari:
• Deve memorizzare e mantenere grandi quantità di informazioni
dando la possibilità di organizzarle mediante schemi e attributi.
• Deve essere sicuro rispetto a problematiche di safety e di security,
quindi deve avere una serie di meccanismi per assicurare che i dati non
24
Figura 2.6: Server IAM.
vengano persi in caso di malfunzionamenti o guasti accidentali (safety)
e che non possano essere letti da persone malintenzionate (security).
• Deve essere affidabile, ovvero deve garantire la continuità di servizio,
rispettando le specifiche di funzionamento nel tempo.
• Deve essere performante nelle operazioni di lettura e nelle interrogazioni, poiché costituiscono la maggior parte di operazioni che vengono
effettuate su di esso.
• Deve essere possibile interfacciarlo, in modo relativamente semplice,
con le tecnologie di accesso che leggono le informazioni memorizzate, e
con procedure automatiche per l’inserimento dei dati provenienti dalle
fonti.
Eistono principalmente due strumenti che possiedono le precedenti caratteristiche: LDAP oppure i DBMS. Nei successivi paragrafi vengono
descritti entrambi e, come si vedrà, ognuno ha caratteristiche più o meno
marcate. È possibile utilizzarli singolarmente per implementare un server
25
IAM, ma una buona soluzione, come si potrà vedere più avanti nel progetto,
può essere quella di utilizzarli entrambi, in modo congiunto, sfruttando le
migliori caratteristiche di entrambi.
Di seguito non si vuole dare una spiegazione esaustiva dei due argomenti,
ma semplicemente introdurre i concetti che vengono poi ripresi all’interno
del progetto. Per una descrizione completa e accurata di LDAP e DBMS si
rimanda a testi specifici.
2.5.1
LDAP
LDAP (Lightweight Directory Access Protocol) è sostanzialmente
un protocollo di gestione e accesso a directory service. Un directory service
(servizio di directory) è utilizzato per associare nomi ad oggetti, dove ogni
oggetto è caratterizzato da una serie di attributi costituiti da una coppia nome
- insieme di valori. I directory service sono ottimizzati per effettuare ricerche
di oggetti, ricerche che possono avvenire in base al nome dell’oggetto, ma
anche per il valore di un dato attributo. In genere gli oggetti di un directory
service rappresentano un elemento dell’ambiente in cui viene utilizzato il
servizio, per esempio un utente, un computer, una stampante o una rete, ed
ogni oggetto conterrà una serie di attributi che servono per descrivere ciò
che rappresenta. Una directory è quindi un insieme di oggetti, e un directory
service è un servizio che ha lo scopo di gestire gli oggetti di una directory ed
effettuare ricerche su di essi.
In LDAP le informazioni vengono organizzate in modo gerarchico, in una
struttura ad albero, dove ogni nodo rappresenta un oggetto, chiamato entry.
Figura 2.7: Esempio di un albero delle entry (DIT).
L’albero delle entry è chiamato anche DIT (Directory Information Tree).
Ogni entry del DIT è identificata univocamente dal suo DN (Distinguished
Name), composto dalla concatenazione dei nomi dei suoi antenati fino alla
radice (figura 2.8).
26
Figura 2.8: Distinguished name (DN) di una entry.
Ogni entry è costituita da un insieme di coppie attributo-valore. L’attributo speciale ObjectClass definisce la struttura della entry, cioè quali
attributi sono presenti e quali di questi sono obbligatori (devono per forza
contenere un valore). Una object class è un insieme di attributi che hanno,
in genere, un significato comune. Per esempio l’object class person ha un
insieme di attributi che servono per descrivere una persona, come il nome,
il cognome o il numero di telefono. Nella definizione di una object class è
possibile indicare quali attributi sono obbligari e quali invece sono facoltativi.
Il valore dell’attributo speciale ObjectClass in una entry dev’essere il nome
di una object class, e la struttura della entry sarà composta dagli attributi
definiti in tale object class. La struttura di ogni entry è indipendente dagli
altri oggetti e dalla posizione in cui si trova nell’albero.
Figura 2.9: Possibile struttura di una entry.
27
Attributi
LDAP utilizza la sintassi X.500 per la definizione degli attributi. Per ogni
attributo sono specificati:
• OID (Object IDentifier): numero identificativo dell’attibuto, assegnato
gratuitamente da IANA.
• Nome: nome identificativo dell’attributo, con eventuali alias di seguito.
• Significato: breve descrizione dell’utilizzo dell’attributo.
• Sintassi: numero identificativo standard della sintassi utilizzata per il
valore dell’attributo.
• Regole di confronto: regola con cui confrontare il valore dell’attributo
in caso di ricerca.
• Molteplicità: indica se è possibile memorizzare più di un valore nell’attributo.
Due possibili definizioni di attributi sono le seguenti:
attributetype ( 2.5.4.4 NAME ( ’sn’ ’surname’ )
DESC ’RFC2256: last (family) name(s)
for which the entity is known by’
SUP name )
attributetype ( 2.5.4.5 NAME ’serialNumber’
DESC ’RFC2256: serial number of the entity’
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.44{64} )
Il primo utilizzato per contentere il cognome di una persona, il secondo
per un eventuale numero di serie dell’entità rappresentata dalla entry.
Object class
Anche per la definizione delle object class viene utilizzata la sitassi X.500.
Per ogni object class sono specificati:
28
• OID: numero identificativo della classe, assegnato gratuitamente da
IANA.
• Descrizione: breve descrizione del significato dell’object class.
• Categoria: può essere abstract, auxiliary oppure structural. Ogni entry
deve avere almeno una object class structural, e non può avere solo
object class auxiliary. Una object class abstract invece può essere usata
solamente per derivare altre object class.
• Attributi obbligatori: elenco di attributi che devono esistere nella entry.
• Attributi opzionali: elenco di attributi che possono esistere nella entry.
Due possibili definizioni di object class:
objectclass ( 2.5.6.2 NAME ’country’
DESC ’RFC2256: a country’
SUP top STRUCTURAL
MUST c
MAY ( searchGuide $ description ) )
objectclass ( 2.5.6.3 NAME ’locality’
DESC ’RFC2256: a locality’
SUP top STRUCTURAL
MAY ( street $ seeAlso $ searchGuide $ st $
l $ description ) )
Schema
Uno schema è un insieme di definizioni di attributi e object class. Esistono
alcuni schemi standard, per esempio RFC4519, ma in generale è possibile
definire un proprio schema personalizzato.
Alcune organizzazioni realizzano e promuovono i loro schemi in modo da
standardizzare l’utilizzo di alcuni attributi comuni e favorire la realizzazione
di strutture federate, per esempio Internet2 ha realizzato lo schema eduPerson,
utilizzabile per descrivere le persone in ambiente universitario.
29
LDIF
LDIF (LDAP Data Interchange Format) è un formato standard per
rappresentare le informazioni contenute in una directory in un file di testo. È
utilizzato per importare, esportare o modificare i dati di un directory service.
Un file LDIF è composto da un’insieme di entry semparate da linee vuote.
Per ogni entry vengono rappresentati gli attributi nella forma “nome attributo:
valore”. Il seguente esempio rappresenta due differenti entry in formato LDIF:
dn: cn=giorgio,ou=people,dc=organization,dc=it
cn: giorgio
objectClass: person
objectClass: inetOrgPerson
objectClass: posixAccount
mail: [email protected]
telephoneNumber: +3905219029850
dn: cn=giovanni,ou=people,dc=organization,dc=it
cn: giovanni
sn: verdi
objectClass: person
objectClass: inetOrgPerson
objectClass: posixAccount
mail: [email protected]
Access Control List
In un server LDAP sono spesso contenuti dati riservati o comunque dati
a cui va limitato l’accesso. Per fare questo è possibile definire delle ACL
(Access Control List), mediante le quali si possono gestire le autenticazioni al
server stesso, andando a reperire le informazioni di autenticazione (in genere
username e password) dalle entry che rappresentano gli utenti. È possibile
anche definire le modalità di accesso (lettura o scrittura) e la granularità,
dall’intera directory al singolo attributo.
Vantaggi di LDAP
Un directory service LDAP è particolarmente adatto per implementare
una infrastruttura centralizzata per la gestione delle identità: permette di
30
rappresentare facilmente gli utenti e i loro attributi, la struttura basata su
schemi è facilmente estendibile e modificabile, è un servizio ottimizzato per
le letture e le ricerche che costituiscono sicuramente la maggior parte delle
operazioni in questo tipo di infrastrutture, ed è ormai supportato da tutte le
principali tecnologie per la gestione dell’accesso. Inoltre è possibile stabilire
connessioni sicure tra client e server con TLS, e definire delle ACL per limitare
l’accesso alle informazioni mantenute nel server. LDAP è quindi un’ottima
soluzione, ha vantaggi notevoli anche in termini di sicurezza, è sempre più
diffuso e stà diventando ormai uno standard nella gestione centralizzata degli
utenti.
Per quanto riguarda le implementazioni di server LDAP, ne esistono
diverse, fra quelle proprietarie ricordiamo DSEE (Directory Server Enterprise
Edition) di SUN, eDirectory di Novell e Active Directory di Microsoft, mentre
le più diffuse implementazioni libere sono Fedora Directory Server, OpenDS,
Apache DS e OpenLDAP.
2.5.2
Database e DBMS
Il termine database (detto anche banca dati o base di dati) indica un
archivio di dati e informazioni, strutturato in modo tale da consentire la
gestione dei dati stessi (l’inserimento, la ricerca, la cancellazione ed il loro
aggiornamento) da parte di applicazioni software.
Informalmente e impropriamente, la parola database viene spesso usata
come abbreviazione di Data Base Management System (DBMS), che
si riferisce invece a una vasta categoria di sistemi software che consentono
la creazione e la manipolazione efficiente di database. Più precisamente
un DBMS lo si può definire come un sistema software in grado di gestire
grandi collezioni di dati in modo condiviso, assicurando la loro persistenza,
affidabilità e privatezza. Come ogni prodotto informatico, un DBMS deve
essere efficente ed efficace. Un database è quindi una collezione di dati gestita
da un DBMS.
Vediamo nei dettagli le caratteristiche di database e DBMS:
• I database possono essere grandi, nel senso che possono essere di dimensioni molto superiori alla memoria centrale, di conseguenza i DBMS
devono prevedere una gestione dei dati in memoria secondaria.
31
• Un database può essere condiviso nel senso che applicazioni diverse
possono accedere, secondo opportune modalità, a dati comuni. Attraverso la condivisione si possono ridurre le repliche dei dati, infatti le
applicazioni possono accedere ad un database comune e condiviso senza
necessità di mantenersi una copia dei dati, in questo modo si evitano le
incosistenze.
• I database sono persistenti, cioè hanno un tempo di vita che non è
limitato a quello delle singole esecuzioni dei programmi che li utilizzano.
• I DBMS garantiscono l’affidabilità, cioè la capacità del sistema di
conservare intatto il contenuto del database (o almeno di permetterne
la ricostruzione) in caso di malfunzionamenti harware e software.
• I DBMS garantiscono la privatezza dei dati, dando la possibilità di
impostare meccanismi di autenticazione e autorizzazione al DBMS
stesso.
• Per efficenza intendiamo la capacità di svolgere le operazioni utilizzando
un insieme di risorse (tempo e spazio) che sia accettabile. I DBMS
forniscono un insieme piuttosto ampio di funzionalità che richiedono
molte risorse, e quindi possono garantire efficenza solo a condizione
che il sistema informatico su cui sono installati sia adeguatamente
dimensionato.
• Per efficacia intendiamo la capacità dei database di rendere produttive,
in ogni senso, le attività di chi le utilizza. Questa definizione è abbastanza generica poiché esistono diversi DBMS che offrono funzionalità
differenti. L’attività di progettazione del database e delle applicazioni
che lo utilizzano mira essenzialmente a garantire una buona efficacia
del sistema.
Attualmente esistono molte implementazioni di DBMS. Limitando l’attenzione ai database relazionali2 , quindi agli RDBMS, che sono senza dubbio i
più diffusi e quelli utilizzati nel nostro progetto, citiamo le tre implementazioni più famose: Oracle, MySQL e PostgreSQL. Il primo è un sistema chiuso,
2
Il modello relazionale è un modello logico di rappresentazione dei dati implementato
sui DBMS, detti perciò sistemi di gestione di database relazionali (RDBMS). Esso si basa
sull’algebra relazionale e sulla teoria degli insiemi ed è strutturato attorno al concetto di
relazione (detta anche tabella).
32
con costi di licenza molto alti, che ha presentato in passato vari problemi
in termini di sicurezza, ma resta il più diffuso nelle grandi organizzazioni.
MySQL e PostgreSQL sono invece due progetti open-source, il primo è un
sistema semi-aperto mentre PostgreSQL è un sistema completamente aperto,
entrambi non hanno costi di licenza e, nonostante non costino nulla, sono due
ottimi RDBMS, in continuo sviluppo e supportati da due grandi comunità.
Vantaggi dei DBMS
Concludiamo con un breve riassunto dei vantaggi di database e DBMS:
• I DBMS permettono di considerare i dati come una risorsa comune di
una organizzazione, a disposizione (con opportune forme di controllo)
di tutte le sue componenti.
• I database forniscono un modello unificato e preciso della parte del mondo reale di interesse per l’organizzazione, utilizzabile nelle applicazioni
attuali e, con possibili estensioni, in applicazioni future.
• Con l’uso di un DBMS è possibile un controllo centralizzato dei dati.
• La condivisione permette di ridurre ridondanza e inconsistenze.
• L’indipendenza dei dati, caratteristica fondamentale dei DBMS, favorisce lo sviluppo di applicazioni più flessibili e facilmente modificabili.
L’importanza che i dati (e quindi le informazioni) vengano gestiti nel
modo più corretto, efficace ed efficente possibile è ovviamente fondamentale
per una qualunque organizzazione (ed in particolar modo per un’università)
dove vi è la necessità di gestire un elevato numero di utenti, garantendo che il
sistema informatico funzioni praticamente sempre e non si vuole che vi siano
inconsistenze o errori sui dati.
33
34
Capitolo 3
Gestione dell’accesso
3.1
Cosa significa gestire l’accesso
La gestione dell’accesso è quella parte del sistema IAM che si occupa
di fornire una soluzione al problema dell’autenticazione e dall’autorizzazione
degli utenti ad ogni risorsa del sistema informatico, prelevando le informazioni
necessarie dalla parte del sistema IAM che gestisce le identità digitali.
Gestire l’accesso di un sistema informatico significa quindi trovare una
tecnologia appropriata, o un insieme di tecnologie, che permetta di fornire
l’accesso ad ogni risorsa informatica. Nel progetto di questo documento si
vuole realizzare una gestione centralizzata dell’accesso, percui un sistema in
cui le identità digitali degli utenti e le loro credenziali di accesso vengono
mantenute in un’unica infrastruttura centralizzata (il server IAM), e la
gestione dall’accesso di ogni risorsa preleva le informazioni necessarie da questa
infrastruttura. L’esempio più semplice è avere una sola risorsa all’interno
del sistema informatico e voler permettere agli utenti di accedervi dopo
l’inserimento di username e password; tutti gli username e le password degli
utenti sono mantenuti nel server IAM, quando un utente prova ad accedere
alla risorsa, questa li preleva e li confronta con quelli inseriti dall’utente al
momento dell’autenticazione, per consentire o negare l’accesso alla risorsa. La
parte in cui viene stabilito che per accedere alla risorsa è necessario inserire
username e password, la scelta di mantenere le credenziali in un server IAM
e la modalità con cui queste vengono prelevate, fanno parte della gestione
dell’accesso. Ovviamente con una sola risorsa non si apprezza la scelta del
server IAM, il progetto consiste nell’estendere il ragionamento a più risorse
35
non omogenee, senza stabilire a priori un metodo di autenticazione.
Nei due paragrafi successivi vengono definiti meglio i concetti di risorsa
informatica e tecnologia, dando degli esempi reali di entrambi.
3.2
Le risorse informatiche
Con il termine risorsa informatica (o brevemente risorsa) intendiamo
un componente fisico o virtuale del sistema informatico dell’organizzazione,
reso disponibile ad un insieme di utenti registrati, ovvero di cui si conosce
l’identità. Esempi di risorse sono la posta elettronica, un computer oppure
una rete locale.
Di seguito vengono introdotte le principali risorse informatiche, disponibili
all’interno di praticamente ogni università. Con una gestione delle identità e
dell’accesso appropriata si può fare in modo che l’utente finale possa accedere
a tutte le risorse descritte di seguito utilizzando sempre le stesse credenziali
di accesso, indipendentemente dai ruoli ricoperti.
Nel paragrafo successivo (3.3) vengono illustrate le tecnologie per gestire
l’accesso alle risorse informatiche.
3.2.1
WiFi
In molte realtà può essere comodo, se non indispensabile, accedere alla
rete locale e alla rete Internet senza essere costretti ad attaccare un cavo al
computer; basti pensare ai luoghi all’aperto nei quali si vuol dare la possibilità
di arrivare con il proprio portatile, accenderlo ed essere immediatamente
connessi alla rete, oppure negli edifici storici dove diventa impossibile, non
potendo toccare la struttura dell’edificio, stendere una rete con cavi, ma
anche semplicemente in una università, per permettere ad ogni studente con
un portatile (ma anche con cellulari o palmari che supportano l’accesso alla
rete) di poter accedere alla rete universitaria da ogni aula di studio senza
dover stendere cavi di rete in ogni stanza, oltretutto risparmiando anche sul
costo dei cavi e dell’impianto. Tutto questo è possibile attraverso una LAN
wireless (indicata anche con la sigla WLAN), ovvero una rete locale “senza
fili”.
La tecnologia wireless si sta difondendo rapidamente soprattutto per la
possibilità di fornire servizi di rete ad un costo ridotto, in quanto supera
la necessità di costruire fisicamente una rete cablata; il successo di questa
36
tipologia di rete è sicuramente dovuto alle buone prestazioni raggiunte (fino
a 54 Mbps), che le permettono di competere con una economica rete cablata.
Siccome è molto importante che tutti i dispositivi wireless siano compatibili, altrimenti potrebbe succedere che un portatile con una scheda wireless
di una certa marca non possa accedere ad una WLAN perché la stazione
base è di un’altra marca, il comitato IEEE ha creato lo standard 802.11 per
questo tipo di reti, chiamato anche WiFi (Wireless Fidelity). Lo standard
802.11 può funzionare in due modi:
1. Con stazione base (rete strutturata).
2. Senza stazione base (rete ad hoc).
Nel primo caso tutte le comunicazioni passano attraverso la stazione
base, chiamata access point (AP), mentre nel secondo caso i computer
comunicano direttamente tra di loro. Il modo con stazione base è sicuramente
il più utilizzato quando si deve implementare una rete locale permanente, e
unire ad una rete cablata i vantaggi del WiFi; il modo senza stazione base è
invece, in genere, usato per lo scambio di file (con una connessione modello
peer to peer) o quando si necessita di una piccola rete per breve tempo (ad
esempio per riunioni, convegni, stand o dimostrazioni).
Una rete wireless può quindi essere l’estensione ad una normale rete
cablata, supportando, tramite access point, la connessione a dispositivi
mobili (computer portatili con scheda di rete wireless o palmari predisposti).
In generale le architetture di questo tipo sono basate su due tipologie di
dispositivi (figura 3.1):
• Access Point (AP)
• Wireless Terminal (WT)
Gli access point funzionano da bridge e collegano la sottorete wireless con
quella cablata, mentre i wireless terminal sono i dispositivi che usufruiscono
del servizio di rete wireless. In modo simile ad una rete cellulare è possibile
all’interno di una WLAN il roaming tra access point (figura 3.2), ovvero la
sovrapposizione di una parte di segnale tra due AP in modo da suddividere
lo spazio in celle (chiamate anche BSS, Basic Service Set), ognuna gestita da
un AP.
37
Figura 3.1: Schema di una rete wireless collegata ad una rete wired
Quando un WT viene acceso in una WLAN, all’interno di una cella gestita
da un AP, per prima cosa effettua lo scanning, ovvero cerca di ottenere
informazioni per connettersi all’AP. Lo scanning può essere di due tipi:
• Scanning passivo: ogni AP trasmette periodicamente il suo SSID1
(Service Set IDentifier, è il nome identificativo di una rete WiFi); il WT
si mette in ascolto per catturare un SSID e poter quindi effettuare la
connessione all’AP.
• Scanning attivo: il WT invia pacchetti sonda (Probe Packets) contenenti
il SSID dell’AP; quando un AP riceve uno di questi pacchetti controlla
se il SSID coincide con il suo, in tal caso invia al WT un pacchetto
di risposta contenente una serie di informazioni per associarsi all’AP,
altrimenti ignora il pacchetto ricevuto.
A volte viene utilizzato proprio il SSID come metodo di gestione dell’accesso ad una rete WiFi: attraverso lo scanning attivo si mantiene il SSID
nascosto, e solamente chi lo conosce (si presuppone solo utenti fidati) può
associarsi all’access point. È però evidente che questo non è un metodo sicuro,
che al massimo può evitare che un utente si connetta “accidentalmente” alla
rete, basta infatti catturare un paio di pacchetti di una trasmissione WiFi
per estrapolarne il SSID e riuscire così a connettersi all’access point.
1
In realtà viene spedito un pacchetto di sincronizzazione, chiamato Beacon Frame, che
contiene diverse informazioni sull’AP oltre al SSID.
38
Figura 3.2: Roaming tra access point
3.2.2
VPN
Una VPN (Virtual Private Network) è una rete privata che sfrutta
infrastrutture pubbliche, come Internet, per interconnettere diverse reti o
computer tra loro. Le VPN più utilizzate sono ovviamente quelle che sfruttano
la rete Internet, queste infatti permettono, a chiunque abbia un collegamento
DSL, di poter creare una rete privata anche tra host geograficamente molto
distanti tra loro. Esistono due tipi di VPN: site-to-site e remote access.
Le site-to-site sono VPN instaurate tra due reti, per esempio tra due sedi
distaccate di una stessa azienda per le quali si vuole usare una rete privata
unica. Con remote access, invece, si intende il collegamento di un singolo
computer ad una rete privata tramite VPN. Siccome in questo testo di vuol
parlare di risorse per gli utenti, quando si parla di VPN si ci riferisce solamente
a quast’ultima modalità.
Figura 3.3: Remote Access VPN su rete Internet
39
Una VPN permette quindi ad un utente con un collegamento a Internet di
connettersi ad una rete privata come se si trovasse fisicamente al suo interno.
Questo viene fatto creando un tunnel virtuale nella rete pubblica nel quale
viene trasportato il traffico di rete come se si trattasse di un collegamento
fisico (figura 3.3). Il tunnel è fatto con protocolli che impacchettano (e in
genere cifrano) il frame che dovrebbe viaggiare nella rete privata, lo portano
da un estremo all’altro della connessione VPN attraverso la rete publica, e lo
spacchettano nella rete privata in modo trasparente per l’utente e per la rete
privata.
È evidente che una VPN che si appoggia ad Internet deve prevedere
sistemi di crittografia per garantire l’integrità e l’autenticità dei pacchetti
trasmessi e che i dati restino privati e indecifrabili durante il tragitto in
Internet, e metodi sicuri di autenticazione per impedire che utenti sconosciuti
possano accedere ad una rete privata.
3.2.3
Posta elettronica
La posta elettronica (o e-mail) è, con ogni probabilità, la risorsa
informatica più utilizzata dagli utenti. Permette di scrivere e ricevere messaggi
digitali di praticamente ogni formato, non solo testo. Ciascun utente può
possedere una o più caselle e-mail, su cui può ricevere messaggi che vengono
conservati. Quando lo desidera, l’utente può consultare il contenuto della
sua casella, organizzarlo, inviare messaggi a uno o più utenti. L’accesso
alla casella di posta elettronica dev’essere ovviamente controllato da qualche
forma di autenticazione, soprattutto quando l’accesso alle caselle di posta
può avvenire tramite Internet.
I componenti fondamentali del servizio di posta elettronica sono:
• Il client (MUA, Mail User Agent), utilizzato per accedere ad una casella
di posta elettronica e per inviare messaggi.
• Il server, che svolge due funzioni fondamentali: invia e recapita i
messaggi (MTA, mail transfer agent), e permette ad un client di accedere
e gestire la propria casella di posta (MAA, mail access agent).
I protocolli tipicamente impiegati per lo scambio di e-mail sono SMTP, usato
per l’invio, la ricezione e l’inoltro dei messaggi, e POP o IMAP, usati per la
ricezione e consultazione dei messaggi.
40
Il client può essere una applicazione (ad esempio Thunderbird) opportunamente configuarata per accedere al server di posta, ma è anche molto
diffusa la possibilità di consultare una casella e-mail attraverso il web.
3.2.4
Risorse web
Con risorse web intendiamo tutte le risorse accessibili attraverso un
browser web. Sotto questa categoria possono finire le più svariate risorse,
come iscrizioni on-line ad esami, forum o accesso alla casella e-mail. Questa
diffusione è dovuta ai diversi vantaggi che hanno le applicazioni web:
• Basta semplicemente un browser web per poterle utilizzare, senza dover
installare nessuna ulteriore applicazione, il che le rende indipendenti
dal sistema operativo utilizzato dal lato del client.
• Chiunque, con una connessione a Internet, ne può usufruire. Da
un computer, ma anche con cellulari o palmari, in qualunque luogo
geografico.
• Sono molto scalabili in termini di servizi e prestazioni, infatti si possono
modificare, il server può essere aggiornato o ingrandito, il tutto senza
“toccare” il client.
• Il continuo sviluppo di nuove tecnologie web porta sempre più in alto
le potenzialità di queste applicazioni.
Grazie a questi vantaggi ormai buona parte delle risorse informatiche
disponibili in una università sono risorse web. Diventa chiaramente fondamentale gestirne l’accesso, e che questa gestione sia particolarmente robusta e
sicura, per via della semplicità con cui si può accedere a queste risorse, e per la
riservatezza che molte di queste risorse devono garantire, ad esempio l’accesso
alla casella e-mail deve essere autenticato e possibilmente la trasmissione
dev’essere cifrata.
3.2.5
Postazioni computer
Altre risorse, ormai indispensabili in ogni università, sono le postazioni
computer, ovvero dare ad un utente la possibilità di accedere ad un PC, per
avere un suo spazio di memoria fissa dove gestire dei propri dati, per consentire
l’utilizzo di applicativi software specifici resi disponibili dall’università, per
41
svolgere laboratori informatici, ma anche, semplicemente, per dare l’accesso
ad Internet o alle risorse precedentemente illustrate.
La gestione dell’accesso ai PC si può suddividere in base al sistema
operativo: in genere i più utilizzati sono windows e linux, per i quali, come si
vedrà in seguito, si devono utilizzare metodi e tecnologie di accesso differenti.
3.3
Soluzioni e tecnologie per l’accesso
Una tecnologia è una soluzione, software, hardware o anche semplicemente concettuale, ad un certo problema. Di seguito vengono illustrate le
tecnologie per l’accesso, ovvero le tecnologie che risolvono il problema
dell’accesso, cioè che permettono di gestire l’autenticazione e l’autorizzazione
alle risorse informatiche.
3.3.1
Username e password
La prima soluzione per gestire l’accesso ad una risorsa, la più semplice,
ma anche la più diffusa, è senza dubbio la coppia username-password.
Lo username definisce il nome con il quale l’utente viene riconosciuto
all’interno del sistema informatico, dev’essere quindi un nome identificativo
e univoco. Come venga stabilito dipende dal sistema in cui si ci trova, può
essere deciso dall’utente al momento della registrazione, oppure, per motivi
di chiarezza e coerenza, può essere composto dall’organizzazione stessa, ad
esempio dalla sequenza nome.cognome.
Una password è una sequenza di caratteri alfanumerici che, assieme allo
username, rappresenta le credenziali di accesso per una risorsa informatica.
Mentre lo username è un nome pubblico, con cui si viene riconosciuti nel
sistema, la password dovrebbe rimanere segreta, addirittura non dovrebbe
neanche essere mantenuta nel sistema stesso, ma dovrebbe essere mantenuta
una copia criptata con un algoritmo hash (ad esempio MD5) in modo da
poterla confrontare con la password originale al momento dell’autenticazione,
ma non di poter risalire ad essa. La password si riconosce nel paradigma di
autenticazione “qualcosa che sai”.
L’autenticazione con username e password non è sicuramente fra i metodi più sicuri poiché lo username è un nome conosciuto e la password è
una semplice sequenza di caratteri che può essere, più o meno facilmente,
individuata. Per evitare questo, un’organizzazione può stabilire una serie di
42
politiche di gestione delle password per rendere il sistema informatico più
sicuro, ad esempio può obbligare gli utenti a scegliere password complicate
e a cambiarle periodicamente. Alcune norme elementari di sicurezza per la
scelta della password sono le seguenti:
• Nel determinare una password è da evitare l’uso di parole ovvie (come
il proprio nome o cognome o altri dati anagrafici), di senso compiuto
o direttamente associabili all’account (come l’username stesso) come
anche di parole troppo brevi (di solito per le password viene stabilito un
numero minimo di caratteri dal momento che all’aumentare del numero
di caratteri aumenta esponenzialmente il numero delle disposizioni
possibili).
• È preferibile utilizzare una password complessa e sforzarsi di memorizzarla piuttosto che sceglierne una di facile memorizzazione ma di più
facile determinazione.
• È da evitare l’utilizzo di parole presenti nei dizionari, come anche
anagrammi o combinazioni delle stesse (tale tipo di password sono quelle
più facilmente attaccabili mediante attacchi a forza bruta), mentre è
consigliabile utilizzare combinazioni del maggior numero possibile di
“tipi” di caratteri: maiuscoli, minuscoli, numeri e caratteri speciali.
• È buona norma variare le password utilizzate dopo un tempo determinato e non utilizzare la medesima password per più risorse.
3.3.2
Single Sign On
Il Single Sign On (SSO) è una sistema di autenticazione che prevede
che un utente fornisca le credenziali di accesso una sola volta, dopodiché
possa accedere a tutte le risorse che fanno parte del sistema informatico senza
doversi ri-autenticare.
I benefici sono molteplici, dal punto di vista dell’amministratore, il quale
ha un maggiore controllo sull’accesso che viene concentrato in un solo punto,
e dal punto di vista dell’utente, che non è più costretto ad autenticarsi a
diverse risorse o a ricordarsi una serie di credenziali di accesso differenti.
Grazie a questo ne deriva anche una sicurezza migliore, in quanto l’utente
potrà tenere traccia di una sola password, anche complessa, senza il bisogno
di annotarla su qualche foglietto. Oltre ad essere particolarmente comodo
43
per l’utente è anche molto sicuro, poiché vengono scambiati dati riservati una
sola volta e non ad ogni accesso ad una risorsa.
Questo modello di autenticazione è particolarmente utilizzato nei servizi
web, dove viene molto bene implementarlo attraverso l’utilizzo dei cookie.
Due implementazioni di SSO per risorse web sono CAS e Shibboleth,
quest’ultimo nato soprattutto per supportare anche ambienti federati.
3.3.3
RADIUS
RADIUS (Remote Authentication Dial-In User Service) è un protocollo
di rete utilizzato per controllare e gestire l’autenticazione, l’autorizzazione e
l’accounting a servizi remoti. Questo protocollo, ormai diventato uno standard
de-facto per questo tipo di problemi, è utilizzato da ISP, reti wirless, access
point, VPN e, in generale, da ogni servizio di rete che fornisce un sistema
di AAA (authentication, authorization, accounting). Un server RADIUS ha
quindi tre compiti:
• Autenticazione: consiste nell’identificazione dell’utente; può essere fatta
attraverso username e password, oppure utilizzando il protocollo di
autenticazione EAP che permette diversi altri modi, come certificati
digitali o Kerberos.
• Autorizzazione: dopo aver identificato l’utente il server RADIUS può
stabilire cosa è permesso fare all’utente. Per esempio può stabilire
il tempo o la quantità di servizio erogato, ma anche parametri più
specifici.
• Accountig: dopo il processo di autorizzazione il server RADIUS può
tracciare cosa l’utente stà facendo, mantenendo, per esempio in un
database, un log delle attività dell’utente.
Autenticazione
Il processo di autenticazione tramite un server RADIUS avviene nel
seguente modo:
1. Il client crea ed invia un messaggio Access-Request, contenente la
richiesta di autenticazione con le credenziali di accesso (diverse in base
al protocollo di autenticazione utilizzato).
44
2. Il server riceve il messaggio Access-Request; siccome server e client
devono condividere una chiave segreta comune, se il server RADIUS
non possiede la chiave segreta per il client, ignora “silenziosamente” il
messaggio ricevuto, altrimenti consulta le informazioni degli utenti per
verificarne le credenziali di accesso: se sono valide invia un messaggio
al client in cui conferma l’autenticazione (Access-Accept), se non sono
valide invia un messaggio di errore (Access-Reject).
3. Durante una sessione di autenticazione, in ogni messaggio spedito vi è
un valore identificativo casuale generato in partenza dal client, utilizzato,
insieme al segreto condiviso, per garantire l’autenticità e l’integrità dei
messaggi trasmessi.
4. Quando il client riceve il messaggio di risposta dal server, per prima cosa
ne verifica l’autenticità attraverso l’identificativo e il segreto condiviso,
se la verifica fallisce viene scartato il messaggio, altrimenti il client si
considera autenticato al servizio.
Autorizzazione
Una volta identificato l’utente i suoi dati vengono passati al modulo
di autorizzazione, che deve stabilire cosa l’utente può fare o meno. Ad
esempio, nel caso di una connessione Internet si può stabilire quale indirizzo
IP utilizzare, qual’è la durata massima di una sessione e il traffico massimo
che può essere fatto. Da un punto di vista prettamente di networking
è possibile impostare regole di filtraggio di indirizzi IP, impostazione del
routing, limitazioni di ampiezza della banda, utilizzo di comunicazioni con
crittografia, e tanto altro ancora. È possibile andare a prelevare i dati di
autorizzazione direttamente dai database, rendendo infinite le possibilità di
utilizzo di questo modulo.
Sicurezza
RADIUS supporta diversi metodi di autenticazione; il più semplice è
quello tramite username e password, la password viene cifrata con l’algoritmo
di hashing MD5 utilizzando anche il segreto condiviso, questa soluzione è
molto semplice ma offre un livello di sicurezza non elevato: MD5 (e in generale
tutti gli algoritmi hash) non è considerato un metodo altamente affidabile
45
perché vulnerabile agli attacchi basati su dizionario, ovvero se si riescono
ad intercettare i messaggi di richiesta e risposta si può provare (off-line)
a ripetere l’algoritmo utilizzato da client e server per generare i messaggi,
utilizzando parole di un dizionario come password, fino a quando i messaggi
di richiesta e risposta non coincidono, a quel punto si è trovata la password.
Per avere un livello di sicurezza maggiore si possono utilizzare protezioni
addizionali, come un tunnel IPsec, per cifrare il traffico tra client e server
RADIUS.
Un metodo di autenticazione più sicuro e molto usato è MSCHAPv22 ,
che però utilizza comunque algoritmi di hash per cifrare le password, ma se
integrato con il protocollo MPPE (Microsoft Point-to-Point Encryption) per
la cifratura del traffico raggiunge un buon livello di sicurezza.
Un’alternativa per garantire un elevato livello di sicurezza ed utilizzare
credenziali diverse da username e password, è utilizzare il protocollo EAP
che rende RADIUS capace di lavorare con diversi schemi di autenticazione,
come chiave pubblica, smart-card e Kerberos. Attraverso il protocollo EAP
si può negoziare il metodo di autenticazione, i principali sono i seguenti:
• EAP-MD5: equivalente a CHAP, viene utilizzato l’algoritmo di hash
MD5 e un segreto condiviso. Come già detto MD5 non è considerato
un buon metodo per avere un alto livello di sicurezza perché può essere
vulnerabile ad attacchi di tipo dizionario. È basato su password e
username, ed offre soltanto l’autenticazione lato client (ovvero, il client
viene autenticato alla rete).
• EAP-TLS: attraverso TLS (Transport Layer Security) si può effettuare
l’autenticazione con certificati X.509 lato client. È supportata la mutua
autenticazione (client e server sono reciprocamente sicuri dell’identità
dell’altro), e chiavi di sessione dinamiche. TLS è un’ottima scelta quando si vuole un elevato livello di sicurezza ed è presente una infrastruttura
a chiave pubblica.
• EAP-TTLS: Tunnelled Transport Layer Security (TTLS) è un’estensione del TLS sviluppata per superare la necessità di certificati lato
client (sono invece richiesti certificati lato server). TTLS è un metodo
a due passaggi. Nel primo si crea un tunnel di crittazione simmetrica
2
Microsoft CHAP v2 è un protocollo di autenticazione sviluppato da Microsoft che
deriva direttamente dal CHAP.
46
tra client e server. Il secondo passaggio riguarda la verifica dell’identità
del client utilizzando un’altro metodo di autenticazione all’interno del
tunnel di crittazione simmetrica. Questo secondo metodo di autenticazione, utilizzato con il tunnel, può essere un tipo di EAP (spesso MD5)
o un metodo di vecchio tipo come CHAP o MS-CHAPv2. Il tunnel
a crittazione simmetrica del TTLS è utilizzato solo per proteggere il
metodo di autenticazione del client. Una volta verificato, il tunnel viene
eliminato.
• PEAP: è uno standard aperto ideato da Cisco Systems, Microsoft e RSA
Security, e fornisce un elevato livello di sicurezza. È molto simile a EAPTTLS, richiede solo il certificato lato server e crea un tunnel sicuro
con TLS per proteggere l’autenticazione dell’utente, autenticazione
effettuata utilizzando altri metodi come MS-CHAPv2 (PEAP/EAPMSCHAPv2) basati su username e password.
freeRADIUS
Vale la pena citare freeRADIUS: una implementazione open source di
RADIUS, giunto alla versione 2.1.0, è il più popolare server RADIUS in
circolazione. freeRADIUS offre tutte le funzionalità offerte dai software
commerciali, offre il supporto per LDAP, MYSQL, PostgreSQL, Oracle;
gestisce autenticazioni EAP (EAP-MD5, EAP-SIM, EAP-TLS, EAP-TTLS,
EAP-PEAP), MSCHAP, MSCHAPV2, Cisco LEAP, oltre ai classici PAP e
CHAP.
Diameter
Diameter è il protocollo successore di RADIUS, per ora ancora poco
utilizzato, ma destinato a rimpiazzarlo. È basato su RADIUS, ma non è
compatibile, aggiunge nuove funzionalità in termini di sicurezza, efficenza e
controllo degli errori. Inoltre utilizza TCP, mentre RADIUS utilizza UDP, il
che lo rende più sicuro ed affidabile.
3.3.4
Kerberos
Kerberos è un protocollo di autenticazione sviluppato presso il MIT,
che fornisce un meccanismo per una mutua autenticazione (entrambi sono
47
certi dell’identità dell’altro) tra client e server o tra due server. Il protocollo
assume che le transizioni iniziali tra client e server avverranno in una rete
insicura, anche sotto il monitor di qualche utente malintenzionato, sia essa
una intranet o Internet.
Il sistema di autenticazione Kerberos è composto da tre elementi: il Key
Distribution Center (KDC), l’utente e l’application server (ovvero dove risiede
la risorsa) a cui l’utente vuole accedere. Il KDC svolge due funzioni principali:
l’Authentication Service (AS) e il Ticket Granting Service (TGS).
Figura 3.4: Scambio di ticket per l’autenticazione con kerberos.
Come si può vedere nella figura 3.4, lo scambio di chiavi dell’utente avviene
in tre fasi: AS Exchange, TGS Exchange e Client/Server (CS) Exchange.
Quando l’utente effettua un’autenticazione alla rete, esso deve immettere
username e password in modo da essere verificato dall’AS che fa parte del
KDC. Il KDC interrogherà il suo database di utenza e, una volta verificate le
credenziali dell’utente, rilascia all’utente un Ticket Granting Ticket (TGT). Il
TGT ha una “vita limitata” e può essere rinnovato automaticamente qualora
la sessione utente sia ancora attiva e senza che quest’ultimo reinserisca le
credenziali. Il TGT è mantenuto in memoria nella macchina client e viene
utilizzato per chiedere accesso ad una risorsa. Vediamo in dettaglio lo scambio
per l’ottenimento del TGT. La richiesta dell’AS identifica il client al KDC in
chiaro. Se la preautenticazione è abilitata sull’utente, un time stamp viene
criptato con l’hash della password dell’utente come chiave di crittografia. Se
il KDC, una volta decriptato il time stamp con l’hash della password, lo
identifica come valido, allora il KDC saprà che non si tratta di un attacco
48
a ripetizione. Se il KDC autorizza la richiesta del client all’ottenimento del
TGT, la risposta dell’AS nei confronti del client includerà due sezioni: un
TGT criptato con una chiave che solamente il KDC (TGS) può decriptare
e una chiave di sessione criptata con l’hash della password dell’utente (per
le future comunicazioni con il KDC). Siccome il client non può leggere il
contenuto del TGT, esso dovrà presentarlo così com’è al TGS per avere un
service ticket. Il TGT include parametri time-to-live, autorizzazione, una
chiave di sessione per comunicare con il client e il nome del client/utente.
Ottenuto il TGT, il client lo presenta al TGS (una delle due parti del
KDC) quando vuole accedere ad una determinato risorsa. Il TGS verifica il
TGT dell’utente e crea un ticket e una chiave di sessione sia per il client che
per il server remoto. Queste informazioni, conosciute come Service Ticket,
sono memorizzate localmente sulla macchina del client. Il TGS riceve il
TGT del client e lo legge attraverso la propria chiave. Se il TGS verifica
correttamente la richiesta del client, un Service Ticket vieve generato sia per
il client che per il server su cui l’utente sta tentando di accedere. Il client
legge la sua porzione usando la chiave di sessione del TGS che ha ricevuto
precedentemente durante la risposta dell’AS. Il cliente presenta la porzione
del Service Ticket relativa al server alla risorsa che sta accedendo durante il
Client/Server Exchange.
Una volta che l’utente ha ottenuto il Service Ticket, può stabilire la
sessione con la risorsa disponibile sul server. Il server può decriptare le
informazioni che arrivano direttamente dal TGS usando la propria chiave
stabilita con il KDC. Il Service Ticket è usato quindi per autenticare l’utente
e stabilire una sessione di erogazione servizio tra il server e il client. Dopo che
il time-to-live del ticket è terminato, il Service Ticket deve essere rinnovato
per usare il servizio. Nello specifico, il client passa la porzione relativa al
server del Service Ticket, al server verso cui sta richiedendo il servizio per
ottenere la sessione client/server. Se la mutua autenticazione è abilitata, il
server ritorna un timestamp criptato con la chiave di sessione del Service
Ticket. Se il timestamp viene decriptato correttamente, non solo il client si è
autenticato al server, ma il server si è autenticato con il client. Da notare
che il target server non ha mai comunicato direttamente con il KDC, il che
riduce il carico sul KDC.
49
SSO con Kerberos
Nel paragrafo 3.3.2 abbiamo accennato al fatto che, attraverso CAS o
Shibboleth, è possibile implementare un sistema di SSO per risorse web. Attraverso Kerberos si può invece creare una infrastruttura di SSO tra applicazioni
di rete, come shell remote o posta elettronica. Quindi è possibile accedere ad
un PC immettendo le credenziali di accesso al login, dopodiché accedere a
una serie di applicazioni in rete senza dover rieffettuare l’autenticazione.
Senza entrare nei dettagli implementativi, cui si rimanda a testi specifici,
diciamo che è possibile configurare i sistemi operativi basati su Unix, fra
cui Linux e MacOS X, e Windows (da Windows 2000 in poi) in modo da
effettuare il login appoggiandosi ad un server kerberos per l’autenticazione
dell’utente. In questo modo il sistema operativo, una volta effettuato il login,
avrà un TGT che potrà essere utilizzato da varie applicazioni per accedere a
servizi di rete che supportano l’autenticazione con kerberos, senza rieffetture
il processo di autenticazione, implementando così un sistema di SSO tra
servizi di rete.
Fra i servizi che possono essere configurati per questa forma di SSO ci
sono:
• Accesso ad un sistema unix remoto tramite ssh.
• Accesso ad un servizio web protetto.
• Accesso alla casella di posta.
Kerberos si occupa però solamente dell’autenticazione, e non tutti i servizi lo
supportano. Per tutti gli altri servizi e per mantenere le informazioni sugli
utenti si può utilizzare LDAP. I maggiori server LDAP (fra cui OpenLDAP)
danno la possibilità di reperire la password di un utente tramite Kerberos, in
questo modo si centralizza la gestione delle password nel server Kerberos e si
può utilizzare il server LDAP per mantenere le identità digitali degli utenti,
ma anche per l’autenticazione ai quei servizi che non supportano Kerberos.
3.3.5
Public Key Infrastructure
Una Public Key Infrastructure (PKI) si può definire come l’insieme
dell’hardware, del software, del personale e delle procedure necessarie per
gestire (creare o revocare), immagazzinare e distribuire i certificati digitali
basati sulla crittografia a chiave pubblica.
50
Un certificato digitale è un documento elettronico che attesta, con
una firma digitale, l’associazione tra una chiave pubblica e l’identità di un
soggetto, che può essere una persona, ma anche una società, un software o
qualcos’altro che si possa associare ad un’identità. In genere un certificato
digitale include i dati identificativi del soggetto, un periodo di validità del
certificato stesso, l’URL della lista dei certificati revocati (CRL), la chiave
pubblica del soggetto, il tutto ovviamente firmato (tramite algoritmi di firma
digitale) da una terza parte fidata (La Certification Authority). Lo standard
comune per i certificati, utilizzato anche in Internet, è X.509.
Una PKI è in genere composta dalle seguenti parti:
• Certification Authority (CA): hanno il compito di emettere, consegnare
e revocare i certificati digitali.
• Registration Authority (RA): hanno il compito di verificare il legame
tra le chiavi pubbliche e le identità dei possessori.
• Soggetti o possessori dei certificati: persone, organizzazioni o software
per i quali è stato emesso un certificato digitale.
• Repository: contenitore per le chiavi, i certificati digitali e la lista
dei certificati revocati o Certificate Revocation List (CRL). Spesso
mantenuto in un server LDAP.
• Politica di sicurezza: stabilisce e definisce una serie di principi e processi,
ad alto livello, per l’organizzazione della sicurezza.
• In aggiunta a tutto ciò la PKI può fornire un servizio di recupero delle
chiavi nel caso in cui un utente dovesse perdere la propria chiave privata.
Gli accordi alla base di una PKI consentono ad un utente di essere
mutuamente autenticato con una risorsa, e di utilizzare le informazioni
contenute nel rispettivo certificato per cifrare e decifrare i messaggi trasmessi.
Un utente può firmare i propri messaggi con la sua chiave privata, ed una
risorsa può controllare questa firma usando la chiave pubblica contenuta nel
certificato del mittente, fornito dall’autorità di certificazione facente parte
della PKI. Questo consente a due (o più) parti desiderose di comunicare di
verificare la confidenzialità, l’integrità dei messaggi e l’autenticazione degli
utenti senza il bisogno di un precedente scambio di informazioni segrete.
51
La maggior parte delle PKI fanno affidamento su catene di certificati per
stabilire l’identità delle parti: un certificato viene emesso da una CA, a sua
volta autenticata da un certificato emesso da un’autorità di livello più alto, e
così via. In questo modo si stabilisce una gerarchia di certificati, composta
da computer, organizzazioni e pacchetti software diversi.
Le PKI a livello di grandi organizzazioni, come le università, possono
essere legate ai servizi di directory, come LDAP, in cui la chiave pubblica di
ogni utente può essere memorizzata (incorporata in un certificato) assieme ai
dettagli personali dell’identità digitale.
In qualche caso, il soggetto genera la coppia di chiavi nel proprio ambiente
locale e poi passa la chiave pubblica alla CA per l’emissione del certificato;
un’altra soluzione può comportare che sia la CA ad essere responsabile della
generazione delle chiavi. Per ragioni di sicurezza, è considerata migliore la
pratica di generazione della coppia di chiavi da parte dell’utente, seguita
dalla trasmissione della sola chiave pubblica alla CA, perché in questo modo
si è sicuri che la chiave privata sia memorizzata solo in un’unica postazione.
La distribuzione sicura delle chiavi pubbliche è essenziale e una tipica
soluzione potrebbe essere anche quella di equipaggiare ogni utente con una
Smartcard o con una chiavetta USB contenenti il certificato digitale.
52
Capitolo 4
Situazione attuale
nell’Università di Parma
4.1
Il contesto
Dopo aver introdotto i concetti principali che verranno utilizzati nel
progetto, entriamo nei dettagli dell’Università di Parma, descrivendo l’attuale
situazione per quanto riguarda la gestione dell’accesso.
In questo paragrafo vediamo il contesto in cui il progetto del sistema IAM
centralizzato viene applicato, cioè quelle parti che non vengono modificate
dal progetto ma a cui esso si riferisce, che costituiscono quindi un vincolo
fissato di cui si dovrà tener conto nel progetto.
Concentrandoci sulla gestione dell’accesso, l’unico contesto utile sono le
risorse informatiche disponibili all’interno dell’università, l’obiettivo del
progetto è appunto la gestione dell’accesso a tali risorse. Un’altra parte del
contesto potrebbe essere costituita dalle fonti, ovvero da dove provengono
le informazioni relative agli utenti, da cui si deve effettuare l’operazione
di consolidamento per creare l’identità digitale unica, ma questo fa parte
della gestione dell’identità, percui va oltre gli scopi del progetto di questo
documento.
4.1.1
Risorse disponibili agli utenti
Le risorse informatiche disponibili all’interno dell’università che necessitano di una gestione dell’accesso si possono suddividere in risorse web,
risorse di rete e postazioni computer.
53
Alcune risorse web sono realizzate per gli studenti:
• GOAL: gestione delle aule della facoltà di Ingegneria;
• IscrizioNet: iscrizione agli esami per numerose facoltà (agraria, economia, farmacia, giurisprudeza, ingegneria, ecc.);
• WebGISS: servizi diversi alla didattica: esenzione maggiorazione, ecc.;
• YaGISS: comunicazione esami a scelta per la facoltà di Ingegneria;
• Er-Go: domande di benefici per il diritto allo studio;
• CampusNet: servizi per la didattica per le facoltà di Medicina e
Chirurgia e Scienze MM.FF.NN (per esempio iscrizione agli esami);
• Dspace: deposito delle tesi di dottorato;
• Dokeos-Moodle: sistemi di supporto alla didattica frontale;
altre per i dipendenti:
• CSAWeb: cedolini stipendiali;
• Form per il Nucleo di Valutazione;
• Catalogo delle Pubblicazioni.
I servizi di rete sono WiFi e VPN, entrambi disponibili sia per il personale,
sia per gli studenti. Le postazioni computer invece sono gestite singolarmente
all’interno di ogni facoltà, spesso limitate solo ai docenti e agli studenti della
facoltà stessa.
4.2
Attuale gestione dell’accesso
Vediamo ora come viene attualmente gestito l’accesso alle risorse e quali
problematiche comporta tale gestione. La struttura generale è composta da
un RDBMS MySQL dove vengono mantenute le identità digitali degli utenti,
in tabelle differenti in base al ruolo ricoperto (studenti, erasmus, dipendenti,
ospiti, ecc.) riempite con le informazioni provenienti da varie fonti (segreteria
studenti, ufficio personale, ecc.) senza che vi sia una riconciliazione dei
dati. Le informazioni nel database vengono replicate su un server LDAP per
54
l’interfacciamento con le risorse. Senza soffermarci oltre sul database, che è
parte della gestione dell’identità, vediamo nei dettagli com’è strutturato il
server LDAP e come le risorse si interfacciano ad esso.
4.2.1
Struttura del server LDAP
Illustriamo prima la struttura dell’albero, dopodiché lo schema utilizzato
e la struttura delle entry degli utenti.
Struttura dell’albero nel server LDAP
Per quel che riguarda la struttura, attualmente è organizzata per ruoli
nel seguente modo:
dc=unipr,dc=it
+ ou=people
+ ou=personale
+ cn=...
+ ...
+ ou=studenti
+ cn=...
+ ...
+ ou=erasmus
+ cn=...
+ ...
+ ou=...
+ ...
+ ou=service
+ ou=...
Nell’attributo cn viene messo il cognome seguito dal nome e, in caso di
omonimie, un numero univoco tra parentesi. Quindi se, ad esempio, abbiamo
due studenti di nome Mario Rossi, il secondo avrà cn=Rossi Mario (1) come
cn univoco all’interno del ramo studenti, e tale entry avrà il seguente DN:
cn=Rossi Mario (1),ou=studenti,ou=people,dc=unipr,dc=it
55
Schema e attributi
L’attuale schema è composto da una object class ad-hoc per ogni ruolo
(come studenteUniPR, oppure docenteUniPR), con attributi specifici per tale
ruolo. Le entry degli utenti sono perciò costituite dalla specifica object class a
seconda del ruolo ricoperto dall’utente a cui si riferiscono (quindi, guardando
la precedente struttura dell’albero, in base al ramo in cui si trovano). Per
esempio la entry di uno studente è costituita dall’object class studenteUniPR,
quella di un docente da docentiUniPR, e così via. La definizione di una object
class ad-hoc è praticamente inevitabile siccome in quelle standard mancano
attributi fondamentali, come il codice fiscale o la matricola (per gli studenti).
Ognuna di queste object class specifiche è derivata da personaUniPR, che a
sua volta è derivata dall’object class standard inetOrgPerson (percui tutte
contengono implicitamente gli attributi di quest’ultima object class). Inoltre,
le entry degli utenti sono costituite anche dalle object class posixaccount,
shadowaccount e sambaSamAccount, che contengono una serie di attributi
per l’accesso alle risorse.
4.2.2
Accesso alle risorse informatiche
Delle risorse web elencate in precedenza la maggior parte utilizzano CAS
per l’autenticazione, implementando un servizio di SSO, percui è sufficente
autenticarsi ad una sola risorsa per accedere anche alle altre. CAS preleva le
informazioni di autenticazione dal server LDAP, mentre per l’autorizzazione
è necessario un web service che restituisca ulteriori informazioni sull’utente
autenticato. Non tutte le risorse web utilizzano però CAS, alcune (per esempio
CampusNet) non implementano il servizio di SSO e prendono direttamente le
informazioni da LDAP, con la conseguenza che un utente può avere credenziali
di accesso diverse per queste risorse web.
La posta elettronica viene gestita internamente all’università per quanto
riguarda le caselle del personale, mentre vengono gestite dal CINECA le
caselle di posta degli studenti, il quale mantiene degli slave del server LDAP
copiando solo il ramo relativo agli studenti. Questa doppia gestione comporta
l’avere credenziali di accesso differenti in base al ruolo ricoperto, in particolare
viene usato come username l’indirizzo e-mail per gli studenti e l’UID per il
personale.
56
Le risorse di rete, WiFi e VPN, si appoggiano ad un server RADIUS per
la gestione dell’accesso, il quale legge le informazioni sugli utenti necessarie
per l’autenticazione e l’autorizzazione dal server LDAP. Per accedere a queste
risorse, sia per gli studenti che per il personale, viene richiesto l’indirizzo
e-mail come username.
Le postazioni computer, infine, sono in una situazione un po’ più complessa. Alcune facoltà utilizzano SAMBA per la gestione dell’accesso, come
Giurisprudenza, che si appoggia direttamente al server LDAP dell’università,
oppure la facoltà di Fisica, che però si gestisce in proprio un server LDAP
copiando dei dati dal server dell’università. La facoltà di Ingegneria invece ha
una gestione propria delle postazioni computer, con anche una password autonoma per gli utenti. Altre facoltà non usano SAMBA, ma ActiveDirectory
di Microsoft.
4.2.3
Problematiche della gestione attuale
Mantenere un database con tabelle distinte in base al ruolo comporta
diversi problemi per un sistema in cui si vorrebbe gestire un’identità unica
per ogni persona, infatti, se una persona ricopre più ruoli, come può essere un
docente-studente, vengono mantenuti due identità digitali separate per una
stessa persona, rendendo impossibile realizzare l’obiettivo dell’identità digitale
unica. Questo problema lo si risolve progettando un database unico nel quale
memorizzare e mantenere le informazioni degli utenti e le informazioni relative
a tutti i ruoli da essi ricoperti, attraverso delle opearazioni di consolidamento
che riconcilino i dati provenienti da diverse fonti in questo database unico.
Difficoltà analoghe si hanno anche nella gestione del server LDAP. Un
problema nell’attuale struttura dell’albero nel server LDAP, suddivisa per
ruoli, si ha quando un utente cambia ruolo, per esempio passa da studente
a docente, in tal caso si dovrebbe prevedere una procedura per spostare
i dati dell’utente dal ramo studenti al ramo personale per non perdere le
informazioni dell’identità digitale. Situazione ancora peggiore si ha quando
un utente ricopre contemporaneamente due ruoli, ad esempio uno studentericercatore, in questo caso si vengono ad avere due entry separate per un
unica identità digitale e, siccome lo scopo del progetto è proprio quello di
creare un’identità unica, questi casi sono assolutamente da evitare. Come
vedremo in seguito, attraverso una struttura piatta, dove tutti gli utenti
vengono mantenuti in un solo ramo indipendentemente dal ruolo ricoperto, si
57
risolvono questi problemi, infatti si ha sempre una sola entry per ogni utente,
ma chiaramente si introducono nuovi problemi: che attributi vanno mantenuti
in questa entry? Nel caso di una persona che ricopre più ruoli, come vengono
gestiti questi attributi? Questi problemi si possono risolvere attraverso la
definizione di uno schema appropriato. L’attuale schema non è però adatto
a questo scopo, infatti le object class specifiche (come studenteUniPR o
docentiUniPR) hanno spesso attributi in comune che, in una struttura non
suddivisa per ruoli, creano conflitti nel caso una persona ricopra più ruoli
all’interno dell’università. Per questo verranno definite delle nuove object
class ad-hoc con dei nuovi attributi. Inoltre, è buona norma dare un nome,
ad ogni attributo e ad ogni object class definita, che inizi con il prefisso unipr
seguito dal nome “descrittivo”.
Infine, nel sistema che si vuole ottenere ogni servizio dell’università dovrà
utilizzare un unico server LDAP centralizzato per reperire le informazioni di
accesso, ed ogni utente avrà una sola indentità digitale, percui potrà accedere
ai servizi utilizzando sempre la stessa chiave di accesso, sia essa una coppia
username-password o un certificato digitale. Nell’attuale situazione, come
abbiamo visto precedentemente, può capitare che per accedere a risorse diverse
si abbiano credenziali differenti, e in generale vi è una situazione abbastanza
confusa per quanto riguarda dove vengono prelevate le informazioni per
l’accesso. Inoltre, per il fatto che una persona può avere più identità digitali
all’interno del sistema informatico, non si possono adottare i certificati digitali
come metodo di autenticazione, non potendoli associare univocamente ad
una coppia persona-identità.
58
Capitolo 5
Progetto: gestione
centralizzata dell’accesso
Il progetto, che viene illustrato in questo capitolo, ha lo scopo di realizzare
un sistema IAM con gestione dell’accesso centralizzata, in cui ogni utente ha
un’unica identità digitale e può accedere alle risorse informatiche utilizzando
sempre le stesse credenziali di accesso, anche nel caso ricopra più ruoli.
L’attuale sistema nell’Università di Parma non è perfettamente centralizzato
(vedi capitolo precedente), anche se si avvicina molto ad un sistema di questo
tipo, ma ha soprattutto un grande problema: un utente può avere più identità
digitali se ricopre più ruoli, il che comporta avere credenziali di accesso
differenti a seconda del ruolo ricoperto. Attraverso una ristrutturazione del
server IAM riusciremo ad eliminare questa anomalia.
Il server IAM è attualmente composto da un RDBMS e da un server
LDAP. Questa suddivisione è particolarmente importante poiché i dati degli
utenti provenienti dalle fonti vengono consolidati e mantenuti nel RDBMS
che permette di organizzare dati anche molto complessi in modo semplice,
permettendo per esempio di mantenere facilmente uno storico delle informazioni degli utenti, cosa che risulterebbe particolarmente complicata in un
server LDAP. Un RDBMS è anche molto più agevole per quanto riguarda la
manipolazione e la gestione dei dati stessi rispetto ad un server LDAP, ed ha
una serie di meccanismi che lo rendono sicuro rispetto ai dati, il che lo rende
particolarmente adatto per mantenere le identità digitali degli utenti. Il server
LDAP, forte dei vantaggi illustrati nel paragrafo 2.5.1, è utilizzato invece per
interfacciarsi con le risorse informatiche. Attraverso questa suddivisione si
59
sfruttano i vantaggi di entrambe le tecnologie, realizzando un ottimo server
IAM, con l’unico svantaggio che è necessario prevedere delle procedure (degli
script) per replicare i dati dal database al server LDAP, con la conseguenza
che gli aggiornamenti ai dati, come l’eliminazione di un utente dal sistema,
subiscono dei ritardi prima di diventare effettivi.
Mantenendo quindi la struttura del server IAM, il progetto si impone di
riorganizzare la gestione delle informazioni degli utenti, creando l’identità
digitale unica. La creazione di un database unico dove mantenere i dati, come
reperire e gestire le informazioni degli utenti e come consolidarle nel database
mantenendo una ed una sola identità digitale per ogni utente, tutto questo fa
parte della gestione dell’identità, si assume perciò che venga fatta in qualche
modo e si ci concentra invece nella gestione dell’accesso. Gli obiettivi del
progetto sono percui la riorganizzazione del server LDAP in modo che supporti
la gestione di un’identità unica per ogni utente, e centralizzare la gestione
dell’accesso alle risorse in modo tale che vengano reperite le informazioni dal
server LDAP.
5.1
Vincoli progettuali
Oltre ai vincoli dovuti al contesto dell’Università di Parma, descritti
nel capitolo precedente, ci sono una serie di vincoli di carattere tecnico,
dovuti all’importanza di un sistema IAM in una realtà con molti utenti, che
assolutamente non si possono trascurare: sicurezza, affidabilità e performance.
Il progetto per la gestione degli accessi dovrà quindi prevedere che il sistema
realizzato sia:
• Sicuro, siccome durante l’accesso ad una risorsa transitano informazioni
riservate, dovranno quindi essere previsti meccanismi per cifrare le
trasmissioni, ed impedire a malintenzionati di intercettare e leggere
certe informazioni.
• Affidabile, cioè deve garantire la continuità del servizio poiché diventerebbe inaccettabile che periodicamente il sistema dell’accesso non sia
disponibile e gli utenti non riescano ad accedere alle risorse informatiche.
• Performante, ovvero deve rispondere alle richieste in tempi sempre
accettabili, anche quando viene sottoposto ad aumenti del carico da
60
gestire. Infatti un utente, in genere, non vuole aspettare diversi minuti
prima che gli venga consentito l’accesso ad una risorsa.
Tutti questi vincoli sono presi in considerazione nel seguente progetto e
vengono illustrati in paragrafi a parte.
5.2
Architettura generale
Figura 5.1: Architettura generale del progetto.
Nello schema rappresentato in figura 5.1 si può vedere l’architettura
generale del progetto: i dati provenienti dalle fonti vengono consolidati
in un database unificato, le informazioni degli utenti vengono replicate
sul server LDAP il quale le rende disponibili alle risorse per la gestione
dell’accesso.
Quando un utente prova ad accedere ad una risorsa informatica, questa
richiede i dati al server LDAP, li confronta con quelli inseriti dall’utente e
gli consente o gli nega l’accesso. L’intera parte della gestione dell’identità
si presuppone che sia in qualche modo gestita, e la si può vedere come una
scatola nera in cui è contenuta un’identità digitale unica per ogni utente
(figura 5.2).
Da questo schema di alto livello si apprezza il fatto che tutta la gestione
dell’accesso è centralizzata presso il server IAM, e quando un utente vuole
61
Figura 5.2: Schema logico dell’architettura del progetto.
accedere ad una qualunque risorsa lo può fare utilizzando sempre le stesse
credenziali di accesso. Il modo con cui poi verrà gestita l’identità all’interno
del server IAM permetterà all’utente di avere una ed una sola identità digitale
anche se ricopre più ruoli, quindi di accedere alle risorse con le sue credenziali
uniche indipendenti dal ruolo ricoperto.
5.3
LDAP
La gestione dell’accesso parte dal server LDAP, nel quale vengono mantenute le informazioni degli utenti che le risorse informatiche vengono a
prelevare per il controllo dell’accesso. Mentre nel database vengono mantenute in modo altamente sicuro tutte le informazioni degli utenti, il server
LDAP viene utilizzato per interfacciarsi con le risorse, sarà quindi necessario
replicare alcune informazioni dal database.
5.3.1
Quale server LDAP
La scelta del server LDAP, escludendo le soluzioni proprietarie, la si può
restringere ai due principali progetti open source: Fedora DS e OpenLDAP.
Vediamoli allora entrambi nei dettagli.
62
Fedora DS
Fedora Directory Server (in breve FDS) è nato nel 1999 come Netscape
DS, un directory server di classe Enterpries. Nel 2004 Red Hat l’ha acquistato,
l’ha passato alla comunità Fedora e ne’ ha fatto un prodotto open source,
rilasciato con licenza GPL. Le principali caratteristiche sono:
• Configurazione Multi-Master Replication grazie alla quale riesce a
fornire un’alta affidabilità e ottime performance.
• Elevata scalabilità.
• Sviluppato e supportato dall’ampia comunità Fedora.
• Documentazione molto ricca.
• Permette la sincronizzazione di utenti e gruppi Active Directory.
• Fornisce sitmetodi di autenticazione e trasporto sicuri (SSLv3, TLSv1
e SASL)
• Compatibilità con lo standard LDAPv3.
• Utility grafiche per la gestione del server.
OpenLDAP
OpenLDAP è probabilmente il più diffuso server LDAP, ed è attualmente
utilizzato anche nell’Università di Parma. È un progetto open source iniziato nel 1998 da Kurt Zeilenga, rilasciato sotto una licenza personalizzata
(OpenLDAP Public License) più restrittiva rispetto alla GPL. Di seguito le
caratteristiche principali:
• È un software libero ed è adottato dalle maggiori distribuzioni linux.
• Ha una buona comunità alle spalle e, per la sua diffusione, dispone di
un’ottimo supporto.
• Esiste da oltre dieci anni ed è ormai consolidato e affermato.
• In continuo sviluppo e aggiornamento, ed aggiunge sempre nuove funzionalità (come la replica su server multimaser o configurazioni dinamiche
disponibili con le ultime versioni).
63
• Compatibilità con lo standard LDAPv3
• Offre metodi di autenticazione e connessioni sicure.
• Supporta la distribuzione dei carichi di lavoro.
• Permette la replica delle informazioni.
• Fornisce tempi brevi di risposta.
Fedora DS vs. OpenLDAP
Nonostante OpenLDAP sia molto diffuso ed affermato, sono in molti a
preferirgli Fedora DS. Quest’ultimo, oltre ad essere un prodotto di classe
Enterprise percui, teoricamente, più adatto ad ambienti con molti utenti,
può vantare una gestione più semplice e vari strumenti che possono aiutare
l’amministratore, come una console grafica per la configurazione, e un “http
admin server” per amministrare il server attraverso un browser web. Inoltre
FDS offre una documentazione molto ampia e ben fatta, a differenza di
OpenLDAP nel quale la documentazione non è perfetta.
OpenLDAP resta comunque un ottimo prodotto, anche se più complicato
da configurare e gestire, in quanto a caretteristiche offerte non si può dire
che sia inferiore a Fedora DS, con le ultime versioni all’incirca si equivalgono.
Per l’infrastruttura trattata in questo testo è stato scelto OpenLDAP perché
già in uso e non vi sono validi motivi per sostituirlo. Da aggiungere che
alcuni benchmark effettuati nel 2007 sui maggiori server LDAP (OpenLDAP
2.3.34, Fedora DS 1.0.4, OpenDS 0.3-34 e ApacheDS 1.0.1) hanno mostrato
che OpenLDAP è nettamente al di sopra degli altri in quanto a tempi di
risposta anche a fronte di una grande quantità di richieste.
5.3.2
Struttura e schema
Una delle problematiche principali è la riorganizzazione della struttura
dell’albero delle entry nel server LDAP, quindi come organizzare le informazioni, e la definizione dello schema del server LDAP, stabilendo quali
informazioni portare dal database a LDAP e in quali attributi memorizzarle,
eventualmente definendo degli attributi e delle object class ad-hoc.
64
Struttura
Per quel che riguarda la struttura, attualmente organizzata per ruoli, si
vuole passare ad una struttura “piatta”, in cui tutte le identità sono mantenute
in un unico ramo, in modo da eliminare la dipendenza dell’identità digitale
rispetto al ruolo ricoperto:
dc=unipr,dc=it
+ ou=people
+ cn=...
+ cn=...
+ cn=...
+ ...
+ ou=service
+ ou=...
Per non avere tutti gli utenti in un singolo ramo, il che comporterebbe
scarse prestazioni in caso di ricerche, è opportuno suddividerli per iniziale del
cognome, facilitando cosiì anche il browsing tra le entry. In questo modo si
riescono a suddividere gli utenti in modo logico e abbastanza uniformemente
in più rami, facilitando e ottimizzando le operazioni di ricerca. Altra modifica
rispetto all’attuale schema è la scelta di come indentificare gli utenti. Come
già descritto precedentemente, ora si identificano in base al cn, composto dal
cognome, seguito dal nome e da un numero univoco in caso di omoninie. Una
scelta migliore, più semplice ed efficace, è di identificarli in base al codice
fiscale, poichè raramente è doppio e difficilmente dev’essere modificato.
In definitiva la struttura scelta è la seguente:
dc=unipr,dc=it
+ ou=people
+ dc=A
+ uniprCodiceFiscale=...
+ uniprCodiceFiscale=...
+ ...
+ dc=B
+ uniprCodiceFiscale=...
+ ...
+ dc=C
65
+ ...
+ ...
+ ou=service
+ ou=...
Un esempio di DN, che identifica univocamente una entry, può essere il
seguente:
uniprCodiceFiscale=RSSMRA88A01G337P,dc=R,dc=unipr,dc=it
Schema
Con la definizione dello schema LDAP intendiamo stabilire quali informazioni replicare dal database al server LDAP, decidere quali attributi (oppure
intere object class) standard si possono utilizzare, quindi definire gli attributi
e le object class “ad-hoc” in base agli attributi mancanti fra quelli standard.
L’utilizzo di attributi standard ha un certo rilevo soprattutto se si parla di
federazone: gestire informazioni in modo omogeneo tra diverse organizzazioni,
memorizzandole negli stessi attributi, può notevolmente semplificare la gestione di un sistema di AAI (Authentication and Authorization Infrastructure)
federato. Un altro vantaggio è anche verso le applicazioni che si appoggiano
a LDAP, infatti può risultare più semplice la gestione di attributi standard
rispetto ad attributi scritti appositamente, inoltre utilizzando attributi standard si possono utilizzare (o implementare) applicazioni di carattere più
ampio e generale e non utilizzabili solo all’interno di una specifica università.
Per quanto riguarda il problema di quali informazioni memorizzare per
ogni utente si è scelta la seguente soluzione: viene stabilita la struttura di
una “entry base” comune a tutti gli utenti, indipendente dal ruolo ricoperto,
composta da almeno una object class di tipo structural, dopodiché per ogni
ruolo viene definita una object class di tipo auxiliary contenente gli attributi
specifici per quel ruolo. La struttura di una generica entry sarà quindi
composta dalle object class della “entry base” più le object class auxiliary dei
ruoli ricoperti dall’utente a cui la entry si riferisce.
Nel paragrafo successivo stabiliamo quali informazioni memorizzare nel
server LDAP e in quali attributi, partendo da quelle comuni a tutti gli utenti,
che andranno nella “entry base”, poi quelle specifiche dei ruoli, che andranno
nelle object class auxiliary.
66
5.3.3
Attributi per l’identità
Stabiliamo allora quali informazioni serviranno, iniziando dalla “entry
base”:
• ID identità
• Cognome
• Nome
• Sesso
• Codice Fiscale
• Data nascita
• Indirizzo di domicilio e di residenza
• Mail
• Telefoni
• Fax
• Titolo onorifico
• Nazione di residenza, cittadinanza e domicilio
• Luogo di residenza, cittadinanza e domicilio
• Ruoli ricoperti
Oltre alle informazioni sopraelencate vanno aggiunti gli attributi necessari
per la gestione dell’accesso alle risorse, inidicati nel paragrafo 5.3.4.
Passiamo alle informazioni specifiche in base al ruolo:
• Studente
– Matricola
– Anno di ultimo pagamento delle tasse
– Anno di prima immatricolazione
– Anno della laurea triennale
– Anno della laurea specialistica
67
– Corso di laurea di appartenenza (e facoltà)
• Dipendente
– IDSGE
– Codice SISA
– Data Inizio
– Data Fine
– Codice Ruolo
– Profilo e categoria
– Stati del ruolo
– Incarichi
– Aree e settori
– Dipartimenti, serivizi e sezioni e sedi collegate
• Futura matricola
– Matricola
– Anno di prima immatricolazione
– Corso di laurea di appartenenza (e Facoltà)
• Professore a contratto
– IDSGE
– Codice SISA
– Data Inizio
– Data Fine
– Codice Ruolo
– Profilo e categoria
– Stati del ruolo
– Aree e settori
Da notare che si è deciso di replicare in LDAP molte informazioni contenute nel database, una diversa soluzione poteva essere quella di avere un
numero ristretto di dati in LDAP e nel caso una applicazione avesse bisogno
68
di ulteriori informazioni su un utente, “collegarla” direttamente al database
implementando, per esempio, un web service per questo scopo.
Vediamo ora in quali attributi LDAP si possono memorizzare le precedenti
informazioni. Gli attributi standard verranno presi dalle seguenti object class:
• person, definita in [RFC4519].
• organizationalPerson, definita in [RFC4519].
• inetOrgPerson, definita in [RFC1274]
• eduPerson, vedere eduPerson 200806
• schacPersonalCharacteristics, vedere SCHAC v. 20060928-1.3.0
• schacContactLocation, vedere SCHAC v. 20060928-1.3.0
• schacEmployeeInfo, vedere SCHAC v. 20060928-1.3.0
Nonostante il buon numero di attributi presenti in queste object class
ne mancano alcuni fondamentali, come il codice fiscale, percui, per coprire
queste lacune, andranno definiti attributi ad-hoc per l’università, tali attributi
inizieranno con il prefisso unipr. Iniziamo con gli attributi della “entry base”:
Informazione
Attributo LDAP
IDIdentità
uniprIDIdentita
Cognome
sn
Nome
givenName
Sesso
schacGender
Codice Fiscale
uniprCodiceFiscale
Data nascita
schacDateOfBirth
Via di domicilio
street
CAP di domicilio
postalCode
Luogo di domicilio
uniprLuogoDiDomicilio
Provincia di domicilio
uniprProvinciaDiDomicilio
Stato di domicilio
uniprStatoDiDomicilio
Via, CAP, Luogo, Provincia, Stato di
domicilio
postalAddress
Via di residenza
uniprViaDiResidenza
69
Informazione
Attributo LDAP
CAP di residenza
uniprCAPdiResidenza
Luogo di residenza
l
Provincia di residenza
st
Stato di residenza
schacCountryOfResidence
Via, CAP, Luogo, Provincia, Stato di
residenza
homePostalAddress
Mail
mail
Telefono residenza
homePhone
Telefono domicilio
telephoneNumber
Telefono cellulare
mobile
Fax
facsimileTelephoneNumber
Titolo onorifico
schacPersonalTitle
Ruoli ricoperti
uniprRuoliRicoperti
La struttura della entry base sarà costituita dall’object class uniprPersona
(derivata da inetOrgPerson1 ) nella quale ci andranno gli attributi ad-hoc
presenti nella precedente tabella (quelli con il prefisso unipr), e dalle seguenti
object class standard :
• schacPersonalCharacteristics
• schacContactLocation
• eduPerson
• schacEmployeeInfo
Passiamo agli attributi specifici di ogni ruolo, che andranno a formare
le object class auxiliary. Gli attributi seguenti (compresi quelli standard)
andranno a formare l’object class ad-hoc uniprStudente:
Informazione
Attributo LDAP
Matricola
uniprMatricola
Anno di ultimo pagamento delle tasse
uniprAnnoUltimoPagamento
1
L’object class inetOrgPerson deriva da organizationalPerson che a sua volta deriva
da person.
70
Informazione
Attributo LDAP
Anno di prima immatricolazione
uniprAnnoPrimaImmatricolazione
Anno della laurea triennale
uniprAnnoLaureaTriennale
Anno della laurea specialistica
uniprAnnoLaureaSpecialistica
Corso di laurea di appartenenza
uniprCorsoLaurea
Facoltà di appartenenza
ou
Attributi per l’object class uniprDipendente:
Informazione
Attributo LDAP
IDSGE
uniprIDSGEDipendente
Codice SISA
employeeNumber
Data Inizio
uniprDataInizioRuolo
Data Fine
uniprDataFineRuolo
Codice Ruolo
employeeType
Profilo
uniprProfilo
Categoria
uniprCategoria
Stati del ruolo
uniprStatoRuolo
Incarichi
uniprIncarico
Aree
uniprAree
Settori
uniprSettore
Dipartimenti
departmentNumber
Servizi
uniprServizi
Sezioni
uniprSezioni
Attributi per l’object class uniprFuturaMatricola:
Informazione
Attributo LDAP
Matricola
uniprFuturaMatricola
Anno di prima immatricolazione
uniprAnnoPrimaImmatricolazione FuturaMatricola
Corso di laurea di appartenenza
uniprCorsoLaureaFuturaMatricola
Facoltà di appartenenza
uniprFacoltaFuturaMatricola
71
Attributi per l’object class uniprProfessoreAContratto:
Informazione
Attributo LDAP
IDSGE
uniprIDSGEProfessoreAContratto
Codice SISA
uniprCodiceSISAProfessoreAContratto
Data Inizio
uniprDataInizioRuoloProfessore
AContratto
Data Fine
uniprDataFineRuoloProfessore AContratto
Codice Ruolo
uniprCodiceRuoloProfessore
tratto
Profilo
uniprProfiloProfessoreAContratto
Categoria
uniprCategoriaProfessoreAContratto
Stati del ruolo
uniprStatoRuoloProfessore AContratto
Aree
uniprAreeProfessoreAContratto
Settori
uniprSettoreProfessoreAContratto
ACon-
La definizione del nuovo schema, con i nuovi attributi, l’object class
di tipo structural uniprPersona e le object class auxiliary uniprStudente,
uniprDipendente, uniprFuturaMatricola e uniprProfessoreAContratto,
la si può ricavare dalle precedenti tabelle ed è riportata nell’appendice A.
5.3.4
Attributi per l’accesso
Per gestire l’accesso (cioè autenticazione e autorizzazione) ogni risorsa
preleva le informazioni necessarie dal server LDAP, leggendo particolari attributi che dovranno esistere nella entry LDAP dell’utente che vuole accedere
alla risorsa. Questi attributi sono presenti in una serie di object class:
• account
• posixAccount
• shadowAccount
• sambaSamAccount
• radiusprofile
72
Queste object class andranno perciò aggiunte alla struttura della “entry
base” descritta a pagina 70.
Per l’accesso ai PC linux, attraverso i moduli PAM, vengono utilizzate le
object class account, posixAccount e shadowAccount, nelle quali sono contenute tutte le informazioni per “creare” un utente unix. Il server SAMBA,
utilizzato per l’accesso ai PC windows, prende le informazioni dall’object
class sambaSamAccount (creata apposta dagli sviluppatori di SAMBA). Il
server RADIUS, di cui consideriamo l’implementazione libera freeRADIUS,
utilizzato per l’accesso alle risorse di rete WiFi e VPN, legge le informazioni
di autenticazione dall’object class sambaSamAccount mentre per la gestione
dell’autorizzazione è stata creata una object class apposta: radiusprofile.
Infine le rimanenti risorse (applicazioni WEB, CAS e server di posta) possono essere configurate per leggere attributi già esistenti, in genere uid e
userPassword rispettivamente per username e password, presenti nell’object
class posixAccount.
Vediamo allora nel dettaglio ognuna di queste object class e i loro attributi.
Object-class account
Definita all’interno di cosine.schema:
objectclass ( 0.9.2342.19200300.100.4.5
NAME ’account’
SUP top
STRUCTURAL
MUST uid
MAY ( description $ seeAlso $ localityName $
organizationName $ organizationalUnitName $ host )
)
Questa object class rappresenta l’account di un computer e viene utilizzata
per l’accesso ai PC linux, tramite i moduli PAM. L’unico attributo necessario,
che è anche l’unico obbligatorio, è uid, nel quale viene mantenuto il nome di
login dell’utente.
Object-class posixAccount
Definito all’interno di nis.schema:
73
objectclass ( 1.3.6.1.1.1.2.0
NAME ’posixAccount’
DESC ’Abstraction of an account with POSIX attributes’
SUP top
AUXILIARY
MUST ( cn $ uid $ uidNumber $ gidNumber $ homeDirectory )
MAY ( userPassword $ loginShell $ gecos $ description )
)
Serve per rappresentare un utente unix attraverso gli attributi in genere
contenuti nel file di sistema /etc/passwd. Questi attributi sono utilizzati
dalla maggior parte dei sistemi di autenticazione e autorizzazione, fra cui:
accesso ai PC linux, applicazioni web, CAS, server di posta elettronica.
Vediamo in dettaglio il contenuto di ogni attributo:
• cn: nome completo della persona a cui è associata la entry.
• uid: nome di login dell’utente (lo stesso della object class account).
• uidNumber: identificativo numerico dell’utente.
• gidNumber: identificativo numerico del gruppo principale dell’utente.
• homeDirectory: path completo della home directory.
• userPassword: password cifrata dell’utente.
• loginShell: path del programma lanciato al login.
• gecos: campo opzionale, in genere il nome utente.
• description: breve descrizione relativa all’utente (opzionale).
Object-class shadowAccount
Definito all’interno di nis.schema:
objectclass ( 1.3.6.1.1.1.2.1
NAME ’shadowAccount’
DESC ’Additional attributes for shadow passwords’
SUP top
AUXILIARY
74
MUST uid
MAY ( userPassword $ shadowLastChange $ shadowMin $
shadowMax $ shadowWarning $ shadowInactive $
shadowExpire $ shadowFlag $ description )
)
Questa object class è utilizzata per mantenere i dati di un account unix
in genere mantenuti nel file di sistema /etc/shadow. Gli attributi uid e
userPassword sono gli stessi dell’object class posixAccount, gli altri attributi
da utilizzare sono i seguenti:
• shadowLastChange: giorno dell’ultimo cambiamento password (dal
1/1/1970).
• shadowMin: numero di giorni dall’ultimo cambiamento prima dei quali
la password non può essere cambiata.
• shadowMax: numero di giorni dall’ultimo cambiamento password, dopo
i quali la password scade e deve essere rinnovata.
• shadowWarning: numero di giorni prima della scadenza della password
durante i quali l’utente viene avvertito.
• shadowInactive: numero di giorni dopo i quali, una volta scaduta la
password senza essere rinnovata, l’account viene disabilitato.
• shadowExpire: giorno in cui l’account viene disabilitato (dal 1/1/1970).
Object-class sambaSamAccount
Definito all’interno di samba3.schema:
objectclass ( 1.3.6.1.4.1.7165.2.2.6
NAME ’sambaSamAccount’
SUP top
AUXILIARY
DESC ’Samba 3.0 Auxilary SAM Account’
MUST ( uid $ sambaSID )
MAY
( cn $ sambaLMPassword $ sambaNTPassword $
sambaPwdLastSet $ sambaLogonTime $ sambaLogoffTime $
sambaKickoffTime $ sambaPwdCanChange $
75
sambaPwdMustChange $ sambaAcctFlags $ displayName $
sambaHomePath $ sambaHomeDrive $ sambaLogonScript $
sambaProfilePath $ description $
sambaUserWorkstations $ sambaPrimaryGroupSID $
sambaDomainName $ sambaMungedDial $
sambaBadPasswordCount $ sambaBadPasswordTime $
sambaPasswordHistory $ sambaLogonHours)
)
I dati mantenuti in questa object class vengono utilizzati dal server
SAMBA per gestire l’accesso ai PC windows e dal server RADIUS per
l’autenticazione del WiFi e della VPN.
• sambaSID: Security ID (SID) dell’utente.
• sambaNTPassword: password nel formato NT (hash MD4 della password
in Unicode). La stessa password mantenuta nell’attributo userPassword.
• sambaLMPassword: password nel formato LAN manager. Stessa password mantenuta in sambaNTPassword e userPassword.
• sambaPwdLastSet: tempo di ultima modifica delle password.
• sambaPwdMustChange: tempo in cui la password dovrà essere modificata.
• sambaKickoffTime: tempo in cui l’account sarà bloccato. Analogo a
shadowExpire di shadowAccount.
• sambaPasswordHistory: password precedenti, non potranno essere
riutilizzate al momento della modifica della password.
• sambaPrimaryGroupSID: Security ID (SID) del gruppo principale dell’utente.
• sambaAcctFlags: flag, una stringa di 11 caratteri delimitata da parentesi quadre che definisce le caratteristiche dell’account.
• sambaDomainName: dominio Windows di cui l’utente fa parte.
76
Object-class radiusprofile
Definito all’interno di RADIUS-LDAPv3.schema:
objectclass ( 1.3.6.1.4.1.3317.4.3.2.1
NAME ’radiusprofile’
SUP top AUXILIARY
DESC ’’
MUST cn
MAY ( radiusArapFeatures $ radiusArapSecurity $
radiusArapZoneAccess $ radiusAuthType $
radiusCallbackId $ radiusCallbackNumber $
radiusCalledStationId $ radiusCallingStationId $
radiusClass $ radiusClientIPAddress $
radiusFilterId $ radiusFramedAppleTalkLink $
radiusFramedAppleTalkNetwork $
radiusFramedAppleTalkZone $
radiusFramedCompression $ radiusFramedIPAddress $
radiusFramedIPNetmask $ radiusFramedIPXNetwork $
radiusFramedMTU $ radiusFramedProtocol $
radiusCheckItem $ radiusReplyItem $
radiusFramedRoute $ radiusFramedRouting $
radiusIdleTimeout $ radiusGroupName $ radiusHint $
radiusHuntgroupName $ radiusLoginIPHost $
radiusLoginLATGroup $ radiusLoginLATNode $
radiusLoginLATPort $ radiusLoginLATService $
radiusLoginService $ radiusLoginTCPPort $
radiusLoginTime $ radiusPasswordRetry $
radiusPortLimit $ radiusPrompt $
radiusProxyToRealm $ radiusRealm $
radiusReplicateToRealm $ radiusServiceType $
radiusSessionTimeout $ radiusStripUserName $
radiusTerminationAction $
radiusTunnelClientEndpoint $ radiusProfileDn $
radiusSimultaneousUse $ radiusTunnelAssignmentId $
radiusTunnelMediumType $ radiusTunnelPassword $
radiusTunnelPreference $
77
radiusTunnelPrivateGroupId $
radiusTunnelServerEndpoint $
radiusTunnelType $ radiusUserCategory $
radiusVSA $ radiusExpiration $ dialupAccess $
radiusNASIpAddress $ radiusReplyMessage )
)
Attraverso questi attributi è possibile gestire l’autorizzazione alle risorse
di rete che si appoggiano al server RADIUS, vediamo il significato di alcuni
di questi attributi:
• radiusFramedIPAddress: indirizzo IP assegnato al client durante la
connessione.
• radiusFramedIPNetmask: netmask assegnata al client.
• radiusFramedMTU: consente di impostare la MTU, ovvero la massima
dimensione trasferibile in un pacchetto.
• radiusFramedRoute: consente di impostare la tabella di routing del
client.
• radiusIdleTimeout: imposta il tempo di timeout: trascorso il tempo
prefissato di inattività la connessione viene chiusa.
• radiusLoginService: specifica il tipo di servizio accordato al client.
• radiusSessionTimeout: specifica la durata massima, in secondi, di
una sessione utente.
• radiusSimultaneousUse: numero massimo di accessi simultanei consentiti.
5.3.5
Esempio di una entry LDAP
Vediamo allora un esempio di entry, in formato LDIF, di un possibile
studente di nome Mario Rossi:
dn: uniprCodiceFiscale=RSSMRA86D12G337Z,dc=R,dc=unipr,dc=it
uniprCodiceFiscale: RSSMRA86D12G337Z
objectClass: person
objectClass: organizationalPerson
78
objectClass: inetOrgPerson
objectClass: schacPersonalCharacteristics
objectClass: schacContactLocation
objectClass: eduPerson
objectClass: schacEmployeeInfo
objectClass: uniprPersona
objectClass: uniprStudente
objectClass: account
objectClass: shadowAccount
objectClass: posixAccount
objectClass: sambaSamAccount
objectClass: radiusprofile
cn: Mario Rossi
givenName: Mario
sn: Rossi
uniprIDIdentita: [email protected]
schacGender: 1
schacDateOfBirth: 19860412
street: Via Roma 1/a
postalCode: 43100
uniprLuogoDiDomicilio: Parma
uniprProvinciaDiDomicilio: PR
uniprStatoDiDomicilio: Italia
postalAddress: Via Roma 1/a$Parma$PR$Italia
mail: [email protected]
telephoneNumber: +39 0521 893204
uniprRuoliRicoperti: studente
uniprMatricola: 187324
uniprAnnoUltimoPagamento: 2008
uniprAnnoPrimaImmatricolazione: 2008
uniprAnnoLaureaTriennale: 2008
uniprCorsoLaurea: 0314
ou: 02
uid: mario.rossi
userPassword: e01ENX1GNXJVWEd6aXk1ZlBFQ25pRWdSdWdRPT0=
uidNumber: 1003
79
gidNumber: 100
homeDirectory: /home/mario.rossi
loginShell: /bin/bash
gecos: Mario Rossi
shadowMin: 100
shadowMax: 100
shadowWarning: 7
shadowInactive: 14
sambaSID: S-1-5-21-178374138-3223223291-377472742-3010
sambaLMPassword: 3AE6CCCE2A2A253F93E28745B8BF4BA6
sambaNTPassword: 35CCBA9168B1D5CA6093B4B7D56C619B
sambaPwdLastSet: 1141916899
shadowLastChange: 13216
sambaKickoffTime: 1893488400
sambaAcctFlags: [XU ]
sambaHomeDrive: U:
sambaPrimaryGroupSID: S-1-5-21-178374138-3223223291-377472742-4003
sambaDomainName: sambadomain
sambaProfilePath: \\PDC\profiles\mario.rossi
sambaHomePath: \\PDC\home\mario.rossi
5.4
Gestione cetralizzata dell’accesso con LDAP
L’altro obiettivo del progetto è creare una infrastruttura in cui tutte le
risorse prendano le informazioni per gestire l’accesso da un server centralizzato,
nel nostro caso LDAP. Come già detto, in questo server viene mantenuta
l’identità digitale unica degli utenti, che potranno accedere a tutte le risorse
utilizzando sempre le stesse credenziali di accesso.
5.4.1
RADIUS e LDAP
Un server RADIUS (descritto nel paragrafo 3.3.3) viene utilizzato, come
vedremmo in seguito, per la gestione dell’accesso alle risorse di rete, WiFi e
VPN. Questo server può prelevare le informazioni di autenticazione e autorizzazione da un server LDAP in cui sono gestiti gli utenti e, per ogni utente,
sono impostati gli attributi adatti. Gli attributi LDAP da cui RADIUS
preleva le informazioni possono variare a seconda dell’implementazione di
80
RADIUS che si utilizza e dal metodo di autenticazione utilizzato (CHAP,
MSCHAPv2, EAP-TTLS, ...), tipicamente lo username viene prelevato dall’attributo uid e la password da userPassword, mentre per le informazioni
di autorizzazione è possibile che si debba aggiungere uno schema ad-hoc al
server LDAP contenente gli attributi necessari. Nel server LDAP è opportuno
creare un utente “radius” al quale gli si dà permessi in sola lettura per le
entry degli utenti, e nel server RADIUS verrà impostato l’accesso ad LDAP
tramite l’utente “radius”. Un’altro accorgimento da adottare in termini di
sicurezza è impostare una connessione TLS tra server RADIUS e server LDAP
(tipicamente supportata dalle implementazioni di entrambi i server) in modo
che i dati scambiati siano cifrati e non transitino in chiaro sulla rete.
In questo progetto viene utilizzata l’implementazione open source freeRADIUS, il quale preleva le informazioni di autenticazione dall’object class
sambaSamAccount, mentre per la gestione dell’autorizzazione è stata creata
una object class apposta: radiusprofile. Entrambe queste object class
faranno quindi parte della struttura dell’entry di un utente nel server LDAP.
5.4.2
WiFi
Un grande svantaggio di una rete WiFi è che, potenzialmente, può accedervi chiunque; poiché non si possono controllare i punti di accesso ad una
WLAN, una persona con un portatile dotato di scheda WiFi può mettersi nel
raggio di copertura di un AP e connettersi alla rete, potendo così accedere a
dati riservati disponibili in rete o sfruttare un connessione a Internet. Diventa
perciò di fondamentale importanza poter controllare chi accede alla rete, cioè
gestire l’accesso alla risorsa WiFi.
Esistono diverse soluzioni per implementare una infrastruttura di autenticazione e autorizzazione ad una rete WiFi, di seguito si ci vuole però concentrare sulle soluzioni destinate a gestire una situazione con molti utenti che
possono accedere al servizio WiFi (come appunto un’università), organizzati
e mantenuti in un sistema centralizzato con un server LDAP.
Protocolli di sicurezza
Siccome i dati trasmessi in una WLAN sono potenzialmente leggibili
da chiunque poiché viaggiano nell’aria, ed una qualunque persona, con un
portatile che abbia una scheda wireless, può facilmente intercettare una
81
trasmissione, è stato necessario introdurre nello standard WiFi un sistema
per cifrare e proteggere i dati trasmessi. Nel primo standard 802.11 è stato
inserito il protocollo di sicurezza WEP (Wired Equivalent Privacy) che agisce
a livello data-link, basato su una chiave condivisa tra AP e WT; purtroppo
questo protocollo garantisce un livello di sicurezza praticamente nullo perché
sono stati trovati algoritmi in grado di decifrare la chiave in meno di due ore.
Nel 2004 è uscito il nuovo standard di sicurezza delle reti WiFi, 802.11i
(chiamato anche WPA2), con il quale si possono ottenere elevati livelli di
sicurezza. 802.11i rimpiazza tutte le specifiche di sicurezza di 802.11, prevede l’utilizzo dello standard IEEE 802.1x per il processo di autenticazione
e CCMP per cifrare le comunicazioni; CCMP (Counter Mode with Cipher
Block Chaining Message Authentication Code Protocol) è un protocollo di
crittografia basato sull’alogritmo AES attraverso il quale si riesce a garantire confidenzialità , integrità del messaggio e certezza del mittente. Per
compatibilità con WEP, lo standard WPA2 supporta la gestione a chiave
condivisa, ma si può utilizzare un sistema con chiave dinamica in modo che il
WT non debba necessariamente conoscere a priori la chiave, rendendo molto
più semplice la gestione della WLAN (soprattutto nel caso si abbiano molti
utenti che devono accedervi).
Un altro possibile sistema è quello di lasciare le trasmissioni wireless in
chiaro, limitandosi all’autenticazione degli utenti per accedere alla WLAN, e
rimandare la cifratura ai protocolli degli strati superiori, per esempio utilizzando IPsec oppure SSL; se da un lato è vero che sempre più applicazioni
che trattano dati riservati utilizzano protocolli sicuri (come HTTPS) e garantiscono già loro la sicurezza su tali dati, d’altra parte esistono ancora
numerose applicazioni che non prevedono protocolli sicuri (ad esempio alcuni
server di posta accettano ancora la password di autenticazione trasmessa in
chiaro), perciò alcuni dati riservati potrebbero transitare in chiaro sulla rete
wireless; inoltre, anche escludendo che possano essere trasmesse password in
chiaro, la maggior parte dei dati scambiati in rete, le pagine web visitate o le
e-mail inviate, transitano in chiaro, e sembra comunque inopportuno che un
malintenzionato (o semplicemente una persona un po’ troppo curiosa) possa
vedere le attività di rete di un utente, monitorando il suo traffico wireless.
82
WPA2-PSK
WPA2 può essere utilizzato in due modi: con chiave condivisa oppure
con lo standard 802.1x. Con la sigla WPA2-PSK si intende WPA2 utilizzato
con chiave condivisa (PSK stà per Pre-Shared Key): l’access point viene
configurato con una determinata chiave, dopodiché ogni dispositivo che vuol
accedere alla rete WiFi, tramite quell’access point, deve essere configurato
con la stessa chiave, altrimenti la connessione viene rifiutata. Se la chiave
viene scelta abbastanza complessa (ad esempio non una parola comune, ma
una composizione di numeri e lettere sufficentemente lunga) e viene periodicamente cambiata, questo sistema assicura un buon metodo di autenticazione,
difficilmente aggirabile, ed anche un ottimo livello di sicurezza poiché la
trasmissione viene cifrata utilizzando la chiave condivisa. Purtroppo è abbastanza evidente che può funzionare bene solo in ambienti piccoli, come
abitazioni domestiche o piccoli uffici, dove si può conoscere a priori tutti i
dispositivi che devono accedere alla rete, in modo da poter impostare, ed
eventualmente cambiare, la chiave condivisa; per questo motivo non ci soffermeremo oltre su questo metodo di autenticazione. Bisogna però sottolineare
che solo i sistemi operativi più moderni supportano nativamente lo standard
WPA2.
Da notare che esiste anche WEP-PSK ma, per i motivi citati in precedenza,
il protocollo WEP non si può considerare un sistema che garantisca un livello
di sicurezza accettabile.
PPPoE
Una soluzione al problema dell’autenticazione, in un ambiente con molti
utenti da gestire, è di sfruttare il protocollo PPP, in particolare PPPoE (PPP
over Ethernet). PPPoE è un protocollo per connessioni punto-punto che
permette di incapsulare il protocollo PPP in un frame Ethernet. È molto
utilizzato dagli ISP (Internet Service Provider) perché permette di autenticare
gli utenti e gestirne le connessioni. Utilizzando questo protocollo per gestire
l’autenticazione non è necessario il supporto di 802.1x (previsto da WPA2),
implementato solo negli ultimi sistemi operativi, inoltre la configurazione del
client che accede alla rete WiFi è sicuramente più semplice rispetto a 802.1x.
È possibile utilizzare PPPoE per gestire l’autenticazione al WiFi attraverso
un’infrastruttura come quella illustrata in figura 5.3.
83
Figura 5.3: Esempio di infrastruttura per l’autenticazione al WiFi con PPPoE
Come si può notare l’autenticazione viene rimandata ad un server RADIUS, che a sua volta utilizza LDAP per verificare le informazioni di autenticazione, mantenendo la gestione utenti in un unico punto centrallizzato. Nel
NAS è presente un server PPPoE2 ed un client RADIUS. Il server PPPoE
accetta le richieste di autenticazione provenienti dall’access point, che possono
essere fatte utilizzando il protocollo CHAP (Challenge-Handshake Authentication Protocol) oppure con MS-CHAPv2 (Microsoft CHAP v2). Il client
RADIUS mette in comunicazione il server PPPoE con il server RADIUS per
inoltrare le richieste di autenticazione, utilizzando lo stesso protocollo (CHAP
o MS-CHAPv2). Per aumentare la sicurezza può essere usato un protocollo
per cifrare i dati, come MPPE3 (Microsoft Point-to-Point Encryption), sia
per la comunicazione wireless (tra WT e AP), sia nella comunicazione tra
l’AP e il NAS.
Con questo sistema risulta molto semplice configurare un client per poter
autenticarsi, basta infatti configurare la rete in modo da utilizzare PPPoE
ed inserire username e password, e nella maggior parte dei sistemi operativi,
anche in quelli un po’ vecchi, è un’operazione molto semplice.
2
Un buon server PPPoE per ambiente Linux è Roaring Penguin PPPoE (rp-pppoe);
in ambiente Windows si può invece utilizzare RAS (Remote Access-Server).
3
MPPE non è però supportato da tutti i sistemi operativi, in particolar modo è poco
compatibile con Linux.
84
802.1x
Nello standard WPA2 per la sicurezza nelle reti wireless è previsto che
venga utilizzato 802.1x per gestire l’autenticazione. Questo sistema offre un
notevole livello di sicurezza ed anche una grande flessibilità, poiché permette
di gestire svariati metodi di autenticazione.
IEEE 802.1x è uno standard per l’autenticazione e l’autorizzazione in
rete, sviluppato in origine per reti wired, basato sul protocollo EAP (Extensible Authentication Protocol) per l’autenticazione. Sono previste tre entità
(figura 5.4):
• Authenticator: entità che richiede l’autenticazione prima di offrire un
servizio (nel nostro caso l’access point).
• Supplicant: entità che vuole accedere al servizio e dev’essere autenticata
(nel nostro caso il wireless terminal).
• Authentication server: entità che si occupa di verificare le credenziali del
supplicant a nome dell’authenticator (nel nostro caso il server RADIUS).
Figura 5.4: Schema di una infrastruttura per l’autenticazione al WiFi con
802.1x
L’autenticazione avviene tramite il protocollo EAP, che permette di
negoziare diversi metodi di autenticazione, i principali sono EAP-MD5, EAPTLS, EAP-TTLS e PEAP, già descritti nel paragrafo 3.3.3.
85
Durante il processo di autenticazione l’AP (authenticator) ha un ruolo
passivo, si occupa solo di prendere i messaggi provenienti dal WT (supplicant),
contenuti nel protocollo EAP, e metterli nel protocollo RADIUS per inoltrarli
al server (authenticator server) e viceversa. Il WT si può fidare dell’AP come
se si fidasse direttamente del server RADIUS perché AP e server RADIUS
condividono una chiave segreta utilizzata nelle loro comunicazioni. Se infine il
server RADIUS verifica con successo le credenziali, allora il WT è autenticato
e può acedere al servizio WiFI, altrimenti gli viene rifiutata la connessione.
La sicurezza di questo sistema varia a seconda del metodo di autenticazione
utilizzato, in genere sono utilizzati EAP-TLS per utilizzare i certificati X.509,
oppure PEAP per poi utilizzare MS-CHAPv2 con username e password.
PPPoE vs. 802.1x
Lo standard 802.1x ha grandi vantaggi: dà la possibilità di scegliere
il metodo di autenticazione, lo si può usare con certificati digitali e smart
card oltre, ovviamente, a username e password, usando EAP-TLS o PEAP
garantisce ottimi livelli di sicurezza ed è previsto dal nuovo standard di
sicurezza del WiFi, perciò sarebbe in assoluto da preferire a PPPoE. Purtroppo
è supportato nativamente solo negli ultimi sistemi operativi4 , percui tutti
gli utenti che hanno un sistema operativo di qualche anno fa’ si vederebbero
costretti ad installare software apposta, o esclusi dal servizio WiFi; per quanto
riguarda invece gli access point, ormai è diversi anni che viene supportato lo
standard WPA2 (quindi anche 802.1x), ma hardware troppo vecchio rischia
di non supportare questo standard.
PPPoE non è un sistema di autenticazione standard, ma è compatibile con
la maggior parte dell’hardware e con praticamente tutti i sistemi operativi;
anche il sistema basato si PPPoE però non manca di difetti, infatti il protocollo
di cifratura MPPE non è supportato da tutti i sistemi operativi e MS-CHAPv2,
utilizzato da solo (senza un tunnel cifrato), non è il massimo della sicurezza.
In definitiva WPA2 è sicuramente il futuro per quanto riguarda la sicurezza
WiFi, ma utilizzarlo come unico metodo di autenticazione rischia di tagliare
fuori parecchi utenti dal servizio wireless.
4
In ambiente windows è supportato da Windows XP SP3 in poi.
86
5.4.3
VPN
Nei capitoli precedenti abbiamo descritto cos’è una VPN. Quando un
utente prova ad accedervi per prima cosa viene creato un tunnel cifrato tra il
client (l’utente) e il server VPN. Una volta creato un tunnel cifrato con il
server VPN, l’utente dev’essere autenticato per accedere effettivamente alla
rete privata. Per fornire le credenziali di accesso al server VPN, può essere
utilizzato uno dei seguenti protocolli: CHAP, MS-CHAPv2 oppure EAP.
In praticamente tutti i server VPN è possibile specificare il meccanismo
di autenticazione; se viene fatta utilizzando username e password, può essere
impostato l’inoltro ad un server RADIUS per verificare le credenziali (che a
sua volta si riferirà al server LDAP). L’autenticazione può essere fatta anche
attraverso certificati digitali X.509, in questo caso il server VPN cercherà di
verificarne l’autenticità attraverso una Certification Authority.
Dopo che l’utente è autenticato, tramite il server RADIUS è possibile
gestirne l’autorizzazione al servizio VPN, impostando, per esempio, l’indirizzo
IP locale assegnato all’utente, la durata massima di una sessione oppure il
traffico massimo che può essere fatto.
Protocolli di tunneling
Non esiste uno standard per VPN, perciò ogni sistema può utilizzare il
protocollo che ritiene più opportuno. I protoccolli più utilizzati per creare un
tunnel sicuro sono i seguenti:
• IPsec (IP security): probabilmente il protocollo5 più utilizzato, agisce a
livello network e garantisce l’autenticazione, la confidenzialità (ovvero
la cifratura sicura del messaggio) e il controllo di integrità. Con IPSec
NAT-T è possibile anche utilizzare una VPN con un client dietro un
dispositivo NAT.
• PPTP (point-to-point tunneling protocol): sviluppato da Microsoft,
assicura autenticazione, criptazione e compressione dei dati. Utilizza
MPPE per la cifratura e può attraversare la maggior parte dei dispositivi
NAT.
5
In realtà si tratta di un insieme di protocolli, ognuno per gestire un preciso problema,
come lo scambio di chiavi o la cifratura del pacchetto.
87
• Secure Sockets Layer (SSL) / TLS: un’altro protocollo molto utilizzato
che assicura un ottimo livello di sicurezza. Garantisce confidenzialità e
integrità dei messaggi trasmessi.
• L2TP (Layer 2 Tunnelling Protocol): protocollo che agisce a livello
data-link, sviluppato da Microsoft e Cisco. Dev’essere associato ad
un altro protocollo per implementare autenticazione, confidenzialità e
integrità dei dati, in genere IPsec.
5.4.4
Risorse web
Ovviamente in molte risorse web è necessario controllare l’accesso per
limitarne l’utilizzo solo a utenti “conosciuti”. Siccome questi servizi sono
tutti accessibili tramite un browser web, un sistema di SSO, che offre diversi
vantaggi, risulta relativamente semplice da implementare, percui molto adatto
per gestirne l’accesso. Se il servizio web è però uno solo, diventa inutile ed
eccessivo implementare un sistema di SSO, è infatti sufficente interfacciare
l’applicazione web direttamente con il server LDAP per il processo di autenticazione. Come già detto LDAP è ormai uno standard e diventerà sempre
più diffuso per la gestione centralizzata degli utenti, per questo motivo le
maggiori tecnologie per lo sviluppo di applicazioni web, come PHP, JSP, ASP
e altre ancora, hanno librerie che permettono di interrogare il server LDAP,
anche in modo sicuro usando connessioni cifrate. Utilizzando una di queste
tecnologie si possono quindi scrivere applicazioni web che utilizzano LDAP
per l’autenticazione. Inoltre anche diversi CMS (tra cui drupal e joomla
per php) permettono l’autenticazione tramite un server LDAP. Infine anche
nei server web, come apache e tomcat, è possibile abilitare l’autenticazione
degli utenti, per accedere a determinate directory, utilizzando le informazioni
contenute in un server LDAP.
CAS e SSO
CAS (JA-SIG Central Authentication Service) è un servizio di SSO per
web, sviluppato come progetto open-source dall’università di Yale. Di seguito
viene illustrato il funzionamento di CAS senza però entrare nei dettagli (figura
5.5):
1. Un client cerca di accedere ad un servizio web.
88
Figura 5.5: Autenticazione ad una risorsa web tramite CAS.
2. Il servizio redirige il client all’URL del CAS, su una connessione sicura
HTTPS.
3. Il client effettua il login al server CAS. Finché l’autenticazione fallisce
rimane “bloccato” nella pagina di login.
4. Quando il login ha successo, il server CAS redirige il client alla risorsa iniziale, spedendo al browser web un cookie contenente un ticket
identificativo (Ticket-Granting Cookie).
5. Il browser del client fornisce il cookie all’applicazione.
6. L’applicazione verifica tramite il server CAS che il ticket sia valido.
7. Se il ticket è valido viene fornito il servizio richiesto.
8. Il client può ora accedere ad altri servizi web associati al CAS senza
dover autenticarsi, verrà semplicemente ricontrollato il ticket.
Il server CAS può essere configurato in modo da prendere le informazioni
di autenticazione degli utenti dal server LDAP.
Un grande svantaggio di CAS è che si limita a gestire l’autenticazione,
mentre alcune applicazioni web possono avere bisogno di informazioni per
l’autorizzazione, o in generale di ulteriori informazioni sull’utente autenticato
(oltre allo username), e per far questo è necessario trovare altre soluzioni, ad
esempio implementando un web service interfacciato con il server LDAP al
quale i servizi web si rivolgono per le informazioni sugli utenti.
89
Shibboleth
Un’altra soluzione, sempre più diffusa, è Shibboleth: un progetto opensource realizzato dal consorzio Internet2 per la creazione di una infrastruttura
di autorizzazione e autenticazione federata. Attraverso Shibboleth è possibile
creare un sistema di SSO per accedere ai servizi web resi disponibili dalla
federazione, utilizzando le informazioni di autenticazione degli utenti mantenute solamente all’interno dell’organizzazione di afferenza. Come CAS quindi
fornisce un sistema di SSO, ma in più ne permette l’utilizzo in ambiente federato. Inoltre permette ai fornitori di servizi di poter prelevare direttamente
informazioni sull’utente (percui di gestire facilmente anche l’autorizzazione),
a differenza di CAS che permette di sapere solamente l’username dell’utente
autenticato.
Fondamentalmente ci sono tre entità in gioco:
• IdP (Identity Provider): componente che serve per il processo di
autenticazione, reso disponibile dall’organizzazione di appartenenza
dell’utente.
• SP (Service Provider): fornitore del servizio a cui si può accedere
attraverso Shibboleth.
• WAYF (Where Are You From?): servizio tipicamente gestito dalla
Federazione che permette all’utente di indicare la sua organizzazione
durante il processo di autenticazione.
Il funzionamento, illustrato in figura 5.6, è il seguente:
1. L’utente, attraverso il suo browser web, cerca di accedere ad un servizio
fornito da un SP.
2. Il servizio rileva che l’utente non ha una sessione Shibboleth attiva
(altrimenti lo farebbe accedere senza ripetere l’autenticazione) e lo
redirige al servizio WAYF.
3. WAIF visualizza una pagina web nel browser dell’utente in cui si deve
scegliere l’organizzazione di afferenza (fra quelle che forniscono un IdP).
4. L’utente seleziona la sua organizzazione.
5. WAIF redirige l’utente alla pagina di autenticazione dell’IdP dell’organizzazione selezionata.
90
Figura 5.6: Schema di funzionamento di Shibboleth.
6. L’IdP visualizza la pagina di autenticazione.
7. L’utente fornisce le sue credenziali di accesso, che possono essere
una coppia username-password, ma anche un certificato digitale o
un identificatore biometrico.
8. L’IdP redirige l’utente al servizio richiesto inizialmente, e consegna al
browser dell’utente una handle che a sua volta consegnerà al SP.
9. La handle viene utilizzata dal SP per reperire in modo sicuro degli
attributi sull’utente dall’IdP.
10. L’IdP spedisce gli attributi richiesti al SP. Ora l’utente è autenticato
presso il servizio richiesto inizialmente e il servizio ha ottenuto le
informazioni sull’utente che gli servivano.
Per il processo di autenticazione l’IdP Shibboleth può esere configurato per
reperire le informazioni direttamente dal server LDAP, oppure può utilizzare
altri strumenti, ad esempio CAS (che a sua volta si appoggia al server LDAP).
5.4.5
Posta elettronica
Come già detto in precedenza, questa risorsa la si può scomporre in due
parti: il server SMTP (MTA, mail transfer agent), che si occupa di inviare e
91
recapitare la posta al destinatario, e il servizio di consultazione della mailbox
(MAA, mail access agent), ovvero il server POP3 o IMAP.
L’autenticazione per queste risorse è fondamentale, infatti si vuol impedire
ad utenti anonimi di utilizzare il server SMTP, ma soprattutto è necessario
impedire l’accesso a mailbox private senza prima essersi autenticati. Sia nel
protocollo SMTP, che nei protocolli IMAP e POP3 è previsto un meccanismo
di autenticazione6 , ed è fortemente consigliato utilizzare solo le varianti sicure
di questi protocolli (SMTPS, POP3S, IMAPS), cioè con l’utilizzo di TLS,
per proteggere la trasmissione di dati riservati.
I principali mail server, come sendmail, postfix e qmail, prevedono, se
opportunamente configurati, l’utilizzo di LDAP per reperire le informazioni
di autenticazione. Questo supporto di LDAP molto diffuso nei mail server è
dovuto al fatto che sono molto frequenti le operazioni di lettura dei dati di
autenticazione, e i server LDAP sono ottimizzati proprio per queste operazioni.
Come al solito è opportuno abilitare il protocollo TLS nella comunicazione
con il server LDAP per garantire la sicurezza dei dati.
5.4.6
Windows e Linux
Vediamo infine la gestione dell’accesso a postazioni PC. Descriviamo una
possibile infrastruttura che utilizzi LDAP per reperire le informazioni degli
utenti, considerando i casi dei due sistemi operativi più diffusi: Windows e
Linux.
Windows
In ambiente Windows un server al quale i client di una rete si connettono
per il recupero degli account è chiamato PDC (Primary Domain Controller).
Un PDC funziona attraverso il protocollo SMB (chiamato anche CIFS) di cui
SAMBA è una implementazione libera per Linux. Tramite SAMBA è quindi
possibile implementare un PDC su un server Linux.
SAMBA offre diverse funzionalità, come la condivisione di file system,
accessibile sia da client Windows che da client Linux, o la condivisione di
stampanti, ma, soprattutto, offre la possibilità di gestire l’autenticazione di
92
Figura 5.7: Clients Windows configurati per autenticare gli utenti tramite il
server SAMBA, che a sua volta prende gli attributi degli utenti dal server
LDAP.
sistemi Windows in modo centralizzato e può essere collegato ad un server
LDAP per reperire le informazioni degli utenti (figura 5.7).
Nel server LDAP è necessario aggiungere lo schema samba.schema (ottenibile da sito ufficiale di samba) e, ad ogni utente presente nel server LDAP
a cui si vuol concedere l’autenticazione a PC Windows, aggiungere le objectclass contenute in questo schema. Tra gli altri attributi di questo schema
ci sono sambaNTPassword e sambaLMPassword, nei quali va memorizzata la
password di accesso dell’utente (uguale a quella contenuta in userPassword).
Tra i vari software presenti in SAMBA c’è smbldap-tools, un insieme di
tools scritti in perl che permettono di creare e gestire utenti e gruppi in un
server LDAP in modo da poterli utilizzare con un server SAMBA.
Nei client Windows si deve impostare il dominio uguale a quello impostato
nel server SAMBA, in questo modo, quando un utente accede ad un PC
Windows, vengono verificate le credenziali di accesso (username e password)
attraverso il server SAMBA, che a sua volta le andrà a prelevare dal server
LDAP.
Per garantire che le password e i dati riservati non transitino in chiaro sulla
rete si può configurare il server SAMBA in modo da instaurare una connessione
cifrata attraverso TLS con il server LDAP. Dal lato client Windows, invece,
può essere impostato, nel server SAMBA, la trasmissione di password cifrate
(figura 5.7).
6
In realtà nel protocollo SMTP originale non è prevista l’autenticazione, è stata però
aggiunta con l’estensione SMTP-AUTH.
93
Figura 5.8: Connessioni sicure con SAMBA.
Linux
Nei sistemi Linux esistono i moduli PAM (Pluggable Authentication
Module) per gestire l’autenticazione. Questi moduli permettono di integrare
più sistemi di autenticazione di basso livello in una unica API di alto livello,
in modo che le applicazioni possano usare le API di alto livello ed essere
indipendenti dal metodo di autenticazione utilizzato. PAM è supportato
anche nei sistemi BSD, MacOS X e Solaris.
Tra questi moduli è presente il modulo pam_ldap che permette di autenticare gli utenti con i dati presenti in un server LDAP. Per configurare il client
Linux in modo che utilizzi LDAP per autenticarsi è necessario installare e
configurare le librerie libpam-ldap e libnss-ldap, la prima necessaria per
impostare correttamente i moduli PAM, la seconda permette di modificare
il file nsswitch.conf in modo che il client Linux consideri utenti locali gli
utenti presenti nel server LDAP.
Figura 5.9: Autenticazione di client Linux sfruttando direttamente il server
LDAP.
In LDAP è necessario aggiungere le object-class account, posixAccount
94
e shadowAccount ad ogni utente al quale si vuol concedere l’accesso ai PC
Linux. L’utility cpu (Change Password Utility) permette di aggiungere e
modificare gli utenti nel server LDAP in modo semplice e intuitivo.
Per garantire un certo livello di sicurezza per la trasmissione di dati
riservati, come si è fatto per la connessione tra il server SAMBA e LDAP, è
possibile configurare i moduli PAM in modo da instaurare una connessione
con TLS tra il client Linux e il server LDAP.
Un altro modo per gestire l’autenticazione nei client Linux è di utilizzare
il server SAMBA (che a sua volta utilizza il server LDAP) come per i
client Windows; questo metodo è disponibile dalla versione 2.2.2 di SAMBA
attraverso il demone winbindd lato server; dal lato client, invece, vanno
opportunamente configurati i moduli PAM e il file nsswitch.conf in modo da
utilizzare la libreria Winbind (presente nel pacchetto SAMBA).
5.4.7
Schema del progetto
Figura 5.10: Schema di tutte le risorse illustrate in precedenza, con uno
sguardo anche ai protocolli di sicurezza utilizzati.
Vediamo allora, nella figura 5.10, uno schema nel quale sono rappresentati
tutte le risorse descritte in precedenza, con i collegamenti che rappresentano
lo scambio delle informazioni di autenticazione e autorizzazione, evidenziando
anche i protocolli sicuri utilizzati per trasmettere i dati riservati. Da notare che
95
tutte le risorse, in modo diretto o indiretto, prelevano le informazioni di accesso
dal server LDAP che implementa perfettamente uno IAM centralizzato.
5.5
Trasmissione sicura dei dati riservati
In una infrastruttura di autenticazione e autorizzazione è previsto che
vengano spesso trasmessi dati riservati, come le password degli utenti al
momento dell’autenticazione, si vuole perciò essere sicuri che questi dati non
possano essere intercettati e letti da persone malintenzionate. Per far questo,
ogni risorsa, deve utilizzare dei sistemi di sicurezza appropriati, per esempio
possono essere utilizzati protocolli sicuri che cifrano la trasmissione di dati.
Questi sistemi di sicurezza, relativi ad ogni risorsa, sono stati trattati in
dettaglio nel paragrafo precedente, vediamone un rapido riassunto:
LDAP
Ogni connessione con il server LDAP deve avvenire utilizzando protocolli
sicuri come SSLv3 o TLSv1, supportati entrambi da OpenLDAP. Inoltre
è opportuno creare un utente specifico, con permessi appropriati, per ogni
tecnologia per l’accesso che utilizza i dati degli utenti e, ovviamente, configuare
la tecnologia in questione per accedere ad LDAP con il suo particolare utente.
Per esempio si può creare un utente “radius” in OpenLDAP, con permessi in
sola lettura sui dati degli utenti, e configurare freeRADIUS per accedere a
OpenLDAP instaurando una connessione TLS e autenticandosi come utente
“radius”.
Per proteggere i dati memorizzati sul server LDAP stesso si possono
definire delle apposite ACL (Access Control List), anche molto complesse,
che possono regolare l’accesso anche sul singolo attributo.
RADIUS
Il server RADIUS è utilizzato dal WiFi e da VPN, per entrambi si può
utilizzare il protocollo PEAP per effettuare l’autenticazione tramite username
e password.
96
WiFi
Come già detto in precedenza, le connessioni wireless possono essere un
vero problema per la semplicità con cui si può intercettare una comunicazione. Utilizzando lo standard WPA2 per l’autenticazione e la cifratura delle
trasmissioni si riesce ad ottenere un ottimo livello di sicurezza.
VPN
Per creare il tunnel VPN può essere utilizzato IPsec, mentre per l’autenticazione con username e password il protocollo PEAP che viene inoltrato al
server RADIUS.
SAMBA
Nel protocollo SAMBA è previsto che possano essere trasmesse le password
cifrate per l’autenticazione dei PC Windows.
CAS
Tutte le autenticazioni dei servizi WEB avvengono tramite il server CAS.
Con questo sistema è già previsto l’utilizzo del protocollo HTTPS (HTTP
con TLS) per la trasmissione delle credenziali di autenticazione.
5.6
Gestione del carico: affidabilità e performance
Due problemi da non sottovalutare per un sistema con molteplici risorse
web, posta eletronica, accesso alla rete e laboratori informatici, con un alto
numero di utenti che utilizza queste risorse, sono affidabilità e performance.
Un sistema informatico che non dà continuità di servizio oppure risponde in
tempi inaccettabili, in cui gli utenti periodicamente non possono accedere
alle risorse informatiche perché la gestione dell’accesso non è disponibile o
bisogna aspettare diversi minuti prima di potervi accedere, è di fatto un
sistema inutile. Vediamo allora come possiamo gestire queste problematiche.
Diremo che un sistema è disponibile se i suoi utenti possono disporne
sottomettendo nuovo lavoro, modificando lavori già esistenti o recuperando i
risultati di lavori sottomessi precedentemente. Se anche solo una di queste
azioni non è possibile, allora il sistema non è disponibile.
97
Diremo inoltre che il bilanciamento del carico è la capacità di un
sistema informatico di aumentare o diminuire la propria capacità elaborativa
in base al numero di clienti che richiedono il servizio. Questa capacità può
essere raggiunta utilizzando due modalità operative:
• Senza direttore, ovvero i client accedono direttamente al pool di
risorse disponibili.
• Con direttore, ovvero un server è incaricato di raccogliere le richieste
dell’utente e di indirizzarle al server che le soddisferà.
Con il termine downtime intendiamo il tempo in cui il sistema non è
disponibile. La non disponibilità può essere dovuta a diverse cause:
• Fenomeni ambientali (interruzione dell’energia elettrica, blocco del
condizionamento, eventi fisici eccezionali).
• Guasti hardware ai sistemi.
• Interruzione della connettività.
• Malfunzionamento del software (indisponibilità dei sistemi di frontend,
degli application server, dei database).
Per la gestione dell’alta disponibilità ed il bilanciamento del carico a
livello applicativo utilizziamo due strumenti:
• Heartbeat
• Linux Virtual Server
5.6.1
Heartbeat
Heartbeat è un sistema molto semplice che, date due macchine, permette
di spostare molto velocemente uno o più indirizzi IP da una macchina all’altra
ed attivare o disattivare uno o più servizi su una o l’altra macchina. La
configurazione può essere di tipo attivo/passivo o attivo/attivo.
In una configurazione attivo/passivo, solamente una delle due macchine è
utilizzata per erogare il servizio. Le due macchine possono tenersi in contatto
sia tramite un cavo seriale, sia tramite la rete su cui erogano i servizi oppure
attraverso una rete privata interna.
98
In caso di guasto, l’indirizzo IP del servizio viene spostato dalla macchina
fallita alla macchina superstite. Contemporaneamente possono essere attivati
uno o più servizi sulla macchina superstite.
In una configurazione attivo/attivo, entrambe le due macchine erogano
il servizio. L’erogazione di un medesimo servizio su più indirizzi IP può
essere realizzata definendo più indirizzi IP per lo stesso nome host. In caso di
fallimento, l’indirizzo IP della macchina fallita viene spostato sulla macchina
superstite che assume entrambi gli indirizzi.
Per monitorare le disponibilità di un servizio esiste un tool molto potente
chiamato MON, che compie determinate azioni (dal semplice PING all’analisi
di un risultato di una transazione a livello applicativo) al verificarsi di
condizioni stabilite. Inoltre MON può essere configurato per spedire un’email,
attivare un ticket di assistenza oppure scatenare il failover di un sistema di
alta disponibilità come Heartbeat.
5.6.2
Linux Virtual Server
L’obiettivo di Linux Virtual Server Project è quello di fornire un
framework di base per la costruzione di servizi di rete scalabili e ad alta
disponibilità utilizzando dei comuni server.
Linux Virtual Server è implementato direttamente nel kernel e sono
disponibili tre diversi sistemi di bilanciamento:
• Virtual Server via NAT
• Virtual Server via IP Tunneling
• Virtual Server via Direct Routing
Linux Virtual Server ha al suo interno diversi algoritmi di schedulazione:
• Round-Robin
• Weighted Round-Robin
• Least-Connection
• Weighted Least-Connection
• Locality-Based Least-Connection
• Locality-Based Least-Connection with Replication
99
• Source Hashing
• Destination Hashing
• Shortest Expected Delay
• Never Queue
5.6.3
Architettura per il bilanciamento del carico
Vediamo come possiamo utilizzare Heartbeat e Linux Virtual Server per
risolvere le problematiche del nostro progetto.
Una soluzione è disporre due server Linux Virtual Server. I due server
sono configurati in un cluster-HA attivo/passivo, quindi uno dei nodi
esegue effettivamente il servizio e l’altro è pronto a rilevarlo in caso di
malfunzionamento.
I software usati sono:
• ipvs + ipvsadm (i software del progetto Linux Virtual Server, rispettivamente modulo del kernel e utilità di gestione);
• Heartbeat e ldirectord (software del progetto Linux-HA che serve a
configurare il load balancing e controllare lo stato dei server che offrono
i servizi, ovvero i real server).
Prima di questa soluzione architetturale, i client che avevano bisogno dei
servizi puntavano direttamente ai server, mal bilanciando il carico di richieste.
Usando Linux Virtual Server le richieste ai vari server vengono distribuite
in maniera più che accettabile, al contrario prima si cercava di sopperire a
tale mancanza per esempio impostando i vari client LDAP per interrogare
preferenzialmente un certo server invece che un altro. Si potrebbero migliorare
ulteriormente le cose impostando meccanismi più sofisticati di monitoraggio
del carico dei real server.
I vantaggi dati dall’uso di questa architettura ricadono anche in termini
di sicurezza e affidabilità, difatti gli IP dei real server non appaiono mai, ma
appaiono solo quello del servizio (che risisede sul load balancer), in questo
modo facendo scansioni all’IP dei servizi l’unica porta che si trova aperta
è quella del servizio stesso. Il miglioramento in termini di affidabilità è la
ragione principale che porta a una soluzione di questo tipo. I metodi usati
in precedenza per garantire l’affidabilità non si son dimostrati adeguati. Per
100
quel che riguarda LDAP, per esempio, i client erano configurati per contattare
un altro server in caso di mancata risposta del primario, solo che l’attesa
del timeout fra la richiesta al primario e quella al secondario penalizzava
eccessivamente le prestazioni.
Con Linux Virtual Server i real server vengono tenuti costantemente
sotto controllo e in caso di non disponibilità di uno dei real server tutte le
connessioni vengono reindirizzate agli altri.
L’unica alternativa a Linux Virtual Server che è stata valutata è un load
balancer hardware, che si è dimostrato meno flessibile (funzionamento solo in
modalità natting e possibilità di monitorare un numero esiguo di servizi) in
quanto pensato soprattutto per i server web.
Con questa soluzione quindi si risolvono problemi di carico e di danneggiamento dei server, quindi di affidabilità e performance.
5.7
IDEM: federazione della rete GARR
IDEM (IDEntity Management) è un progetto pilota del GARR per la
realizzazione di una AAI federata per le organizzazioni afferenti. Grazie a
questo progetto sarà possibile utilizzare una procedura standard di autenticazione per l’accesso ai servizi della rete dove ogni utente avrà una chiave
d’accesso unica. I vantaggi offerti da una AAI federata sono descritti nel
paragrafo 2.2.
Ogni organizzazione che vuol partecipare al progetto dovrà realizzare
un Identity Provider Shibboleth (IdP), mentre ogni risorsa dovrà aderire
ad una serie di standard tecnici scelti dalla federazione. L’università di
Parma, siccome fa parte di questo progetto, deve fornire un IdP, illustrato
nel paragrafo 5.4.4.
5.7.1
Attributi IDEM
Per il funzionamento del progetto, in particolare per il corretto funzionamento dei fornitori di risorse, viene richiesta una standardizzazione degli
attributi tra i membri della federazione che forniscono un IdP, percui ogni
membro dovrà fornire un certo elenco di attributi stabiliti nel progetto IDEM
dal gruppo di lavoro GARR-AAI. Nella tabella seguente vengono riportati
gli attributi richiesti, con una breve descrizione del contenuto che dovranno
avere, e con l’object class LDAP alla quale appartengono. Da notare che
101
tutti gli attributi sono già presenti nel nuovo schema LDAP siccome le object
class utilizzate dal progetto IDEM sono già all’interno della struttura della
entry base (vedere a pagina 70).
Caratteristiche personali
Nome LDAP
Objectclass
Descrizione
Stato
sn
person
Cognome
opzionale
givenName
inetOrgPerson
Nome
opzionale
cn
person
Nome seguito da cognome
raccomandato
preferred
Language
inetOrgPerson
Lingua scritta o parlata preferita dal soggetto
raccomandato
schachMother
Tongue
schacPersonal
Characteristics
Lingua madre del soggetto
opzionale
title
organizational
Person
Titolo nel contesto dell’organizzazione. Es. “Direttore”,
“Responsabile Reparto X” ecc.
opzionale
schacPersonal
Title
schacPersonal
Characteristics
Titolo usato per salutare il soggetto. Es: Sig., Sig.ra, Dott.,
Prof.
opzionale
schacPersonal
Position
schacPersonal
Characteristics
Il codice rappresentativo dell’inquadramento della persona
all’interno dell’organizzazione
opzionale
Nome LDAP
Objectclass
Descrizione
Stato
mail
inetOrgPerson
Indirizzo eMail
raccomandato
telephoneNumber
person
Recapito telefonico ufficio
opzionale
mobile
inetOrgPerson
Recapito cellulare di servizio
opzionale
facsimile
TelephoneNumber
organizational
Person
Recapito fax
opzionale
schacUser
PresenceID
schacContact
Location
Recapiti relativi a diversi protocolli di rete
opzionale
eduPersonOrgDN
eduPerson
Il Distinguished Name (DN)
della entry che rappresenta
l’organizzazione di appartenenza alla quale la persona è
associata
opzionale
Contatti
102
Nome LDAP
Objectclass
Descrizione
Stato
eduPerson
OrgUnitDN
eduPerson
Il Distinguished Name (DN)
della entry che rappresenta l’unità organizzativa di appartenenza alla quale la persona è associata (ad esempio
Dipartimento)
opzionale
Autorizzazioni e accounting
Nome LDAP
Objectclass
Descrizione
Stato
eduPersonScoped
Affiliation
eduPerson
Affiliazione secondo le convenzioni descritte gruppo GARRAAI
obbligatorio
eduPerson
TargetedID
eduPerson
Identificativi anonimi persistenti per l’utente relativi ai
diversi Servizi
obbligatorio
eduPerson
Entitlement
eduPerson
URI (URN o URL) che indica
un diritto (standardizzato) di
accesso ad una risorsa
raccomandato
103
104
Capitolo 6
Conclusioni
Tramite questo progetto è quindi possibile realizzare una infrastruttura
di gestione dell’accesso centralizzata, mantenendo la tanto agognata identità
unica per ogni utente.
Facendo un rapido riassunto, si è realizzato un sistema IAM centralizzato, che semplifica l’amministrazione degli utenti e permette agli utenti
stessi di accedere a tutte le risorse informatiche utilizzando sempre le stesse
credenziali di accesso. Il progetto si è occupato di riorganizzare il server
IAM, mantenendo la ottima divisione in RDBMS-LDAP, ma cambiando la
gestione interna delle identità digitali. Inoltre si è mostrato come sia possibile centralizzare con il server IAM la gestione dell’accesso per ogni risorsa
informatica disponibile nell’università. Il tutto concentrandosi anche sulle
problematiche fondamentali di un sistema centralizzato: sicurezza, affidabilità
e performance.
Ovviamente sono da tenere conto gli impatti del progetto sugli utenti,
sui gestori delle risorse e sull’università. Per gli utenti l’impatto è nullo
oppure basso, comunque positivo, ai quali si semplifica l’accesso alle risorse
informatiche. Per i gestori delle risorse può essere medio-basso, poiché in
genere dovranno comunque aggiornare la gestione dell’accesso per il nuovo
sistema, a parte alcune risorse critiche che vengono gestite esternamente,
per esempio la posta elettronica degli studenti gestita dal CINECA, per
la quale non sarà più possibile separare i dati degli studenti da quelli dei
non-studenti, ma vi è la possibilità che le procedure del CINECA funzionino
ugualmente. Infine l’università non potrà che trarne vantaggi da una gestione
di questo tipo: la fornitura di nuove risorse può avvenire con minori sforzi, ed
105
in generale lo scopo del progetto è esattamente quello di semplificare l’intera
gestione degli utenti ed aumentare la produttività.
L’intero progetto tiene conto anche di eventuali sviluppi futuri. Oltre
alla possibilità di introdurre facilmente nuove risorse nel sistema, puntando
sull’estrema flessibilità di LDAP e sulla sua diffusione, si è tenuto conto
anche dell’introduzione di nuovi metodi di accesso, dei certificati digitali
soprattutto. Essendo il futuro, oramai anche molto vicino, l’introduzione
dei certificati digitali non comporta una rivoluzione del sistema di accesso.
Sarà infatti sufficente introdurre una PKI per il controllo del certificato
al momento dell’autenticazione, dopodiché, una volta verificata l’identità
dell’utente, il processo di autorizzazione rimane invariato. Il server LDAP
offre inoltre la possibilità di memorizzare i certificati digitali degli utenti,
permettendo in questo modo di mantenere la loro chiave pubblica assieme
alle altre informazioni sull’identità, in modo da poter sfruttare i certificati
digitali anche per la comunicazione (e la mutua autenticazione) fra utenti
all’interno dell’università.
106
Appendice A
Schema LDAP
Di seguito è riportato il nuovo schema LDAP definito durante il progetto.
###############################################################
#
#
# unipr.schema v: 20092201
#
#
#
# Definizione dello schema LDAP per l’Universita‘ di Parma
#
#
#
###############################################################
objectIdentifier unipr 1.3.6.1.4.14657.1.1
objectIdentifier uniprObjectClass unipr:2
objectIdentifier uniprAttributeType unipr:3
###############################################################
# Attributi
#
###############################################################
#
# uniprCodiceFiscale
#
attributetype ( uniprAttributeType:1
107
NAME ’uniprCodiceFiscale’
DESC ’’
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SINGLE-VALUE
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
)
#
# uniprLuogoDiDomicilio
#
attributetype ( uniprAttributeType:2
NAME ’uniprLuogoDiDomicilio’
DESC ’’
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SINGLE-VALUE
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
)
#
# uniprProvinciaDiDomicilio
#
attributetype ( uniprAttributeType:3
NAME ’uniprProvinciaDiDomicilio’
DESC ’’
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SINGLE-VALUE
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
)
#
# uniprStatoDiDomicilio
#
attributetype ( uniprAttributeType:4
108
NAME ’uniprStatoDiDomicilio’
DESC ’’
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SINGLE-VALUE
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
)
#
# uniprViaDiResidenza
#
attributetype ( uniprAttributeType:5
NAME ’uniprViaDiResidenza’
DESC ’’
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SINGLE-VALUE
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
)
#
# uniprCAPdiResidenza
#
attributetype ( uniprAttributeType:6
NAME ’uniprCAPdiResidenza’
DESC ’’
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SINGLE-VALUE
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
)
#
# uniprRuoliRicoperti
#
attributetype ( uniprAttributeType:7
109
NAME ’uniprRuoliRicoperti’
DESC ’’
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
)
#
# uniprMatricola
#
attributetype ( uniprAttributeType:8
NAME ’uniprMatricola’
DESC ’’
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SINGLE-VALUE
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
)
#
# uniprAnnoUltimoPagamento
#
attributetype ( uniprAttributeType:9
NAME ’uniprAnnoUltimoPagamento’
DESC ’’
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SINGLE-VALUE
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
)
#
# uniprAnnoPrimaImmatricolazione
#
attributetype ( uniprAttributeType:10
NAME ’uniprAnnoPrimaImmatricolazione’
110
DESC ’’
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SINGLE-VALUE
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
)
#
# uniprAnnoLaureaTriennale
#
attributetype ( uniprAttributeType:11
NAME ’uniprAnnoLaureaTriennale’
DESC ’’
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SINGLE-VALUE
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
)
#
# uniprAnnoLaureaSpecialistica
#
attributetype ( uniprAttributeType:12
NAME ’uniprAnnoLaureaSpecialistica’
DESC ’’
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SINGLE-VALUE
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
)
#
# uniprCorsoLaurea
#
attributetype ( uniprAttributeType:13
NAME ’uniprCorsoLaurea’
111
DESC ’’
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SINGLE-VALUE
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
)
#
# uniprIDSGEDipendente
#
attributetype ( uniprAttributeType:14
NAME ’uniprIDSGEDipendente’
DESC ’’
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SINGLE-VALUE
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
)
#
# uniprDataInizioRuolo
#
attributetype ( uniprAttributeType:15
NAME ’uniprDataInizioRuolo’
DESC ’’
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SINGLE-VALUE
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
)
#
# uniprDataFineRuolo
#
attributetype ( uniprAttributeType:16
NAME ’uniprDataFineRuolo’
112
DESC ’’
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SINGLE-VALUE
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
)
#
# uniprProfilo
#
attributetype ( uniprAttributeType:17
NAME ’uniprProfilo’
DESC ’’
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SINGLE-VALUE
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
)
#
# uniprCategoria
#
attributetype ( uniprAttributeType:18
NAME ’uniprCategoria’
DESC ’’
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SINGLE-VALUE
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
)
#
# uniprStatoRuolo
#
attributetype ( uniprAttributeType:19
NAME ’uniprStatoRuolo’
113
DESC ’’
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SINGLE-VALUE
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
)
#
# uniprIncarico
#
attributetype ( uniprAttributeType:20
NAME ’uniprIncarico’
DESC ’’
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SINGLE-VALUE
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
)
#
# uniprAree
#
attributetype ( uniprAttributeType:21
NAME ’uniprAree’
DESC ’’
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
)
#
# uniprSettore
#
attributetype ( uniprAttributeType:22
NAME ’uniprSettore’
DESC ’’
114
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
)
#
# uniprServizi
#
attributetype ( uniprAttributeType:23
NAME ’uniprServizi’
DESC ’’
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
)
#
# uniprSezioni
#
attributetype ( uniprAttributeType:24
NAME ’uniprSezioni’
DESC ’’
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
)
#
# uniprFuturaMatricola
#
attributetype ( uniprAttributeType:25
NAME ’uniprFuturaMatricola’
DESC ’’
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SINGLE-VALUE
115
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
)
#
# uniprAnnoPrimaImmatricolazioneFuturaMatricola
#
attributetype ( uniprAttributeType:26
NAME ’uniprAnnoPrimaImmatricolazioneFuturaMatricola’
DESC ’’
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SINGLE-VALUE
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
)
#
# uniprCorsoLaureaFuturaMatricola
#
attributetype ( uniprAttributeType:27
NAME ’uniprCorsoLaureaFuturaMatricola’
DESC ’’
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SINGLE-VALUE
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
)
#
# uniprFacoltaFuturaMatricola
#
attributetype ( uniprAttributeType:28
NAME ’uniprFacoltaFuturaMatricola’
DESC ’’
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SINGLE-VALUE
116
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
)
#
# uniprIDSGEProfessoreAContratto
#
attributetype ( uniprAttributeType:29
NAME ’uniprIDSGEProfessoreAContratto’
DESC ’’
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SINGLE-VALUE
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
)
#
# uniprCodiceSISAProfessoreAContratto
#
attributetype ( uniprAttributeType:30
NAME ’uniprCodiceSISAProfessoreAContratto’
DESC ’’
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SINGLE-VALUE
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
)
#
# uniprDataInizioRuoloProfessoreAContratto
#
attributetype ( uniprAttributeType:31
NAME ’uniprDataInizioRuoloProfessoreAContratto’
DESC ’’
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SINGLE-VALUE
117
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
)
#
# uniprDataFineRuoloProfessoreAContratto
#
attributetype ( uniprAttributeType:32
NAME ’uniprDataFineRuoloProfessoreAContratto’
DESC ’’
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SINGLE-VALUE
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
)
#
# uniprCodiceRuoloProfessoreAContratto
#
attributetype ( uniprAttributeType:33
NAME ’uniprCodiceRuoloProfessoreAContratto’
DESC ’’
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SINGLE-VALUE
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
)
#
# uniprProfiloProfessoreAContratto
#
attributetype ( uniprAttributeType:34
NAME ’uniprProfiloProfessoreAContratto’
DESC ’’
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SINGLE-VALUE
118
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
)
#
# uniprCategoriaProfessoreAContratto
#
attributetype ( uniprAttributeType:35
NAME ’uniprCategoriaProfessoreAContratto’
DESC ’’
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SINGLE-VALUE
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
)
#
# uniprStatoRuoloProfessoreAContratto
#
attributetype ( uniprAttributeType:36
NAME ’uniprStatoRuoloProfessoreAContratto’
DESC ’’
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SINGLE-VALUE
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
)
#
# uniprAreeProfessoreAContratto
#
attributetype ( uniprAttributeType:37
NAME ’uniprAreeProfessoreAContratto’
DESC ’’
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
119
)
#
# uniprSettoreProfessoreAContratto
#
attributetype ( uniprAttributeType:38
NAME ’uniprSettoreProfessoreAContratto’
DESC ’’
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
)
###############################################################
# ObjectClass
#
###############################################################
#
# uniprPersona
#
objectclass ( uniprObjectClass:1
NAME ’uniprPersona’
DESC ’Attributi base per un utente generico’
SUP inetOrgPerson
STRUCTURAL
MUST ( uniprIDIdentita $ sn $ givenName $
uniprCodiceFiscale $ mail )
MAY ( street $ postalCode $ uniprLuogoDiDomicilio $
uniprProvinciaDiDomicilio $ uniprStatoDiDomicilio $
postalAddress $ uniprViaDiResidenza $ uniprCAPdiResidenza $
l $ st $ homePostalAddress $ homePhone $ telephoneNumber $
mobile $ facsimileTelephoneNumber $ uniprRuoliRicoperti )
)
#
120
# uniprStudente
#
objectclass ( uniprObjectClass:2
NAME ’uniprStudente’
DESC ’Attributi per uno studente’
AUXILIARY
MUST ( uniprMatricola $ uniprCorsoLaurea $ ou )
MAY ( uniprAnnoUltimoPagamento $
uniprAnnoPrimaImmatricolazione $ uniprAnnoLaureaTriennale $
uniprAnnoLaureaSpecialistica )
)
#
# uniprDipendente
#
objectclass ( uniprObjectClass:3
NAME ’uniprDipendente’
DESC ’Attributi per un dipendente’
AUXILIARY
MUST ( uniprIDSGEDipendente $ employeeNumber $ employeeType )
MAY ( uniprDataInizioRuolo $ uniprDataFineRuolo $
uniprProfilo $ uniprCategoria $ uniprStatoRuolo $
uniprIncarico $ uniprAree $ uniprSettore $
departmentNumber $ uniprServizi $ uniprSezioni )
)
#
# uniprFuturaMatricola
#
objectclass ( uniprObjectClass:4
NAME ’uniprFuturaMatricola’
DESC ’Attributi per una futura matricola’
AUXILIARY
MUST ( uniprFuturaMatricola $
uniprCorsoLaureaFuturaMatricola $
uniprFacoltaFuturaMatricola )
121
MAY ( uniprAnnoPrimaImmatricolazioneFuturaMatricola )
)
#
# uniprProfessoreAContratto
#
objectclass ( uniprObjectClass:5
NAME ’uniprProfessoreAContratto’
DESC ’Attributi per una futura matricola’
AUXILIARY
MUST ( uniprIDSGEProfessoreAContratto $
uniprCodiceSISAProfessoreAContratto )
MAY ( uniprDataInizioRuoloProfessoreAContratto $
uniprDataFineRuoloProfessoreAContratto $
uniprCodiceRuoloProfessoreAContratto $
uniprProfiloProfessoreAContratto $
uniprCategoriaProfessoreAContratto $
uniprStatoRuoloProfessoreAContratto $
uniprAreeProfessoreAContratto $
uniprSettoreProfessoreAContratto )
)
###############################################################
# Fine di unipr.schema
#
###############################################################
122
Bibliografia
[1] Maria Andreetta.
Identity e access management. L’ora della
centralizzazione. Lineaedp.
[2] Paolo Atzeni, Stefano Ceri, Stefano Paraboschi, and Riccardo Torlone.
Basi di dati. Concetti, linguaggi e architetture. McGraw-Hill, 1996.
[3] Fabio Bucciarelli. LDAP, 2003. http://lia.deis.unibo.it/Courses/
AmmReti0304/ldap.pdf.
[4] Virginia Calabritto. Le Infrastrutture di Autenticazione e Autorizzazione
(AAI) e IDEM. Giugno 2008.
[5] Rocco De Marco. AAA in ambiente OpenSource: PPPoE, LDAP,
RADIUS, 2006.
[6] Giulio Destri. Introduzione ai sistemi informativi aziendali. Monte
Università Parma Editore, 2007.
[7] Fulvio Ferroni. Samba e OpenLDAP. Fulvio Ferroni, 2007.
[8] Luca
Ferroni.
Autenticazione
centralizzata
con
OpenLDAP.
http://www.bo.cnr.it/corsi-di-informatica/seminarioldap/
Autenticazione%20centralizzata%20con%20OpenLDAP.pdf.
[9] GARR. Infrastruttura di Autenticazione e Autorizzazione della rete
GARR. http://www.idem.garr.it/.
[10] Internet2.
Identity and Access Management, 2007.
http://www.
internet2.edu/pubs/200703-IS-MW.pdf.
[11] Giuseppe Lo Biondo. Gestione centralizzata delle utenze tramite LDAP,
2000. http://security.fi.infn.it/conferenze/fi00/ldap.pdf.
123
[12] Maria Laura Mantovani.
l’accesso ai servizi.
IDEntity Management federato per
Università di Modena e Reggio Emilia.
http://www.garr.it/eventiGARR/ws08/presentazioni/Tutorial%
20-%20IDEM/Mantovani_WSGARR08.pdf.
[13] Marco Panella. Identity and Access Management (IAM) e Authentication
and Authorization Infrastructure (AAI) in ambiente federato, 2008. www.
siti.unipr.it/?download=IAM_AAI_20080512.ppt.
[14] Giuseppe Paternò. Sicurezza Nelle Wireless LAN. Giuseppe Paternò,
2003.
[15] Giuseppe Paternò. Single Sign-On con Kerberos e LDAP. Giuseppe
Paternò, 2004.
[16] Antonio Radesca. OpenLDAP, 2002. http://www.dia.unisa.it/~ads/
corso-security/www/CORSO-0203/openLDAP.pdf.
[17] Eugenio
Rustico.
2007.
Identity
Management
Systems,
http://neodimio.files.wordpress.com/2008/05/
identity-management-systems.pdf.
[18] Stefano Sasso. Autenticazione degli utenti centralizzata con LDAP.
A.P.S. Faber Libertatis. http://faberlibertatis.org/w/images/b/
b3/Autenticazione_LDAP.pdf.
[19] Omar Schiaratura. Reti miste Linux-Windows con autenticazioni centralizzate. Novembre 2005. http://www.omarschiaratura.it/file/sec_
day2005.pdf.
[20] SWITCH. Authentication and Authorization Infrastructure (AAI). http:
//www.switch.ch/aai/.
[21] Andrew S. Tanenbaum. Reti di calcolatori. Pearson Education Italia,
2005.
[22] Wikipedia.
Identità digitale.
http://it.wikipedia.org/wiki/
Identit%C3%A0_digitale.
[23] Wikipedia.
Lightweight Directory Access Protocol.
wikipedia.org/wiki/Ldap.
124
http://en.
[24] Wikipedia. Single sign-on. http://en.wikipedia.org/wiki/Single_
sign_on.
125