Progetto di gestione dell`Identit`a in un sistema di Identity and

Università degli studi di Parma
Facoltà di Scienze Matematiche Fisiche Naturali
Corso di Laurea in Informatica
Tesi di Laurea in
Basi di Dati
Progetto di gestione dell’Identità
in un sistema di
Identity and Access Management
di Ateneo
Relatore
Candidato
Chiar.mo Prof. Roberto Alfieri
Francesco Beccari
Corelatore
Dott. Ing. Marco Panella
Anno Accademico 2008/2009
Indice
1 Obbiettivo
3
2 Introduzione
2.1 IAM . . . . . . . . . . . . . . . . . .
2.2 Identità e ciclo di vita delle Identità
2.2.1 Identità . . . . . . . . . . . .
2.2.2 Ciclo di vita delle Identità . .
2.3 Implementare un server IAM . . . .
2.3.1 LDAP . . . . . . . . . . . . .
2.3.2 Database e DBMS . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3 Vincoli progettuali
3.1 Il contesto . . . . . . . . . . . . . . . . . . . .
3.1.1 Fonti: situazione attuale . . . . . . . .
3.1.2 Identità: situazione attuale . . . . . .
3.1.3 Risorse disponibili agli utenti . . . . .
3.2 Attuale gestione delle identità e degli accessi
3.2.1 Database . . . . . . . . . . . . . . . .
3.2.2 Problematiche della gestione attuale .
3.3 Sicurezza, coerenza e affidabilità . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4
4
9
9
10
13
13
14
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
19
19
19
22
24
25
26
26
27
4 Progetto
4.1 Progetto logico . . . . . . . . . . . . . . . . . . . . .
4.2 Architettura generale . . . . . . . . . . . . . . . . . .
4.3 Fonti . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3.1 DBMS scelto . . . . . . . . . . . . . . . . . .
4.3.2 Database unificato . . . . . . . . . . . . . . .
4.3.3 La gestione delle figure esterne all’Università
4.3.4 Sicurezza nel trattamento dei dati . . . . . .
4.4 Identità unica e ciclo di vita dell’identità . . . . . .
4.5 Dati da replicare sul server LDAP . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
30
31
32
34
34
34
39
42
50
53
1
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5 Conclusioni
56
5.1 Sviluppi futuri . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
A Glossario
59
B Dump MySQL
60
C Istruzioni per importare il database dallo script
74
2
Capitolo 1
Obbiettivo
L’obbiettivo di questa tesi è lo studio della gestione delle Identità in un sistema di Identity and Access Management di Ateneo.
Questa tesi è parte costituente dello studio intero di un progetto di Identity and Access Management dell’Università di Parma, ma ne approfondisce appunto solo l’aspetto
relativo alla gestione delle Identità.
L’obbiettivo in sintesi di tale progetto è quello di uniformare gli accessi ai servizi offerti dall’Università di Parma, in modo da evitare il proliferare di account diversi per
ogni funzionalità offerta, semplificando notevolmente la vita agli utenti che dei servizi
ne fanno uso ogni giorno.
Per Identity and Access Management si intende (a grandi linee) un sistema hardware e software che gestisce gli accessi (ovvero la possibilità di entrare o meno e con
quali privilegi) a un sistema informativo e in modo particolare ai servizi che tale sistema
offre. Si dovrà arrivare ad una situazione nella quale ogni utente sarà presente una ed
una sola volta nel sistema (diventando quindi a tutti gli effetti una identità digitale) e
con tali credenziali (sempre le stesse) potrà accedere a ogni servizio (secondo le possibilità che i sui ruoli all’interno dell’universitá gli consentono).
Quindi in questa tesi verrà posta l’attenzione solamente sulle problematiche dell’ Identity Management, tralasciando invece l’Access Management.
3
Capitolo 2
Introduzione
In questo capitolo verranno introdotti, dal punto di vista teorico, tutti gli aspetti analizzati al momento del progetto, ovvero tutti quei principi fondamentali dell’Identity
Management (e quelli più significativi dell’Access Management).
2.1
IAM
Il problema del riconoscimento dell’utente e dell’attribuzione dei relativi permessi è un
problema tipico di tutte quelle situazioni in cui vengono forniti particolari servizi informatici (servizi WEB, servizi di accesso a Internet, servizi di accesso a terminali Linux e
Windows, posta elettronica, ...) che richiedano quindi un autenticazione e autorizzazione.
Ma cosa si intende per autenticazione ed autorizzazione?
L’Autenticazione è il processo che verifica l’identità ovvero risponde alla domada:
l’utente è chi dice di essere?
L’Autorizzazione invece è il processo che consente l’accesso alle risorse solamente
a coloro che hanno i diritti (in base al loro ruolo) di usarle.
Queste problematiche sono gestite dall’ Identity and Access Management che è
l’intero processo (applicazione di policy appropriate ed impiego di strumenti tecnologici)
volto a gestire le informazioni riguardanti le identità degli utenti e controllarne l’accesso
alle risorse aziendali.
Esistono due situazioni estreme a tale problematica [7]:
• ogni applicazione (fornitrice del servizio) gestisce gli accessi e le autorizzazioni ai
propri servizi in modo autonomo
• centralizzazione degli accessi e delle autorizzazioni
4
Nella prima situazione ad ogni applicazione che gestisce un servizio compete inoltre
tutto il sistema di management degli accessi e delle identità.
Figura 2.1:
Sistema di gestione degli accessi e delle autorizzazioni lasciato alle
applicazioni
Ad ogni credenziale corrisponde un insieme di permessi che l’utente possiede o meno
all’interno dei vari servizi. In questo caso l’utente ha credenziali diverse per applicazioni
diverse pur rivestendo lo stesso ruolo e diverse per la stessa applicazione se riveste più
ruoli contemporaneamente.
Le problematiche più evidenti che nascono da una soluzione di questo tipo sono:
• la difficile gestione delle password
• la frammentazione delle credenziali aumenta la possibilità di rischio di permessi
concessi erroneamente
• maggior insicurezza delle credenziali e quindi maggior vulnerabilità delle applicazioni
• maggior difficoltà nell’aggiungere nuovi servizi o modificare privilegi che possono
avere dei ruoli
5
Questo schema è stato sostituito successivamente dall’implementazione del sistema
in cui ogni utente ha un identificativo personale ed il sistema conosce, tramite il supporto
di una apposita base di dati, la mappa dei ruoli ricoperti da ciascun utente.
Questa soluzione razionalizza e gestisce le procedure di autenticazione e autorizzazione tra un utente e i servizi forniti dalla sua organizzazione; in questo ambiente,
la funzione di attribuzione dei permessi dell’applicazione viene sviluppata prendendo a
riferimento la base dei dati dei ruoli: nel momento in cui l’utente si collega e si autentica vengono estrapolati i ruoli registrati per il suo identificativo; questi ruoli vengono
utilizzati per filtrare gli accessi oppure, per ciascun ruolo, vengono assegnati un insieme
di privilegi che, uniti, garantiscono l’accesso alle singole caratteristiche.
Quindi il tutto diviene centralizzato in un unico sistema (indicativamente composto da
un unico Database e da un sistema LDAP) detto sistema IAM (o server IAM), al
quale le applicazioni si interfacciano in modo trasparente, e che quindi gestisce gli accessi, le autorizzazioni al sistema e in modo ottimale le gestione delle Identità.
Questo sistema IAM gestisce indubbiamente anche l’Identità (come vedremo in seguito),
e tale gestione diviene nettamente semplificata da parte del sistema, garantendo inoltre
benefici che dalla precedente situazione non emergono.
Figura 2.2: Sistema di gestione degli accessi e delle autorizzazioni centralizzato
6
Quindi quali sono i passi, in generale, da compiere per giungere a una situazione di
questo tipo?
1
• analizzare i Database (ovvero le varie fonti da cui provendono i dati) esistenti e
vedere quali sono autoritativi
• decidere quali informazioni prendere, mantenere ed eventualmente aggiungere
• consolidare (una persona può essere presente in più fonti) per creare quella che
chiamiamo identità digitale
2
• tenere aggiornato automaticamente il database unificato
Si tratta quindi di centralizzare (dove necessario) le fonti in modo tale da creare
quelle identità (e quindi i loro privilegi) che dovranno accedere ai servizi offerti.
I benefici ottenuti dal sistema dopo il consolidamento dell’identità sono molteplici:
• i decision makers possono attivare cambiamenti più velocemente (per esempio aggiungere un nuovo servizio, oppure modificare i privilegi di accesso ad un gruppo
di servizi)
• l’evoluzione dei requisiti si riflette nei cambiamenti che devono essere fatti solo in
un posto: il sistema IAM (e non più in tutti i servizi offerti)
• secondo EduCause
3
i costi di implementazione di nuovi servizi 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 è 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
• eliminato il problema del Deprovisioning (disattivazione) relativo alla gestione delle
identità in sistemi disgiunti
• ridotto il numero di credenziali da conoscere da parte dell’ utente
1
Per maggiori dettagli consultare [5]
Questo è un passo cruciale dell’Identity Management
3
Consultare per maggiori informazioni http://www.educause.edu
2
7
• l’organizzazione può modificare più velocemente i diritti di accesso basandosi sui
ruoli
• nel processo di garantire che una persona è “quello che dice di essere” l’istituzione
incrementa il suo livello di riservatezza
Il progetto, di cui questa tesi è come detto in precedenza lo studio di una parte,
riguarda l’Università di Parma che è proprio una situazione in cui il problema della
gestione dell’autenticazione e degli accessi è ancora lasciata (in maggior parte) alle varie
applicazioni che gestiscono i servizi offerti.
Inoltre la gestione dell’Identità, allo stato attuale, ha molti difetti ed è ben lontana dalla
situazione ideale con l’implementazione di un server IAM.
8
2.2
Identità e ciclo di vita delle Identità
L’Identity Management è quel processo, parte costituente dell’Identity and Access Management, che si occupa dello studio e della gestione dell’ Identità e soprattutto del ciclo
di vita dell’ Identità. In questi paragrafi analizzerò questi aspetti cruciali.
2.2.1
Identità
Per Identità si intende l’entità unica che accede al sistema e che deve essere riconosciuta
e alla quale possono essere associati diversi ruoli; quindi è l’insieme delle informazioni
che caratterizzano un utente ovvero quelle informazioni relative alla identità e ai diversi
ruoli e/o attributi che questo può avere.
Riassumendo un identità consiste in:
• attributi, ovvero le informazioni specifiche di ogni utente distinguibili in:
– attributi anagrafici (ad es. cognome, nome, data di nascita...) necessari per
una corretta identificazione dell’utente
– attributi riguardanti il ruolo (o i ruoli ricoperti) all’interno del sistema (ad
es. per gli studenti potrebbe interessare il corso di laurea, per i docenti il
dipartimento di afferenza)
– attributi necessari per l’accesso alle risorse (ad es. username e password) detti
anche credenziali
• ruoli, ovvero funzioni che gli utenti ricoprono nel sistema (ad es. studenti, docenti
e incarichi dinamici4 ) ai quali derivano dei privilegi
5
Come si può facilmente intuire gli elementi costitutivi di un identità sono profondamente legati tra di loro: avere dei ruoli all’interno di un sistema comporta inevitabilmente
privilegi specifici nell’accesso alle risorse e quindi attributi specifici necessari per i ruoli
ricoperti.
Tornando alla definizione data in precedenza di identità ha un certo rilievo il termine
unica, che sta a significare che una persona non può essere presente nel sistema se non
solo sotto forma di una sola identità.
4
Per quel che riguarda una situzione universitaria quando ad esempio si creano dei gruppi di lavoro
legati ad un progetto
5
Ovvero le possibilità di accedere alle risorse che il sistema mette a disposizione (ad es. la possibilità
di aggiungere nuovi corsi da parte di un docente oppure di iscriversi a esami da parte degli studenti)
9
Figura 2.3: Identità: attributi, ruoli e privilegi
La non univocità comporterebbe da parte dell’utente più account (quindi più credenziali) ma soprattutto da parte del sistema comporterebbe una disastrosa gestione delle
informazioni riguardanti gli utenti in termini soprattutto di coerenza dei dati (ad es.
le modifiche apportate ad una identità dovrebbero essere propagate a tutte le altre di
quell’utente).
Diviene quindi fondamentale trovare un gruppo di attributi che da soli possano identificare senza ambiguità ogni identità, in modo da potersi riferire a tale identità sempre
attraverso tali attributi detti chiave.
2.2.2
Ciclo di vita delle Identità
Un identità una volta entrata nel sistema non rimane immutata per sempre, ma può, ed
in un sistema come quello universitario molto rapidamente, subire dei cambiamenti;
Difatti le operazioni che si possono fare sono:
• creazione di nuovi utenti (assegnazione credenziali)
• modifiche delle credenziali (quello cioè che serve all’utente per autenticarsi all’interno del sistema)
10
Figura 2.4: Ciclo di vita dell’identità
• modifiche degli attributi a causa di promozioni, trasferimenti o in generale cambio
di ruolo
• cancellazione account
• deve essere fornito un servizio di recupero password smarrita
Tutte queste operazioni sono un nodo cruciale dello IAM, e in particolar modo del
Identity LifeCycle Management.
Quindi la gestione del ciclo di vita delle identità comprende i processi e le tecnologie che consentono l’implementazione, l’annullamento dell’implementazione, la gestione
e la sincronizzazione di identità digitali e conformi ai criteri governativi. La riuscita della
gestione di identità e accessi si basa soprattutto sull’efficienza della gestione del ciclo di
vita delle identità digitali [6].
I servizi di gestione del ciclo di vita delle identità consentono la creazione di identità di
protezione, la gestione degli attributi, la sincronizzazione, l’aggregazione e l’eliminazione.
11
Inoltre, tali azioni devono essere eseguite in modo protetto con un itinerario di controllo
completo.
Esistono tre prospettive dalle quali possiamo analizzare il processo di gestione dell’
Identità[9]:
• paradigma rivolto all’Identità (The pure identity paradigm): creazione, gestione e
cancellazione delle identità senza considerare gli accessi alle risorse
• paradigma rivolto all’accesso alle risorse (The user access paradigm): ad esempio
una smart card usata da un utente per accedere a dei servizi
• paradigma rivolto alle risorse (The service paradigm)
The pure identity paradigm
Un modello generale di Identità può essere costruito da un ridotto insieme di principi
assiomatici; ad esempio tutte le identità in una data situazione sono uniche e distinguibili.
Un modello assiomatico di questo tipo può essere considerato come identità pura, nel
senso che tale modello non è vincolato dal contesto nel quale è applicato. Un pure identity
model non è strettamente legato con la semantica degli attributi delle identità e l’Identity
management può essere definito come un insieme di operazioni su un modello astratto
dell’Identità. In pratica, identity management è usato per esprimere come l’informazione
dell’identità deve essere arricchita e riconciliata tra diversi modelli.
The user access paradigm
L’Identity management in questo paradigma può integrarsi in un sistema di processi
business, politiche e tecnologie che facilitano l’organizzazione a controllare gli accessi
alle risorse. Rappresenta una categoria di soluzioni nelle quali gli amministratori di
sistema si impiegano verso la gestione dell’autenticazione degli utenti, diritti di accesso
e le restrizioni, i profili delgli account, le passwords, e tutti gli altri attributi riguardanti
i ruoli in relazione alle applicazioni (ovvero ai privilegi).
The service paradigm
In questo paradigma, nel quale le organizzazioni evolvono i loro sistemi nel mondo di
servizi convergenti, l’ambito dell’ identity management diviene più ampio e la sua applicazione nettamente più critica. Difatti include tutte le risorse della organizzazione
utilizzate per fornire servizi online. Perciò può includere apparati, strumenti di rete,
server, applicazioni varie.
12
2.3
Implementare un server IAM
Nel paragrafo 2.1 si è parlato di server IAM in linea teorica, descrivendo cos’è e a
cosa serve, vediamo ora e com’è possibile implementarlo realmente e attraverso quali
strumenti software.
Ricordandoci che un server IAM è un sistema che permette di gestire le identità degli
utenti in un unico punto centralizzato, ed al quale si rivolgono le risorse e i servizi (offerti
dal sistema) che fanno uso di queste informazioni, ad esempio per gestire autenticazione
e autorizzazione.
Quali sono, in sintesi, le caratteristiche che deve avere un server IAM?
• deve memorizzare e mantenere grandi quantità di informazioni
• deve essere affidabile, ovvero deve garantire che, anche in caso di malfunzionamenti, guasti o incidenti, non vengano perse le informazioni memorizzate
• deve risulare sicuro, quindi deve avere una serie di meccanismi per assicurare che
non possa essere compromesso e che i dati mantenuti non possano essere acceduti
da persone non autorizzate
• deve essere indubbiamente performante nelle operazioni di lettura, poiché costituiscono la maggior parte di operazioni che verrano 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
Esistono principalmente due strumenti che possiedono le precedenti caratteristiche:
LDAP oppure i DBMS. Nei successivi paragrafi vengono descritti entrambi e, come
si vedrà, sarà possibile utilizzarli singolarmente per implementare un server IAM, ma
una buona soluzione, come si potrà vedere nel progetto può essere quella di utilizzarli
entrambi, in modo congiunto, per sfruttarne al meglio le caratteristiche.
2.3.1
LDAP
LDAP (Lightweight Directory Access Protocol) è sostanzialmente un protocollo di gestione e accesso a directory service. Un directory service (servizio di directory) è utilizzato
per associare nomi ad oggetti, dove ogni oggetto è caratterizzato da una serie di attributi
costituiti da una coppia nome - insieme di valori.
13
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 conterrà una serie di attributi che servono per descrivere ciò che
rappresenta (per quello visto in precedenza un Identità nel nostro caso). Una directory
è quindi un insieme di oggetti, e un directory service è un servizio che ha lo scopo di
gestire gli oggetti di una directory ed effettuare ricerche su di essi.
LDAP è strutturato attraverso uno schema costituito inoltre da attributi caratterizzanti
il contenuto degli oggetti.
Perché LDAP
LDAP è un’ottima soluzione, ha notevoli vantaggi, è sempre più diffuso e stà 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 più diffuse implementazioni libere
sono Fedora Directory Server, OpenDS, Apache DS e OpenLDAP.
2.3.2
Database e DBMS
Database e DBMS: cosa sono e a cosa servono
In informatica, il termine database, banca dati o base di dati, indica un archivio, 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; in altre parole l’insieme organizzato di dati utilizzati per il supporto allo svolgimento di attività [1].
Informalmente e impropriamente, la parola database viene spesso usata come abbreviazione di Database Management System (DBMS), che si riferisce invece a
una vasta categoria di sistemi software che consentono la creazione e la manipolazione
efficiente di database.
Esiste una sottile, ma da non sottovalutare, differenza tra dati ed informazioni in
informatica:
i dati sono materiale informativo grezzo, non (ancora) elaborato, e memorizzato in un
qualche modo;
14
al contrario l’informazione viene costruita dai dati elaborati cognitivamente cioè trasformati in un qualche schema concettuale successivamente manipolabile e usabile per altri
usi cognitivi [3].
L’importanza che i dati (e quindi le informazioni) vengano gestiti nel modo più corretto, efficace ed efficente possibile è ovviamente fondamentale per una qualunque società,
o in particolar modo per un’ Università: essi rappresentano il passato (mantenendo uno
storico), il presente (la gestione attuale dei processi business si basa sulla corretta gestione delle informazioni) ed ovviamente il futuro (le scelte future dipendono anche dalla
situazione attuale e passata).
Panoramica tra i vari DBMS
In questo paragrafo verrà proposta una carrellata tra quali siano oggi i DBMS presenti
sul mercato al fine di scegliere quello più adatto al progetto.
Questa non vuole essere una lista esaustiva e neppure un confronto completo tra le varie
proposte ma una giusta premessa a quella che sarà la scelta finale [2].
Tutti i DBMS di cui parleremo sono di tipo relazionale 6 . Ne esistono di tre categorie:
• sistemi chiusi o proprietari
• sistemi semi-aperti
• sistemi aperti
Di queste categorie rispettivamente verrano prese in analisi i più importanti ovvero:
• Oracle
• MySQL
• PostGreSQL
Licenze d’uso
Oracle propone al cliente una gamma di soluzioni molto ricca alla quale il cliente dovrà
quindi scegliere tra le molte licenze a disposizione. Esistono tre categorie di licenze che
Oracle offre:
6
Basato cioè sul concetto matematico di relazione
15
• Modalità d’uso: in questa categoria sono raccolte le licenze che limitano l’uso che
l’utente può fare del software Oracle. Ci sono tre sotto-categorie:
– le licenze Full Use permettono all’utente finale di utilizzare il software per
qualsiasi tipo di applicazione
– la licenza ASFU (Application Specific Full Use) consente un utilizzo limitato
destinato ad un Partner Oracle per una singola e specifica Applicazione allo
scopo di rivendita ad un utente finale determinato. Permette all’utente di
utilizzare il software solo congiuntamente all’applicazione con cui e’ stato
venduto
– le licenze Embedded (ESL) consentono un utilizzo limitato destinate ad un
Partner Oracle Solution Provider per la vendita di una soluzione in cui il software Oracle e’ appunto Embedded, ovvero inserito all’interno nel pacchetto
applicativo fornito dal Partner
• Tipologia: in questa categoria sono raccolte le licenze che si basano sul sistema
dell’utente finale.
– la licenza Named User Plus viene utilizzata negli ambienti dove il numero di
utenti può essere identificato e contato
– la licenza Processor è una licenza che si applica su ogni singolo processore
attuo a processare il software Oracle
• Scadenza della licenza: in questa categoria sono raccolte le licenze che pongono
limiti sul tempo di utilizzo del software. Ci sono tre sotto-categorie: A tempo
determinato, indeterminato e a tempo esteso.
MySQL invece dispone di una doppia licenza. Affiancata alla GPL troviamo infatti
la MySQL Commercial License.
Questa permette di rilasciare le proprie modifiche con la licenza che si preferisce, senza
alcun vincolo. Quindi il problema della doppia licenza coinvolge solamente chi scrive un
software che si basa su MySQL.
PostGreSQL è rilasciato con la BSD License la quale è considerata una delle licenze
più permissive.
Costi
Riguardo ai costi dei servizi di Oracle, nel seguito riporteremo alcuni esempi (in dollari
americani).
16
• Oracle Database Standard Edition 15 mila dollari
• Oracle Database Enterprise Edition 40 mila dollari
• Suite Enterprise Edition 225 mila dollari
Molte delle opzioni offerte da Oracle però richiedono un ulteriore spesa compresa tra
i 3000 dollari e i 25000 dollari. Tutti questi prezzi sono relativi alla licenza Processor
and Perpetual, questo significa che andranno applicati ad ogni singolo processore per una
durata di tempo illimitata. In caso si voglia installare questi software su più macchine
dunque sarà necessario pagare ripetutamente queste somme per ogni singolo processore.
Nel 2005 Oracle ha rilasciato una versione gratuita chiamata Oracle Database 10g
XE (Express Edition). XE, che si basa sul codice di Oracle Database 10g Release
2, consente a chiunque di provare a costo zero tutte le funzionalità presenti in Oracle
Database 10g. La versione light di Oracle offre infatti gli stessi strumenti del fratello
maggiore, dando la possibilità agli utenti di sviluppare applicazioni in ambiente Java,
.NET e PHP, quindi particolarmente adatta allo svuluppo di applicativi WEB.
Oracle XE utilizza al massimo 1 GB di memoria, gestisce una base di dati con una
dimensione massima di 4 GB e permette l’esecuzione di una sola istanza per sistema,
gira sui sistemi operativi Windows e su una gran varietà di distribuzioni Linux.
Ovviamente ne’ MySQL ne’ PostgreSQL presentano costi di licenze.
Sicurezza
Una delle problematiche maggiori dei software rilasciati senza sorgente, proprio come lo
è Oracle, è proprio la sicurezza. Solo chi ha il sorgente può modificare il software al fine
di risolvere eventuali bug.
Nel caso di Oracle, si è definito un record di inefficienza quando furono segnalati bug
critici da Alexander Kornbrust, CEO della tedesca Red-Database-Security Gmbh e solo dopo 650 giorni furono risolti e rilasciate le patch. Dalla Next Generation Security
Software Ltd (Ngs), David Litchfield, uno dei bug hunter più prolifici nel campo dei
database, ha dimostrato inoltre la non piena efficienza delle patch rilasciate da Oracle.
Molti analisti hanno evidenziato come Oracle tenti di migliorare la sicurezza dei propri
prodotti insistendo sulla via del security through obscurity ad oltranza, anche nei confronti dei propri clienti, senza disporre però di un piano di fondo per rendere i propri
prodotti intrinsecamente sicuri.
17
Al contrario MySQL essendo un sistema aperto, e parzialmente libero, sfrutta la possibilità di analisi e rilascio di patch sia dalla community che segue lo sviluppo del codice
sorgente del database sia dagli sviluppatori ufficiali. È garantita in questo modo un’
elevata disponibilità al rilascio di patch e questo contribuisce sicuramente ad un incremento totale della sicurezza del DBMS.
A maggior ragione PostgreSQL essendo in continuo sviluppo da parte della ricerca
universitaria di tutto il pianeta ha sicuramente dalla sua un gruppo di sviluppatori che
si occupano di migliorare continuamente la sicurezza ed efficenza del DBMS.
18
Capitolo 3
Vincoli progettuali
In questo capitolo si prenderanno in analisi tutti quei vincoli che sono stati da contorno
fondamentale per la progettazione dell’architettura;
tali vincoli possono essere divisi in:
• il contesto in cui andrà a collocarsi il progetto
• l’attuale gestione dell’Identità, e di conseguenza le problematiche di tale situazione
(ovvero la parte da modificare nel progetto)
• vincoli riguardanti la sicurezza, la coerenza e l’affidabilità dei dati
3.1
Il contesto
Vediamo, in questo paragrafo, il contesto nell’università di Parma in cui il progetto del
sistema IAM centralizzato viene applicato, cioè quelle parti che non vengono modificate
dal progetto, ma alle quale esso si riferisce.
In particolare vengono illustrate le fonti, ovvero da dove provengono le informazioni
relative agli utenti e la gestione del ciclo di vita dell’Identità.
3.1.1
Fonti: situazione attuale
La situazione delle fonti dati attualmente è ben lontana dall’ essere una situazione con
un unica fonte dati centralizzata.
Difatti la gestione quotidiana di una struttura come può essere l’Università di Parma si
diversifica in alcuni settori, gestiti da diverse segreterie e in conseguenza diverse fonte
dati.
19
Figura 3.1: Situazione attuale all’Università di Parma
Tali settori sono:
• gestione personale, ovvero:
– professori ordinari
– professori associati
– ricercatori Universitari
– dirigenti
– dirigenti a contratto
– non docenti
– collaboratori linguistici
20
– personale esterno
• gestione professori a contratto e supplenti
• gestione borsisti e specializandi
• gestione future matricole e ditte esterne (fornitrici di tirocini o opportunità di
lavoro)
• gestione studenti (inclusi master e dottorandi)
• gestione degli studenti esteri (erasmus)
Le fonti dati presenti per la gestione del personale sono due:
• U-GOV (presso le varie presidenze di facoltà) che gestisce i professori a contratto
e supplenti
• U-GOV Anagrafica che contiene tutti i dati del personale
Inoltre sono presenti ulteriori due fonti dati per la gestione degli studenti:
• WebGISS per le future matricole, le ditte esterne e gli studenti esteri
• GISS per gli studenti (segreteria studenti), master e specializzandi (dal settore
post-laurea) e dottorandi (dal serivizio borse e dottorandi)
A questi vanno aggiunti le informazioni dei dipendenti ospedalieri che hanno accesso
a servizi dell’Università.
Da tutte queste diversificate fonti, attraverso vari sistemi (invio di files DBF o txt) e
procedure (php e perl principalmente), si inviano i dati ai Database e quindi al sistema
LDAP (presenti presso il SITI) che permettono l’accesso diversificato ai vari utenti che
fanno richiesta dei serivizi. Non è presente nessun tipo di controllo sulle identità, quindi
una persona potrebbe essere tranquillamente presente in più fonti e di conseguenza più
volte nei Database e nel sistema.
21
3.1.2
Identità: situazione attuale
Ruoli: privilegi diversi per le identità
All’interno di una qualunque situazione la diversificazione dei ruoli implica necessariamente la divisione dei doveri e dei diritti.
In un ambiente Universitario, e nel caso specifico del sistema informativo e dei servizi
che esso offre, questo di traduce in diversi privilegi che ogni ruolo possiede.
Basti pensare per esempio cosa succederebbe se chiunque possa avere accesso (anche
in scrittura) a fonti dati riguardanti i corsi di laurea o ancora peggio la gestione degli
stipendi del personale.
Distinguere e formalizzare il più possibile i ruoli che avranno accesso al sistema aiuta
quindi il compito di poterli gestire nel migliore dei modi.
Abbiamo perciò ruoli diversi:
• studenti: persone iscritte ad uno dei corsi che l’Ateneo organizza per il conseguimento di un titolo
• future matricole (coloro che ad esempio non sono riusciti ad entrare in corsi a
numero chiuso)
• personale strutturato (docenti e i non docenti a tempo indeterminato)
• ditte esterne (fornitrici di tirocini)
• professori a contratto
• tutor aziendali
• studenti esterni all’Università (ad esempio studenti Erasmus)
Quelli elencati sono (a grandi linee) i ruoli presenti. L’elenco non è del tutto esaustivo
perché non comprende (almeno in modo diretto) tutti quei casi misti ovvero di persone
che ricoprono contemporaneamente più ruoli (ad esempio il caso più semplice di studenti
che svolgono anche dei servizi didattici).
Ciclo di vita dell’Identità: situazione attuale
Vediamo ora come viene gestito allo stato attuale il ciclo di vita dell’ Identità, per
ogni ruolo:
• studenti:
22
– creazione credenziali: la creazione delle credenziali avviene una volta che lo
studente ha pagato la prima rata delle tasse e contestualmente all’inserimento
dei dati in GISS.
Successivamente una procedura batch estrae i dati dal database GISS e li
inserisce in un file di testo di tipo CSV in cui sono contenuti tutti i dati
necessari alla gestione dei servizi. Alcune procedure bash+perl in automatico
generano il file ldif per popolare il server master LDAP
– modifica credenziali: gli studenti possono modificare autonomamente la password attraverso una pagina web protetta da SSL
– modifica attributi: ogni sera, oltre al file contenente i dati dei nuovi iscritti,
viene inviato anche un file contenente i dati modificati degli studenti già
iscritti. Gli attributi sono modificati utilizzando delle procedure bash+perl
simili a quelle usate per la creazione
– cancellazione: la cessazione della casella di posta elettronica, due anni dopo
l’ultima iscrizione, non comporta la cancellazione dal server LDAP, ma solo
lo spostamento ad un altro ramo
• personale strutturato:
– creazione credenziali: o dati anagrafici sono inviati al Settore Innovazione Tecnologie Informatiche dove sono generati gli indirizzi email seguendo il modello
[email protected]
– modifica credenziali: gli utenti possono modificare autonomamente la password attraverso una pagina web protetta da SSL. Le password scadono ogni
180 giorni. Se l’utente dimentica la password o lascia passare 200 giorni
dall’ultimo cambio, il sistema non permette più di accedere ai servizi e l’utente deve rivolgersi al Servizio Supporto al Settore Innovazione Tecnologie
Informatiche
– modifica attributi: tutti i mesi sono inviate le informazioni relative ai dipendenti attivi. Per differenza con l’elenco del mese precedente, tramite procedure analoghe a quelle usate per la generazione degli account, il Settore Innovazione Tecnologie Informatiche modifica le informazioni relative a eventuali
trasferimenti, promozioni, riassunzioni, ecc.
– cancellazione: per il momento non viene mai effettuata la cancellazione dell’account del personale strutturato ma viene solo registrata la cessazione
modificando alcuni valore di attributi
23
• ditte esterne: per il momento non esiste la necessità di rilasciare delle credenziali
a tutti i fornitori esterni in quanto tali.
• professori a contratto : per il momento, sono trattati come gli strutturati, ma il
trasferimento dei loro dati al Settore Innovazione Tecnologie Informatiche avviene
con evidente ritardo rispetto sia all’inizio del contratto sia, soprattutto, all’inizio
delle attività didattiche (questo evidentemente è un limite di tale gestione del ciclo
di vita)
• studenti esterni e future matricole : la gestione del loro ciclo di vita è tuttora
abbastanza lontana da essere una situazione ideale (ovviamente con una situazione
più razionale anche la loro gestione non sarà più problematica)
3.1.3
Risorse disponibili agli utenti
Le risorse informatiche disponibili all’interno dell’università che utilizzano sistemi di
autenticazione e autorizzazione si possono suddividere in servizi web, servizi di rete
e postazioni computer. Per motivi di completezza (e ovviamente per dare idea della
loro dimensione e importanza per utenti e per il sistema)vengono elencate le principali
risorse dell’università di Parma:
Un elenco dei servizi web offerti è nella tabella 3.1.
I servizi di rete sono:
• Wi-Fi
• VPN
Infine, le postazioni coumputer si possono dividere in base al sistema operativo:
• Windows
• Linux.
24
Nome
Scopo
Dove e/o chi
Goal
Gestione aule
Fac. Ingegneria
Iscrizionet
Iscrizione agli esami
Fac.
Agraria, Economia,
Farmacia,
Giurisprudenza,
Ingegneria,
Lettere
e
Filosofia,
Medicina Veterinaria,
Scienze
Politiche
Yagiss
Comunicazione
scelta
WebGISS
Servizi diversi alla didattica:
esenzione maggiorazione, ecc. (interfaccia al
sistema informativo GISS)
Studenti iscritti e docenti
dell’Ateneo
CSAWeb
Cedolini stipendiali
Personale strutturato dell’Ateneo
Er-GO
Domande di benefici per il
diritto allo studio
Studenti iscritti dell’Ateneo
Campusnet
Servizi diversi per la didattica
Fac. Medicina e Chirurgia,
Scienze MM.FF.NN.
Dspace
Deposito delle tesi di dottorato
Dottorandi dell’Ateneo
Dokeos o Moodle
Sistemi di supporto alla
didattica frontale
Corsi dell’Ateneo, sia per
studenti interni che esterni
Varie applicazioni
interne
Form per il Nucleo di Valutazione; catalogo delle Pubblicazioni; ecc.
esami
a
Fac. Ingegneria
Tabella 3.1: Elenco dei servizi web dell’università.
3.2
Attuale gestione delle identità e degli accessi
Dopo aver illustrato il contesto, vediamo come vengono gestiti attualmente gli utenti.
La struttura generale è composta da un server LDAP in cui vengono replicate le informazioni degli utenti mantenute nei diversi database.
I database servono quindi per mantenere i dati degli utenti che vengono prelevati dalle
fonti (come descritto nel paragrafo 3.1.1), mentre il server LDAP è utilizzato per rendere
disponibili questi dati alle applicazioni.
25
3.2.1
Database
Nella figura 3.1 viene illustrato come le informazioni provenienti dalle fonti vengono
inserite nei database attraverso vari sistemi, come l’invio di files DBF o txt, e procedure
php e perl.
I database mantenuti sono due: uno per gli studenti ed uno per il personale, il che è
chiaramente contro la logica di mantenere un’identità unica per ogni utente, basti infatti
pensare ad uno studente che diventa docente: in questo caso vengono creati due utenti
distinti, uno nel database degli studenti ed uno nel database del personale.
L’obiettivo del progetto è esattamente quello di evitare situazioni di questo genere e
creare una identità digitale unica per ogni persona.
3.2.2
Problematiche della gestione attuale
Mantenere più database distinti comporta diversi problemi se vogliamo costruire un
sistema dove gestire un’unica identità per ogni persona; difatti, se una persona ricopre più
ruoli, come può essere per un docente-studente, vengono mantenuti due utenti separati
per una stessa persona, rendendo impossibile realizzare l’obiettivo dell’identità digitale
unica.
Lo sdoppiarsi possibile delle Identità implica una duplicazione della gestione del ciclo di
vita (ogni modifica andrebbe gestita due volte, sempre se si fosse a conoscenza di tale
situazione, altrimenti si ci ritroverebbe in una situazione di incoerenza).
Questo problema lo si risolverà progettando un database unico nel quale memorizzare
e mantenere le informazioni degli utenti e le informazioni relative a tutti i ruoli da essi
ricoperti.
26
3.3
Sicurezza, coerenza e affidabilità
Quando si parla di progetti informatici riguardanti il trattamento di dati importanti,
come nel caso del nostro progetto, non si possono e non si devono per alcun motivo
tralasciare l’analisi dettagliata delle problematiche riguardanti la sicurezza dei dati.
La sicurezza dell’Identità, e di conseguenza delle sue caratteristiche (attributi, privilegi...), è di vitale importanza per una struttura con molti utenti come lo è l’Università
di Parma; come abbiamo visto l’identità digitale si viene a costituire nel server IAM,
e in particolar modo (come vedremo nel capitolo successivo), nel Database.
Verranno perciò messi a fuoco quali sono i problemi relativi alla sicurezza nelle Basi di
Dati.
Le minacce ai Database si possono dividere in tre categorie:
• perdita di integrità: se vengono cioè apportate modifiche non autorizzate al Database
• perdita di disponibilità: se non sono disponibili (ai servizi o agli utenti) i dati
• perdita di riservatezza: se viene a meno la protezione dei dati
Queste minacce possono essere causate da attacchi:
• a livello fisico: furti, danni
• a livello logico (di intercettazione, di deduzione, di intrusione, di disturbo)
• disastri naturali o accidentali
• errori o bug software/hardware
• errori umani
Vediamo più in dettaglio quali possono essere le soluzioni a questi delicati problemi:
• ridondanza: replicare i dati in luoghi (o supporti) diversi
• controllo degli accessi (permettere solo alle persone autorizzate di accedere ai dati
dando privilegi diversi)
• politiche di prevenzione
27
Con ridondanza intendiamo la replica dell’intero Database su supporti diversi (server ubicati in luoghi differenti ad esempio) in modo da evitare danni irreparabili in caso
di guasti, furti al Database originale.
La replica comporta però problematiche di coerenza dei dati: non è ammissibile che nelle
repliche esistano dati non aggiornati; ciò comporta la realizzazione di politiche di aggiornamento (ad esempio da effettuarsi durante la notte) tra il database master e le copie.
Ciò può avvenire banalmente con un passaggio (ovviamente attraverso canali sicuri) di
script SQL (il linuguaggio dei Database) riguardanti le modifiche del giorno passato.
Per evitare ulteriori problemi conviene mettere in atto delle politiche di prevenzione,
ovvero di implementare delle procedure volte a salvaguardare i dati [8]:
• politiche di log: si deve tener traccia delle modifiche fatte al Database in modo da
poter ricostruire i cambiamenti in caso di guasti
• politiche di backup: salvare il contenuto del Database (o di un sottoinsieme) su
supporti diversificati riduce il richio di perdita dei dati
Un altro aspetto fondamentale della sicurezza dei dati riguarda la gestione delle operazioni sul Database; immaginiamo che durante una scrittura sul database ci sia un
guasto alla rete. Cosa può succedere nel Database? Le modifiche sono state apportate
tutte o solo una parte?
Se fosse cosı̀ ci troveremmo di fronte ad uno stato non coerente perchè non rappresenterebbe la realtà: diventa quindi fondamentale l’uso (da parte ad esempio dei servizi)
delle transazioni, ovvero di operazioni atomiche, che permettono perciò di passare da
uno stato coerente all’altro.
Le proprietà di cui godono le transazioni, le cosidette proprietà Acide, sono:
• Atomicità: è la proprietà del tutto o niente, ovvero o le modifiche sono apportate
per intero o non sono eseguite per niente
• Consistenza: l’esecuzione di una transazione preserva la consistenza del database
• Isolamento: ogni transazione è isolata dal resto del mondo e non deve essere
influenzata da altri cambiamenti di altre transazioni a lei concorrenti
• Durabilità: le modifiche apportate da una transazione rimangono anche dopo
danni al database
Garantire perciò che tutte le operazioni (che in altri termini gestiscono il ciclo di
vita) sul Database rispettino queste quattro proprietà, unito ad un insieme di politiche
28
di sicurezza preventiva (backup e logging), la maggior sicurezza data da delle copie
aggiornate (ridondanza) e un controllo sicuro degli accessi garantisce che la Base di dati
è sicura, o comunque preparata nel migliore dei modi a danni accidentali o meno.
29
Capitolo 4
Progetto
In questo capitolo si entrerà nel merito del progetto, analizzando le scelte architetturali
(prima da un punto di vista più astratto) e concentrando l’attenzione in seguito sulle
scelte inerenti l’Identità (Database, ciclo di vita, sicurezza nel trattamento dei dati).
Ipotizzando che la gestione degli accessi sia già implementata (quindi anche lo schema
dell’LDAP) resterà soltanto da analizzare quali siano gli attributi da replicare sull’LDAP.
30
4.1
Progetto logico
Il progetto, del quale entreremo in dettaglio in questo capitolo, viene illustrato da un
punto di vista logico, o perlomeno più astratto, nella figura 4.1.
Figura 4.1: Progetto da un punto di vista più astratto
In termini logici possiamo quindi osservare come si ci prefigga di fare interagire la
gestione del ciclo di vita dell’identità con un server IAM.
Per quel che riguarda la creazione, le varie modifiche o la cancellazione riguardanti le
identità innanzitutto si verrà a contatto con le varie fonti (diversificate come ora per
ruoli 1 ) prima di interagire (attraverso opportuni strumenti di sincronizzazione) con il
server IAM.
Quando un utente vorrà accedere ad una risorsa, attraverso vari strumenti di autenticazione, vi potrà accedere solo dopo che tale risorsa abbia gestito nel modo migliore
l’accesso tramite il server IAM.
Nei paragrafi successivi vedremo come tale server IAM verrà implementato e quali siano
le problematiche conseguenti a tale scelta.
1
Non è pensabile di poter modificare le fonti poichè esse sono strettamente legate con le varie segreterie
di appartenenza
31
4.2
Architettura generale
Quindi gli obbiettivi del progetto sono di centralizzare le fonti dati e permettere cosı̀
l’interazione con un sistema LDAP in modo da centralizzare gli accessi ai servizi offerti
dall’Università e di poter gestire in maniera ottimale il ciclo di vita dell’Identità.
Le fonti dati scambieranno i dati in modo sicuro (come vedremo in seguito) con il DB
centralizzato il quale popolerà in parte il server LDAP, che attraverso sistemi di bilanciamento del carico e protocolli sicuri gestirà le richieste dei servizi in modo veloce e
sicuro.
32
Figura 4.2: Obbiettivi del progetto
33
4.3
4.3.1
Fonti
DBMS scelto
Senza soffermarci su discorsi di performance ma cercando solamente dei test effettuati
tra le ultime versioni di MySQL, PostgreSQL e Oracle XE si nota subito una differenza
di tempi di risposta tra MySQL e PostgreSQL (tempi eccellenti) e Oracle. MySQL e
PostgreSQL, al contrario di Oracole XE, non usano un server web che comunica con un
server database, ma si basa su un programma compilato, quindi molto più veloce.
Scartando perciò l’ipotesi Oracle restano due prodotti snelli, leggeri, flessibili, altamente
configurabili.
La scelta per il DBMS del progetto cade su MySQL, poichè vince la sfida con PostgreSQL
per la maturità del prodotto (incrementata dalla recente aquisizione di una ditta come la
Sun) e soprattutto la maggiore facilità di utilizzo dovuta a strumenti di gestione, molto
comodi per gli sviluppatori web, come phpmyadmin.
Altri motivi sono i costi (nessuno per le licenze) e l’amplio utilizzo che se ne fa sia presso
il centro di calcolo sia in tutta l’Università.
4.3.2
Database unificato
L’obbiettivo quindi è quello di avere un unico DB locale presso il SITI che raccolga (in
un primo momento) e mantenga costantemente aggiornate le infomazioni presenti in:
• U-GOV
• GISS
• WebGISS
• Dati dipendenti AOU e AUSL
Esso dovrà tenere traccia dei dati anagrafici degli utenti e dei ruoli assunti all’interno
dell’Università, in modo da poter diversificare efficacemente e in modo centralizzato i
privilegi per accedere ai servizi offerti. Elenchiamo più in dettaglio i requisiti richiesti al
Database unificato2 :
• Per ogni Identità si deve tenere traccia di:
– Cognome
2
Tali requisiti vengono imposti sia per motivi di anagrafica che per motivi di gestione ottimale degli
accessi ai servizi
34
– Nome
– Sesso
– Codice Fiscale
– Data nascita
– Via e CAP di residenza
– Via e CAP di domicilio
– Mail personale
– Telefoni
– Fax
– Titolo onorifico
– Nazione di residenza, cittadinanza e domicilio
– Luogo di residenza, cittadinanza e domicilio
– Ruolo ricoperto allı̀’interno dell’Università
– Dati LDAP
• Per ogni Stato si deve tenere traccia di:
– Nome
– Codice IANA
– Codice ISTAT
– Codice Agenzie delle Entrate
– Codice 2 lettere
– Codice 3 lettere
• Per ogni Luogo si deve tenere traccia di:
– Comune
– Provincia
– Descrizione
– Codice ISTAT
– Codice Agenzie delle Entrate
• Per ogni Ruolo ricoperto si deve tenere traccia di:
35
– 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
• In particolare per gli studenti della carriera interessa:
– Matricola
– Anno di ultimo pagamento delle tasse
– Anno di prima immatricolazione
– Anno della laurea triennale
– Anno della laurea specialistica
– Anno di prima immatricolazione
– Corso di laurea di appartenenza (e Facoltà di conseguenza)
• Dei dati ultili per il sistema LDAP (3 ) interessa:
– CN
– Mail assegnata
– UID
– UID Numeber
– SAMBA SID
– Password Iniziale
– Gli attributi della Object Class EduPerson
3
Sono necessari per i processi di autorizzazione e autenticazione
36
Una volta definiti tutti i vincoli del problema di può procedere alla realizzazione dello
schema relazionale (basato cioè su relazioni e associazioni [1]).
Si può quindi pensare di creare l’entità fondamentale Identità, contenente tutte le
informazioni anagrafiche, alla quale si associano i ruoli che conterranno informazioni
specifiche a seconda del ruolo ricoperto.
Lo schema relazionale del Database unificato con queste informazioni è rappresentato
nella figura successiva:
37
38
Il passo successivo è quello si passare dallo schema astratto alla struttura in tabelle
tipica dei Database.
Per fare questo è stato riportato il dump di tale progetto nell’appendice B.
4.3.3
La gestione delle figure esterne all’Università
Come detto in precedenza nel paragrafo 3.1.2, la gestione del ciclo di vita allo stato
attuale oltre ad essere poco efficace è anche incompleta perchè alcuni ruoli non vengono
proprio (o comunque in maniera non informatizzata) gestiti.
È necessario procedere all’identificazione (per la legge anti-terrorismo recentemente entrata in vigore), di tutte quelle figure (che richiedano credenziali di accesso ai servizi
offerti dal sistema), non presenti (come indicato nei paragrafi precedenti), nelle fonti del
sistempa;
queste figure sono:
• collaboratore coordinato continuato
• collaboratore di ricerca
• convenzionato
• cultore della materia
• dipendente di altra Università
• dipendente altro ente di ricerca
• dipendente di altra azienda sanitaria
• dottorando di altra Università
• fornitore (dipendente o titolare delle ditte fornitrici)
• interinale
• lavoratore occasionale (contratto personale senza partita IVA)
• libero professionista (contratto personale con partita IVA)
• ospite con accesso al servizio di VPN
39
• ospite
• studente di altra Università
• tutor
Presento come valida soluzione al problema degli account richiesti per tali figure,
la soluzione adottata dall’Università di Modena (adattata ovviamente al contesto di
Parma)[4].
La procedura è accessibile al solo personale incaricato per l’identificazione a norma del
D. Lgs. 196/2003.
È necessario almeno un incaricato per ogni struttura.
L’incarico è conferito dal responsabile del trattamento dati nelle rispettive strutture di
appartenenza.
L’accesso deve essere controllato tramite LDAP (autenticazione) e profilo di autorizzazione.
• la procedura è fornita mediante interfaccia web sicura in modo da essere accessibile
in modo distribuito senza onere di gestione della parte client
• la procedura deve acquisire i dati anagrafici, il documento di identità, gli estremi
dell’incarico e registrarli in un deposito dove tali dati siano facilmente reperibili
• i dati precedentemente acquisiti devono essere correlati con i dati provenienti dalle
fonti (GISS, WebGISS, ...) ed andare con essi a popolare il database LDAP
• la procedura prevede la popolazione di due tabelle: la tabella IDENTITÀ e la
tabella RUOLI. Per maggiori dettagli riguardo alle tabelle coinvolte si guardi il
progetto del Database Unificato
• alle persone a cui viene affidato almeno un incarico devono perciò essere date le
credenziali che permetteranno quindi l’accesso ai servizi d’ateneo mediante l’autenticazione LDAP e il profilo previsto dalle policy di ateneo
• la procedura deve permettere di sanare la situazione esistente relativa alle credenziali assegnate dal servizio di posta elettronica: molte delle credenziali assegnate
in passato non sono più da considerare valide perchè si è persa traccia dei relativi
richiedenti o referenti o perchè è mancato il controllo costante sulla validità dei
dati. Le credenziali da tenere vanno associate all’identificazione effettuata con la
nuova procedura
40
Ecco in dettaglio le operazioni a carico dell’operatore necessarie per una corretta
identificazione e per l’ottenimento delle credenziali:
1. procurarsi un documento valido e il tesserino del codice fiscale della persona da
identificare
2. preparare un foglio con la copia del documento di identità (fronte e retro) e del
tesserino del codice fiscale in un unica facciata (se possibile). In alternativa in una
facciata il fronte e retro del documento di identità e nell’altra il codice fiscale
3. inviare il foglio al SITI utilizzando la qualità pià alta possibile
4. collegarsi alla pagina della procedura di identificazione del personale esterno usando
le proprie credenziali di accesso UNIPR
5. se la persona possiede già le credenziali di accesso ai servizi informatici recuperare
il suo nominativo dalla Lista Attesa e andare al punto 6.
Se la persona non possiede ancora le credenziali di accesso ai servizi informatici
procedere con Nuovo Esterno
6. inserire il codice fiscale e procedere con Cerca i dati dell’utente in Anagrafica
7. completare i dati mancanti. nei campi Documento di Identità e Codice Fiscale
andare ad inserire il file corrispondente al FAX precedentemente inviato.
Il nome del file è composto da due parti: una prima parte costituita dal numero del
vostro numero di FAX; una seconda parte costituita dall’ora in cui avete inviato il
FAX.
I FAX inviati al FAX server rimangono in giacenza fino alla mezzanotte dopo di
che vengono automaticamente rimossi
8. procedere con Registra i Dati appena inseriti
9. controllare se i dati della persona sono corretti e procedere con Conferma inserimento di questi dati nel DB
10. a questo punto procedere con l’assegnazione dell’Incarico: una volta compilati i
campi procedere con Salva i dati del nuovo incarico
11. procedere stampando la pagina e consegnarla all’utente
Ovviamente la procedura, espressa precedentemente in modo dettagliato, potrà essere modificata a seconda delle esigenze, e come descritto richiede un sistema di creazione
credenziali web.
41
4.3.4
Sicurezza nel trattamento dei dati
La sicurezza del trattamento dei dati deve essere una caratteristica di un qualunque
sistema informativo, e a maggior ragione deve essere una priorità per questo progetto,
trattando dati personali di studenti e altre persone.
Ora verranno analizzati gli aspetti legislativi del trattamento dei dati e successivamente
gli aspetti di affidabilità discussi nel paragrafo 3.3.
La regolamentazione di tali questioni è principalmente affidata al decreto Legislativo del
30 giugno 2003 n.196, argomento del paragrafo seguente.
Decreto legislativo 196/2003
Tale decreto 4 ,volto a regolamentare la sicurezza sui dati che possono essere presenti in
un sistema, definisce5 :
• trattamento: qualunque operazione o complesso di operazioni, effettuati anche
senza l’ausilio di strumenti elettronici, concernenti la raccolta, la registrazione, l’organizzazione, la conservazione, la consultazione, l’elaborazione, la modificazione,
la selezione, l’estrazione, il raffronto, l’utilizzo, l’interconnessione, il blocco, la comunicazione, la diffusione, la cancellazione e la distruzione di dati, anche se non
registrati in una banca di dati
• dato personale: qualunque informazione relativa a persona fisica, persona giuridica, ente od associazione, identificati o identificabili, anche indirettamente, mediante
riferimento a qualsiasi altra informazione, ivi compreso un numero di identificazione
personale
• dati identificativi: i dati personali che permettono l’identificazione diretta dell’interessato;
• dati sensibili: i dati personali idonei a rivelare
– l’origine razziale ed etnica
– le convinzioni religiose, filosofiche o di altro genere
– le opinioni politiche
– l’adesione a partiti, sindacati, associazioni od organizzazioni a carattere religioso, filosofico, politico o sindacale
4
Per il testo completo visitare www.http://www.camera.it/parlam/leggi/deleghe/Testi/03196dl.
htm
5
Questa è la parte giuridico-legislativa della gestione del ciclo di vita dell’Identità
42
– lo stato di salute e la vita sessuale
• dati giudiziari: i dati personali idonei a rivelare provvedimenti in materia di
casellario giudiziale, di anagrafe delle sanzioni amministrative dipendenti da reato
e dei relativi carichi pendenti, o la qualità’ di imputato o di indagato
Ora, per quello che interessa a questo progetto, mettiamo in luce gli aspetti, e di
conseguenza gli articoli di tale decreto:
• Art. 11 (Modalita’ del trattamento e requisiti dei dati):
– I dati personali oggetto di trattamento sono:
∗ trattati in modo lecito e secondo correttezza;
∗ raccolti e registrati per scopi determinati, espliciti e legittimi, ed utilizzati
in altre operazioni del trattamento in termini compatibili con tali scopi
∗ esatti e, se necessario, aggiornati
∗ pertinenti, completi e non eccedenti rispetto alle finalità per le quali sono
raccolti o successivamente trattati
∗ conservati in una forma che consenta l’identificazione dell’interessato per
un periodo di tempo non superiore a quello necessario agli scopi per i
quali essi sono stati raccolti o successivamente trattati
– I dati personali trattati in violazione della disciplina rilevante in materia di
trattamento dei dati personali non possono essere utilizzati
• Art. 16 (Cessazione del trattamento): in caso di cessazione, per qualsiasi causa,
di un trattamento i dati sono:
– distrutti
– ceduti ad altro titolare, purchè destinati ad un trattamento in termini compatibili agli scopi per i quali i dati sono raccolti
– conservati per fini esclusivamente personali e non destinati ad una comunicazione sistematica o alla diffusione
– conservati o ceduti ad altro titolare, per scopi storici, statistici o scientifici
• Art. 23 (Consenso):
– Il trattamento di dati personali da parte di privati o di enti pubblici economici
è ammesso solo con il consenso espresso dell’interessato
43
– Il consenso può riguardare l’intero trattamento ovvero una o più operazioni
dello stesso
• Art. 31 (Obblighi di sicurezza): I dati personali oggetto di trattamento sono
custoditi e controllati, anche in relazione alle conoscenze acquisite in base al progresso tecnico, alla natura dei dati e alle specifiche caratteristiche del trattamento,
in modo da ridurre al minimo, mediante l’adozione di idonee e preventive misure
di sicurezza, i rischi di distruzione o perdita, anche accidentale, dei dati stessi,
di accesso non autorizzato o di trattamento non consentito o non conforme alle
finalità della raccolta
• Art. 34 (Trattamenti con strumenti elettronici): Il trattamento di dati personali
effettuato con strumenti elettronici è consentito solo se sono adottate le seguenti
misure minime:
– autenticazione informatica
– adozione di procedure di gestione delle credenziali di autenticazione
– utilizzo di un sistema di autorizzazione
– aggiornamento periodico dell’individuazione dell’ambito del trattamento consentito ai singoli incaricati e addetti alla gestione o alla manutenzione degli
strumenti elettronici
– protezione degli strumenti elettronici e dei dati rispetto a trattamenti illeciti
di dati, ad accessi non consentiti e a determinati programmi informatici
– adozione di procedure per la custodia di copie di sicurezza, il ripristino della
disponibilità dei dati e dei sistemi
– tenuta di un aggiornato documento programmatico sulla sicurezza
Ora caliamoci nei requisiti riguardanti il trattamento dei dati mediante strumenti
elettronici (allegato B dlgs. 196/2003):
• Sistema di autenticazione informatica:
– Il trattamento di dati personali con strumenti elettronici è consentito agli incaricati dotati di credenziali di autenticazione che consentano il superamento
di una procedura di autenticazione relativa a uno specifico trattamento o a
un insieme di trattamenti
44
– Le credenziali di autenticazione consistono in un codice per l’identificazione
dell’incaricato associato a una parola chiave riservata conosciuta solamente
dal medesimo oppure in un dispositivo di autenticazione in possesso e uso
esclusivo dell’incaricato, eventualmente associato a un codice identificativo o
a una parola chiave, oppure in una caratteristica biometrica dell’incaricato,
eventualmente associata a un codice identificativo o a una parola chiave
– Ad ogni incaricato sono assegnate o associate individualmente una o piu’
credenziali per l’autenticazione
– Con le istruzioni impartite agli incaricati è prescritto di adottare le necessarie cautele per assicurare la segretezza della componente riservata della
credenziale e la diligente custodia dei dispositivi in possesso ed uso esclusivo
dell’incaricato
– La parola chiave, quando è prevista dal sistema di autenticazione, è composta
da almeno otto caratteri oppure, nel caso in cui lo strumento elettronico non
lo permetta, da un numero di caratteri pari al massimo consentito; essa non
contiene riferimenti agevolmente riconducibili all’incaricato ed è modificata
da quest’ultimo al primo utilizzo e, successivamente, almeno ogni sei mesi
– Il codice per l’identificazione, laddove utilizzato, non può essere assegnato ad
altri incaricati, neppure in tempi diversi
– Le credenziali di autenticazione non utilizzate da almeno sei mesi sono disattivate, salvo quelle preventivamente autorizzate per soli scopi di gestione
tecnica
– Le credenziali sono disattivate anche in caso di perdita della qualità che
consente all’incaricato l’accesso ai dati personali
– Sono impartite istruzioni agli incaricati per non lasciare incustodito e accessibile lo strumento elettronico durante una sessione di trattamento
– Quando l’accesso ai dati e agli strumenti elettronici è consentito esclusivamente mediante uso della componente riservata della credenziale per l’autenticazione, sono impartite idonee e preventive disposizioni scritte volte a
individuare chiaramente le modalità con le quali il titolare può assicurare la
disponibilità di dati o strumenti elettronici in caso di prolungata assenza o
impedimento dell’incaricato che renda indispensabile e indifferibile intervenire
per esclusive necessitè di operativitè e di sicurezza del sistema. In tal caso
la custodia delle copie delle credenziali è organizzata garantendo la relativa
45
segretezza e individuando preventivamente per iscritto i soggetti incaricati
della loro custodia, i quali devono informare tempestivamente l’incaricato
dell’intervento effettuato.
• Sistema di autorizzazione:
– I profili di autorizzazione, per ciascun incaricato o per classi omogenee di
incaricati, sono individuati e configurati anteriormente all’inizio del trattamento, in modo da limitare l’accesso ai soli dati necessari per effettuare le
operazioni di trattamento
– Periodicamente, e comunque almeno annualmente, è verificata la sussistenza
delle condizioni per la conservazione dei profili di autorizzazione
• Altre misure di sicurezza:
– I dati personali sono protetti contro il rischio di intrusione e dell’azione di
programmi mediante l’attivazione di idonei strumenti elettronici da aggiornare
con cadenza almeno semestrale
– Gli aggiornamenti periodici dei programmi per elaboratore volti a prevenire
la vulnerabilità di strumenti elettronici e a correggerne difetti sono effettuati
almeno annualmente
– Sono impartite istruzioni organizzative e tecniche che prevedono il salvataggio
dei dati con frequenza almeno settimanale
• Documento programmatico sulla sicurezza:
– Entro il 31 marzo di ogni anno, il titolare di un trattamento di dati sensibili o di dati giudiziari redige anche attraverso il responsabile, se designato,
un documento programmatico sulla sicurezza contenente idonee informazioni
riguardo:
∗ l’elenco dei trattamenti di dati personali
∗ la distribuzione dei compiti e delle responsabilità nell’ambito delle strutture preposte al trattamento dei dati
∗ l’analisi dei rischi che incombono sui dati
∗ le misure da adottare per garantire l’integrità e la disponibilità dei dati,
nonchè la protezione delle aree e dei locali, rilevanti ai fini della loro
custodia e accessibilità
46
∗ la descrizione dei criteri e delle modalità per il ripristino della disponibilità
dei dati in seguito a distruzione o danneggiamento
∗ la previsione di interventi formativi degli incaricati del trattamento, per
renderli edotti dei rischi che incombono sui dati, delle misure disponibili
per prevenire eventi dannosi, dei profili della disciplina sulla protezione
dei dati personali più rilevanti in rapporto alle relative attività, delle
responsabilità che ne derivano e delle modalità per aggiornarsi sulle misure minime adottate dal titolare. La formazione è programmata già al
momento dell’ingresso in servizio, nonchè in occasione di cambiamenti
di mansioni, o di introduzione di nuovi significativi strumenti, rilevanti
rispetto al trattamento di dati personali
∗ la descrizione dei criteri da adottare per garantire l’adozione delle misure
minime di sicurezza in caso di trattamenti di dati personali affidati, in
conformità al codice, all’esterno della struttura del titolare
Privacy dei dati
Quindi il progetto, e in particolare il loro passaggio dalle diverse fonti al database unificato, dovrà attenersi alle direttive del decreto esposto nel paragrafo precedente.
Notiamo innanzitutto che i dati che vengono trattati non sono nè sensibili nè giudiziari,
quindi tutte le indicazioni nel caso di trattamento di queste categorie si possono trascurare.
Entrando nel dettaglio:
• Dall’articolo 11 i dati personali oggetto di trattamento sono trattati come indicato
(in modo lecito e secondo correttezza, raccolti e registrati per scopi determinati,
esatti e aggiornati, pertinenti), da cui si deduce che l’aggiornamento dei dati deve
essere trattato in modo ottimale (ved. 3.1.2)
• Per l’articolo 16 i dati nel nostro progetto vengono conservati per fini esclusivamente personali e non destinati ad una comunicazione sistematica (ved. 3.1.2)
• Già allo stato attuale tutte le misure minime elencate nell’articolo 34 sono rispettate sia in termini di autenticazione per l’accesso ai dati sia in termini di sicurezza
dei dati dal punto di vista software (protezione da intrusioni esterne) sia hardware
• Per le direttive specifiche presenti nell’allegato B verifichiamo che:
– Il trattamento di dati personali è consentito solo a personale autorizzato
47
– Lo scopo di questo progetto è proprio quello di rendere ad ogni incaricato una
ed una sola credenziale per l’autenticazione
– Le problematiche di lunghezza minima della password e difficoltà della password sono già verificati allo stato attuale
– L’univocità delle credenziali (password e username ad esempio) sono una
caratteristica fondamentale del progetto
– Allo stato attuale non esiste alcuna procedura che permetta la disattivazione
di credenziali di autenticazione non utilizzate da almeno sei mesi, quindi
questa procedura automatica dovrà essere implementata
– Le credenziali date dal SITI, per come visto, non possono che essere univoche
Possiamo perciò verificare come il progetto rispetti nella sua interezza (semplificato
anche dal fatto di non trattare dati sensibili o giuridici) il decreto legge 196/2003.
48
Policy per l’affidabilità, coerenza e la sicurezza
Quanto visto nel paragrafo 3.3 esistono oltre agli aspetti di trattamento dei dati procedure da rispettare per garantire che i dati non:
• vengano persi (per cause di vario genere)
• siano acceduti da personale non autorizzato
• stiano in uno stato incoerente
Mostriamo brevemente quali possano essere le soluzioni per evitare tutto ciò.
• provvedere a politiche di backup, quindi effettuare il dump
6
del database :
– ogni notte (quando il carico di lavoro è minore
– copiarlo su dispositivi removibili (nastri, DVD o altro)
– copiarlo in server differenti
• creare gruppi di utenti (con relativi insieme di credenziali), attraverso le procedure
di MySQL, che abbiamo diritti differenti:
– gruppo admin, con potere di modificare il Database
– gruppo onlyread, con la possibilità di sola lettura
– gruppo service, per quei servizi che necessitano di informazioni presenti nel
database
– gruppo other, a cui è negato tutto
– altri gruppi specifici
Tutte queste procedure sono facilmente realizzabili in MySQL oltre che per via testuale anche attraverso ottimi strumenti come phpmyadmin e MySQLAdministrator.
6
Ovvero lo script contenente le istruzioni per ricreare il database
49
4.4
Identità unica e ciclo di vita dell’identità
Una volta studiato il Database centralizzato che gestirà tutte le identità del sistema
sorge un problema non banale: quale attributo (o quale insieme di attributi) può essere
utilizzato come chiave identificativa dell’identità? Esso deve essere univoco (il che può
escludere la scelta ovvia e banale del codice fiscale) e il più possibile facile da ricordare
per l’utente poiché diverrà molto probabilmente l’UserID in un sistema centralizzato nel
sistema classico (ma non unico possibile) di autenticazione Username e Password.
Tra le varie ipotesi:
• indirizzo di posta elettronica
• identificativo progressivo numerico, legato ad esempio ad una smart-card
• il campo CN (fusione di cognome, punto e nome più eventualmente un numero per
distinguere omonimi)
• chiavi costruite ad hoc che siamo più memoniche di un contatore, ad esempio:
– matricola (prima matricola per gli studenti) + data di nascita (nella forma
gg/mm/aaaa)
– matricola (prima matricola per gli studenti) + prima password (implica per
sicurezza il cambio della prima password)
– altri costruiti ad hoc...
Per quello visto all’interno del progetto, non risulta necessario modificare l’attuale
policy di gestione del ciclo di vita dell’identità, ma anche se in un futuro si dovesse avere
la necessità di modificare tali politiche non sarà necesario stravolgere l’architettura del
progetto.
Vediamo in dettaglio quali possano essere i passi necessari per il corretto funzionamento del ciclo di vita dell’Identità rispetto alle Fonti e al Server IAM (come illustrato
in figura 4.1):
• creazione di una nuova Identità:
1. l’utente si registra presso una delle varie segreterie (una delle varie fonti)
2. le informazioni del nuovo utente dalla fonte vengono trasferite (mediante
canali sicuri, quindi cifrati) al Database IAM ogni sera
50
3. un controllo presente nel database (ad esempio uno script PERL) verifica che
l’ Identità non sia già nel Database verificando che ad esempio nome, cognome,
data di nascita e codice fiscale non siano già uguali in un altra Identità7 ;
se ciò fosse verificato si aggiungerebbe la nuova Identità e il suo ruolo collegato altrimenti si aggiungerebbe solamente il nuovo ruolo ricoperto (saremmo
quindi nel caso di Modifica di Ruolo8 )
• cancellazione di un Identità: si è valutato nel progetto più opportuno non cancellare mai un Identità dal server IAM, ma se questo fosse necessario verrebbe vista
come una comune modifica da trasferire dalla fonte al Database IAM la sera stessa
della cancellazione (come nel caso della creazione)
• modifica di attributi: come nei casi precedenti le modifiche di attributi sono
inviate la sera dalle fonti al Database IAM
• modifica credenziali d’accesso: deve essere fornita una pagina web che abbia
accesso diretto al Database e che quindi possa permettere alle Identità di cambiare
le credenziali come ritengono
Come si può facilmente intuire dai passi descritti sopra, i dati presenti nelle fonti non
sono coerenti con i dati presenti nel Database IAM per al più un giorno.
Inoltre i dati presenti nel Database IAM dovranno essere trasferiti
9
al server LDAP
che li renderà disponibili anche alle risorse. Si può pensare che questo ultimo passaggio
possa essere realizzato subito dopo che tali modifiche sono state apportate al Database
(evitando cosı̀ aumentare il tempo di incoerenza dei dati tra Fonti, Databse e LDAP).
7
Possiamo pensare difatti che due identità con stesso nome, cognome, codice fiscale e nate lo stesso
giorno siano la stessa persona
8
Questo perchè l’Identità è già presente ma non ha associato il nuovo ruolo
9
Vedere il paragrafo 4.5
51
Figura 4.3: Sincronizzazione dei dati tra Fonti, DB e LDAP
Come di puù quindi verificare dall’esempio dell’immagine 4.3, se un utente effettua
una modifica in una fonte alle 11 di mattina, l’informazione potrà essere effettivamente
visibile alla risorsa il giorno successivo.
52
4.5
Dati da replicare sul server LDAP
Per vari motivi è fondamentale mantenere le informazioni in un database centralizzato, ma per interfacciarsi con le risorse, per la gestione dell’autenticazione e dell’autorizzazione centralizzate, diventa necessario replicare alcune informazioni su un server
LDAP.
Entriamo ora nel dettaglio della scelta degli attributi da replicare;
per quel che riguarda gli attributi anagrafici:
• IDIdentità
• 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
Oltre alle informazioni sopraelencate vanno aggiunti gli attributi necessari per la gestione
dell’accesso alle risorse:
• account
• posixAccount
• shadowAccount
• sambaSamAccount
53
• radiusprofile
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
– Corso di laurea di appartenenza (e Facoltà di conseguenza)
• 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 Facoltà di conseguenza)
• Professore a contratto
– IDSGE
– Codice SISA
54
– Data Inizio
– Data Fine
– Codice Ruolo
– Profilo e categoria
– Stati del ruolo
– Aree e settori
Da notare che si è deciso di replicare in LDAP molte informazioni contenute nel
database (principalemente per motivi di efficienza), una diversa soluzione poteva essere
quella di avere un numero ristretto di dati in LDAP e nel caso una applicazione avesse
bisogno di ulteriori informazioni su un utente, “collegarla” direttamente al database
implementando, per esempio, un web service per questo scopo.
Questi dati verranno in seguito organizzati e gestiti opportunamente dal server LDAP
che permetterà quindi l’accesso alle risorse.
55
Capitolo 5
Conclusioni
In questa tesi si sono analizzati e formalizzati tutti gli elementi e le problematiche (o
comunque quelli fondamentali) riguardanti l’Identity Management (Capitolo 1), successivamente si sono delinati i vincoli con cui il progetto dovrà avere a che fare (Capitolo 2)
per in fine analizzare e giustificare le scelte fatte in sede di progettazione dell’architettura
(Capitolo 3).
Si sono applicati la maggior parte dei concetti visti nel corso di Basi di Dati (realizzazione di una Base di Dati, problematiche varie di sicurezza e affidabilità, linguaggio
SQL) e in parte anche nei corsi si Sistemi Informativi e Reti di Calcolatori.
Per quel che riguarda il progetto si è quindi realizzato un server IAM (sia il lato Database
di gestione dell’Identità sia il lato LDAP per la gestione delle richieste dei servizi) che
verificasse tutti i requisiti che deve possedere per essere:
• funzionale
• sicuro
• affidabile
• performante
Dopo l’effettiva implementazione di tale progetto sia la gestione delle Identità verrà
razionalizzata (andando quindi a risolvere le problematiche dell’attuale gestione) sia
l’interfacciamento con i servizi subirà dei netti miglioramenti.
56
5.1
Sviluppi futuri
La parte di gestione dell’Identità dell’Università di Parma, se pur migliorata attraverso
questo studio, può ulteriormente essere migliorata in questi punti:
• migliorare le comunicazioni tra le varie fonti e il database centralizzato
• dare la possibilità di iscrizioni web o comunque servizi web per gestire parte del
ciclo di vita
Quel che riguarda il primo punto è sicuramente l’aspetto più interessante: difatti
passare informazioni tramite file di testo dalle varie segreterie al centro di calcolo non è
una soluzione ideale.
Una soluzione sarebbe quella di introdurre i Web Service:
un Web Service (servizio web) è un sistema software progettato per supportare l’interoperabilità tra diversi elaboratori su di una medesima rete[10];
la caratteristica fondamentale di un Web Service sta nell’offrire un’interfaccia software
utilizzando la quale altri sistemi possono interagire con il Web Service stesso attivando le
operazioni descritte nell’interfaccia tramite appositi messaggi inclusi in una busta: tali
messaggi sono, solitamente, trasportati tramite il protocollo HTTP e formattati secondo
lo standard XML.
Proprio grazie all’utilizzo di standard basati su XML, tramite un’architettura basata sui
Web Service (chiamata, con terminologia inglese, Service oriented Architecture - SOA)
applicazioni software scritte in diversi linguaggi di programmazione e implementate su
diverse piattaforme hardware possono quindi essere utilizzate, tramite le interfacce che
queste espongono pubblicamente e mediante l’utilizzo delle funzioni che sono in grado
di effettuare (i servizi che mettono a disposizione) per lo scambio di informazioni e l’effettuazione di operazioni complesse sia su reti aziendali come anche su Internet: la
possibilità dell’interoperabilità fra diversi software (ad esempio, tra Java e Python) e
diverse piattaforme hardware (come Windows e Linux) è resa possibile dall’uso di standard aperti.
L’interazione tra servizi, fonti e server IAM avvanteggierebbe notevolmente tutta l’architettura.
57
Figura 5.1: Architettura con Web Service
58
Appendice A
Glossario
• Ruolo: insieme di privilegi all’interno del sistema dovute alla funzione che si
ricopre all’interno dell’Università
• Identità: entità unica che accede al sistema e che deve essere riconosciuta e alla
quale possono essere associati diversi ruoli; quindi è l’insieme delle informazioni
che caratterizzano un utente che sono le informazioni relative alla identità e ai
diversi ruoli e/o attributi che questo può avere
• Risorsa informatica (o brevemente risorsa) intendiamo un servizio reso disponibile ad un insieme di utenti registrati, ovvero di cui si conosce l’identità, che ha
uno scopo preciso ed utile all’utente che ne fa uso, ed è accessibile attraverso mezzi
informatici (ad esempio attraverso un computer). Esempi di risorse sono la posta
elettronica, l’accesso ad un computer oppure l’accesso ad una rete locale (servizi
ad esempio offerti dall’Università di Parma).
• Server IAM: sistema software ed hardware centralizzato (indicativamente composto da un unico Database e da un sistema LDAP) che gestisce in modo ottimale
il ciclo di vita delle Identità ed al quale le applicazioni si interfacciano gestendo
perciò gli accessi, le autorizzazioni al sistema.
59
Appendice B
Dump MySQL
Di seguito riporto il dump del database IAM unificato, eseguibile in MySQL.
−−
−−
−−
−−
−−
MySQL dump 1 0 . 1 1
Host : l o c a l h o s t
Database : u n i p r
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
Server version
5.0.67 −0 ubuntu6
/∗ ! 4 0 1 0 1
/∗ ! 4 0 1 0 1
/∗ ! 4 0 1 0 1
/∗ ! 4 0 1 0 1
/∗ ! 4 0 1 0 3
/∗ ! 4 0 1 0 3
/∗ ! 4 0 0 1 4
/∗ ! 4 0 0 1 4
/∗ ! 4 0 1 0 1
/∗ ! 4 0 1 1 1
SET
SET
SET
SET
SET
SET
SET
SET
SET
SET
@OLD CHARACTER SET CLIENT=@@CHARACTER SET CLIENT ∗/ ;
@OLD CHARACTER SET RESULTS=@@CHARACTER SET RESULTS ∗/ ;
@OLD COLLATION CONNECTION=@@COLLATION CONNECTION ∗/ ;
NAMES u t f 8 ∗/ ;
@OLD TIME ZONE=@@TIME ZONE ∗/ ;
TIME ZONE= ’+00:00 ’ ∗/ ;
@OLD UNIQUE CHECKS=@@UNIQUE CHECKS, UNIQUE CHECKS=0 ∗/ ;
@OLD FOREIGN KEY CHECKS=@@FOREIGN KEY CHECKS, FOREIGN KEY CHECKS=0 ∗/ ;
@OLD SQL MODE=@@SQL MODE, SQL MODE=’NO AUTO VALUE ON ZERO’ ∗/ ;
@OLD SQL NOTES=@@SQL NOTES, SQL NOTES=0 ∗/ ;
−−
−− T a b l e s t r u c t u r e f o r t a b l e
−−
‘AREA‘
DROP TABLE IF EXISTS ‘AREA‘ ;
= @@character set client ;
SET @ s a v e d c s c l i e n t
SET c h a r a c t e r s e t c l i e n t = u t f 8 ;
CREATE TABLE ‘AREA‘ (
‘ s i g l a ‘ char ( 2 ) NOT NULL COMMENT ’ Co di c e d e l l a r e a d i d a t t i c a ’ ,
‘ nome ‘ varchar ( 3 2 ) NOT NULL COMMENT ’ D e s c r i z i o n e p e r e s t e s o ’ ,
PRIMARY KEY ( ‘ s i g l a ‘ )
) ENGINE=InnoDB DEFAULT CHARSET=l a t i n 1 COMMENT= ’ Aree d i d a t t i c h e ’ ;
SET c h a r a c t e r s e t c l i e n t = @ s a v e d c s c l i e n t ;
−−
60
−− Dumping d a t a f o r t a b l e
−−
‘AREA‘
LOCK TABLES ‘AREA‘ WRITE;
/∗ ! 4 0 0 0 0 ALTER TABLE ‘AREA‘ DISABLE KEYS ∗/ ;
/∗ ! 4 0 0 0 0 ALTER TABLE ‘AREA‘ ENABLE KEYS ∗/ ;
UNLOCK TABLES ;
−−
−− T a b l e s t r u c t u r e f o r t a b l e
−−
‘CARRIERA‘
DROP TABLE IF EXISTS ‘CARRIERA‘ ;
= @@character set client ;
SET @ s a v e d c s c l i e n t
SET c h a r a c t e r s e t c l i e n t = u t f 8 ;
CREATE TABLE ‘CARRIERA‘ (
‘ m a t r i c o l a ‘ char ( 6 ) NOT NULL COMMENT ’ M a t r i c o l a d e l l o s t u d e n t e ’ ,
‘ a n n o p r i m a i m m a t r i c o l a z i o n e ‘ i n t ( 1 1 ) NOT NULL
COMMENT ’ Anno d i prima i m m a t r i c o l a z i o n e ’ ,
‘ d a t a l a u r e a t r i e n n a l e ‘ date default NULL
COMMENT ’ Data d e l l a l a u r e a t r i e n n a l e ’ ,
‘ d a t a l a u r e a s p e c i a l i s t i c a ‘ date default NULL
COMMENT ’ Data d e l l a l a u r e a s p e c i a l i s t i c a ’ ,
‘ c o r s o d i l a u r e a a p p a r t e n e n z a ‘ char ( 4 ) NOT NULL
COMMENT ’ Corso d i l a u r e a d i a p p a r t e n e n z a ’ ,
PRIMARY KEY ( ‘ m a t r i c o l a ‘ ) ,
KEY ‘ n e w f k c o n s t r a i n t 5 ‘ ( ‘ c o r s o d i l a u r e a a p p a r t e n e n z a ‘ ) ,
CONSTRAINT ‘ n e w f k c o n s t r a i n t 5 ‘ FOREIGN KEY ( ‘ c o r s o d i l a u r e a a p p a r t e n e n z a ‘ )
REFERENCES ‘CORSO LAUREA‘ ( ‘ c o d i c e ‘ )
) ENGINE=InnoDB DEFAULT CHARSET=l a t i n 1 COMMENT= ’ C a r r i e r e d e l l o s t u d e n t e ’ ;
SET c h a r a c t e r s e t c l i e n t = @ s a v e d c s c l i e n t ;
−−
−− Dumping d a t a f o r t a b l e
−−
‘CARRIERA‘
LOCK TABLES ‘CARRIERA‘ WRITE;
/∗ ! 4 0 0 0 0 ALTER TABLE ‘CARRIERA‘ DISABLE KEYS ∗/ ;
/∗ ! 4 0 0 0 0 ALTER TABLE ‘CARRIERA‘ ENABLE KEYS ∗/ ;
UNLOCK TABLES ;
−−
−− T a b l e s t r u c t u r e f o r t a b l e
−−
‘CODICE RUOLO‘
DROP TABLE IF EXISTS ‘CODICE RUOLO‘ ;
SET @ s a v e d c s c l i e n t
= @@character set client ;
SET c h a r a c t e r s e t c l i e n t = u t f 8 ;
CREATE TABLE ‘CODICE RUOLO‘ (
‘ s i g l a ‘ char ( 2 ) NOT NULL COMMENT ’ Co di c e d e l r u o l o ’ ,
‘ nome ‘ varchar ( 3 2 ) NOT NULL COMMENT ’Nome p e r e s t e s o d e l r u o l o ’ ,
61
PRIMARY KEY ( ‘ s i g l a ‘ )
) ENGINE=InnoDB DEFAULT CHARSET=l a t i n 1 COMMENT= ’ C od ic e Ruolo ’ ;
SET c h a r a c t e r s e t c l i e n t = @ s a v e d c s c l i e n t ;
−−
−− Dumping d a t a f o r t a b l e
−−
‘CODICE RUOLO‘
LOCK TABLES ‘CODICE RUOLO‘ WRITE;
/∗ ! 4 0 0 0 0 ALTER TABLE ‘CODICE RUOLO‘ DISABLE KEYS ∗/ ;
/∗ ! 4 0 0 0 0 ALTER TABLE ‘CODICE RUOLO‘ ENABLE KEYS ∗/ ;
UNLOCK TABLES ;
−−
−− T a b l e s t r u c t u r e f o r t a b l e
−−
‘CORSO LAUREA‘
DROP TABLE IF EXISTS ‘CORSO LAUREA‘ ;
SET @ s a v e d c s c l i e n t
= @@character set client ;
SET c h a r a c t e r s e t c l i e n t = u t f 8 ;
CREATE TABLE ‘CORSO LAUREA‘ (
‘ c o d i c e ‘ char ( 4 ) NOT NULL COMMENT ’ Co di c e a 4 c i f r e ’ ,
‘ durata ‘ i n t ( 1 1 ) NOT NULL COMMENT ’ Durata i n a n n i ’ ,
‘ nome ‘ varchar ( 3 2 ) NOT NULL COMMENT ’Nome p e r e s t e s o ’ ,
‘ t i p o c o r s o ‘ char ( 2 ) NOT NULL COMMENT ’ Tipo d i c o r s o ’ ,
‘ f a c o l t a ‘ char ( 2 ) NOT NULL COMMENT ’ F a c o l t a d i a p p a r t e n e n z a ’ ,
PRIMARY KEY ( ‘ c o d i c e ‘ ) ,
KEY ‘ n e w f k c o n s t r a i n t 3 ‘ ( ‘ t i p o c o r s o ‘ ) ,
KEY ‘ n e w f k c o n s t r a i n t 4 ‘ ( ‘ f a c o l t a ‘ ) ,
CONSTRAINT ‘ n e w f k c o n s t r a i n t 4 ‘ FOREIGN KEY ( ‘ f a c o l t a ‘ )
REFERENCES ‘FACOLTA‘ ( ‘ s i g l a ‘ ) ,
CONSTRAINT ‘ n e w f k c o n s t r a i n t 3 ‘ FOREIGN KEY ( ‘ t i p o c o r s o ‘ )
REFERENCES ‘TIPO CORSO‘ ( ‘ c o d i c e ‘ )
) ENGINE=InnoDB DEFAULT CHARSET=l a t i n 1 COMMENT= ’ C o r s i d i l a u r e a ’ ;
SET c h a r a c t e r s e t c l i e n t = @ s a v e d c s c l i e n t ;
−−
−− Dumping d a t a f o r t a b l e
−−
‘CORSO LAUREA‘
LOCK TABLES ‘CORSO LAUREA‘ WRITE;
/∗ ! 4 0 0 0 0 ALTER TABLE ‘CORSO LAUREA‘ DISABLE KEYS ∗/ ;
/∗ ! 4 0 0 0 0 ALTER TABLE ‘CORSO LAUREA‘ ENABLE KEYS ∗/ ;
UNLOCK TABLES ;
−−
−− T a b l e s t r u c t u r e f o r t a b l e
−−
‘DATI LDAP‘
DROP TABLE IF EXISTS ‘DATI LDAP ‘ ;
= @@character set client ;
SET @ s a v e d c s c l i e n t
62
SET c h a r a c t e r s e t c l i e n t = u t f 8 ;
CREATE TABLE ‘DATI LDAP ‘ (
‘ cn ‘ varchar ( 3 2 ) NOT NULL COMMENT ’Common name ’ ,
‘ mail ‘ varchar ( 3 2 ) NOT NULL COMMENT ’ Mail a s s e g n a t a ’ ,
‘ p a s s w o r d i n i z i a l e ‘ varchar ( 3 2 ) NOT NULL COMMENT ’ Password i n i z i a l e ’ ,
‘ uid ‘ varchar ( 3 2 ) NOT NULL COMMENT ’UID ’ ,
‘ uid number ‘ i n t ( 1 1 ) NOT NULL,
PRIMARY KEY ( ‘ cn ‘ )
) ENGINE=InnoDB DEFAULT CHARSET=l a t i n 1
COMMENT= ’ D a t i u t i l i p e r l ’ ’ a c c e s s o a l l e r i s o r s e ( i n c o m p l e t o ) ’ ;
SET c h a r a c t e r s e t c l i e n t = @ s a v e d c s c l i e n t ;
−−
−− Dumping d a t a f o r t a b l e
−−
‘DATI LDAP‘
LOCK TABLES ‘DATI LDAP ‘ WRITE;
/∗ ! 4 0 0 0 0 ALTER TABLE ‘DATI LDAP‘ DISABLE KEYS ∗/ ;
/∗ ! 4 0 0 0 0 ALTER TABLE ‘DATI LDAP‘ ENABLE KEYS ∗/ ;
UNLOCK TABLES ;
−−
−− T a b l e s t r u c t u r e f o r t a b l e
−−
‘DIPARTIMENTI‘
DROP TABLE IF EXISTS ‘DIPARTIMENTI ‘ ;
SET @ s a v e d c s c l i e n t
= @@character set client ;
SET c h a r a c t e r s e t c l i e n t = u t f 8 ;
CREATE TABLE ‘DIPARTIMENTI‘ (
‘ nome ‘ varchar ( 3 2 ) NOT NULL COMMENT ’Nome d e l d i p a r t i m e n t o ’ ,
‘ s i g l a ‘ char ( 2 ) NOT NULL COMMENT ’ Co di c e d e l d i p a r t i m e n t o ’ ,
‘ s e d e d i p a r t i m e n t o ‘ char ( 6 ) default NULL COMMENT ’ Sede d e l d i p a r t i m e n t o ’ ,
PRIMARY KEY ( ‘ s i g l a ‘ ) ,
KEY ‘ n e w f k c o n s t r a i n t 7 ‘ ( ‘ s e d e d i p a r t i m e n t o ‘ ) ,
CONSTRAINT ‘ n e w f k c o n s t r a i n t 7 ‘ FOREIGN KEY ( ‘ s e d e d i p a r t i m e n t o ‘ )
REFERENCES ‘ SEDI ‘ ( ‘ c o d i c e ‘ )
) ENGINE=InnoDB DEFAULT CHARSET=l a t i n 1
COMMENT= ’ D i p a r t i m e n t i d e l l U n i v e r s i t a d i Parma ’ ;
SET c h a r a c t e r s e t c l i e n t = @ s a v e d c s c l i e n t ;
−−
−− Dumping d a t a f o r t a b l e
−−
‘DIPARTIMENTI‘
LOCK TABLES ‘DIPARTIMENTI‘ WRITE;
/∗ ! 4 0 0 0 0 ALTER TABLE ‘DIPARTIMENTI‘ DISABLE KEYS ∗/ ;
/∗ ! 4 0 0 0 0 ALTER TABLE ‘DIPARTIMENTI‘ ENABLE KEYS ∗/ ;
UNLOCK TABLES ;
−−
−− T a b l e s t r u c t u r e f o r t a b l e
‘FACOLTA‘
63
−−
DROP TABLE IF EXISTS ‘FACOLTA‘ ;
SET @ s a v e d c s c l i e n t
= @@character set client ;
SET c h a r a c t e r s e t c l i e n t = u t f 8 ;
CREATE TABLE ‘FACOLTA‘ (
‘ s i g l a ‘ char ( 2 ) NOT NULL COMMENT ’ Co di c e a 2 c i f r e ’ ,
‘ nome ‘ varchar ( 3 2 ) NOT NULL COMMENT ’Nome p e r e s t e s o ’ ,
PRIMARY KEY ( ‘ s i g l a ‘ )
) ENGINE=InnoDB DEFAULT CHARSET=l a t i n 1
COMMENT= ’ F a c o l t a d e l l ’ ’ U n i v e r s i t a d i Parma ’ ;
SET c h a r a c t e r s e t c l i e n t = @ s a v e d c s c l i e n t ;
−−
−− Dumping d a t a f o r t a b l e
−−
‘FACOLTA‘
LOCK TABLES ‘FACOLTA‘ WRITE;
/∗ ! 4 0 0 0 0 ALTER TABLE ‘FACOLTA‘ DISABLE KEYS ∗/ ;
/∗ ! 4 0 0 0 0 ALTER TABLE ‘FACOLTA‘ ENABLE KEYS ∗/ ;
UNLOCK TABLES ;
−−
−− T a b l e s t r u c t u r e f o r t a b l e
−−
‘IDENTITA‘
DROP TABLE IF EXISTS ‘IDENTITA ‘ ;
= @@character set client ;
SET @ s a v e d c s c l i e n t
SET c h a r a c t e r s e t c l i e n t = u t f 8 ;
CREATE TABLE ‘IDENTITA ‘ (
‘ i d i d e n t i t a ‘ varchar ( 3 2 ) NOT NULL COMMENT ’E−Mail a s s e g n a t a ’ ,
‘ cognome ‘ varchar ( 3 2 ) NOT NULL COMMENT ’ Cognome ’ ,
‘ nome ‘ varchar ( 3 2 ) NOT NULL COMMENT ’Nome ’ ,
‘ s e s s o ‘ char ( 1 ) NOT NULL COMMENT ’ S e s s o ’ ,
‘ d a t a n a s c i t a ‘ date NOT NULL COMMENT ’ Data d i n a s c i t a ’ ,
‘ c o d i c e f i s c a l e ‘ varchar ( 1 6 ) NOT NULL COMMENT ’ Co di c e f i s c a l e ’ ,
‘ c a p d o m i c i l i o ‘ varchar ( 5 ) NOT NULL COMMENT ’CAP d o m i c i l i o ’ ,
‘ c a p r e s i d e n z a ‘ varchar ( 5 ) NOT NULL COMMENT ’CAP r e s i d e n z a ’ ,
‘ m a i l p e r s o n a l e ‘ varchar ( 3 2 ) default NULL COMMENT ’E Mail p e r s o n a l e ’ ,
‘ t e l e f o n o r e s i d e n z a ‘ varchar ( 3 2 ) default NULL COMMENT ’ T e l e f o n o r e s i d e n z a
‘ t e l e f o n o d o m i c i l i o ‘ varchar ( 3 2 ) default NULL COMMENT ’ T e l e f o n o d o m i c i l i o
‘ t e l e f o n o c e l l u l a r e ‘ varchar ( 3 2 ) default NULL COMMENT ’ T e l e f o n o c e l l u l a r e
‘ f ax ‘ varchar ( 3 2 ) default NULL COMMENT ’ Fax ’ ,
‘ v i a d o m i c i l i o ‘ varchar ( 3 2 ) NOT NULL COMMENT ’ Via d o m i c i l i o ’ ,
‘ v i a r e s i d e n z a ‘ varchar ( 3 2 ) NOT NULL COMMENT ’ Via r e s i d e n z a ’ ,
‘ t i t o l o o n o r i f i c o ‘ i n t ( 1 1 ) default NULL COMMENT ’ T i t o l o o n o r i f i c o ’ ,
‘ s t a t o c i t t a d i n a n z a ‘ varchar ( 3 2 ) NOT NULL COMMENT ’ S t a t o d i c i t t a d i n a n z a ’
‘ s t a t o r e s i d e n z a ‘ varchar ( 3 2 ) NOT NULL COMMENT ’ S t a t o d i r e s i d e n z a ’ ,
‘ s t a t o d o m i c i l i o ‘ varchar ( 3 2 ) NOT NULL COMMENT ’ S t a t o d i d o m i c i l i o ’ ,
‘ s t a t o n a s c i t a ‘ varchar ( 3 2 ) NOT NULL COMMENT ’ S t a t o d i n a s c i t a ’ ,
‘ cn ‘ varchar ( 3 2 ) NOT NULL COMMENT ’Common Name ’ ,
64
’,
’,
’,
,
‘ l u o g o n a s c i t a ‘ char ( 6 ) NOT NULL COMMENT ’ Luogo d i n a s c i t a ’ ,
‘ l u o g o r e s i d e n z a ‘ char ( 6 ) NOT NULL COMMENT ’ Luogo d i r e s i d e n z a ’ ,
‘ l u o g o d o m i c i l i o ‘ char ( 6 ) NOT NULL COMMENT ’ Luogo d i d o m i c i l i o ’ ,
PRIMARY KEY ( ‘ i d i d e n t i t a ‘ ) ,
KEY ‘ n e w f k c o n s t r a i n t 2 0 ‘ ( ‘ t i t o l o o n o r i f i c o ‘ ) ,
KEY ‘ n e w f k c o n s t r a i n t 2 1 ‘ ( ‘ s t a t o c i t t a d i n a n z a ‘ ) ,
KEY ‘ n e w f k c o n s t r a i n t 2 3 ‘ ( ‘ s t a t o r e s i d e n z a ‘ ) ,
KEY ‘ n e w f k c o n s t r a i n t 2 4 ‘ ( ‘ s t a t o d o m i c i l i o ‘ ) ,
KEY ‘ n e w f k c o n s t r a i n t 2 5 ‘ ( ‘ s t a t o n a s c i t a ‘ ) ,
KEY ‘ n e w f k c o n s t r a i n t 2 6 ‘ ( ‘ cn ‘ ) ,
KEY ‘ n e w f k c o n s t r a i n t 2 7 ‘ ( ‘ l u o g o n a s c i t a ‘ ) ,
KEY ‘ n e w f k c o n s t r a i n t 2 8 ‘ ( ‘ l u o g o r e s i d e n z a ‘ ) ,
KEY ‘ n e w f k c o n s t r a i n t 2 9 ‘ ( ‘ l u o g o d o m i c i l i o ‘ ) ,
CONSTRAINT ‘ n e w f k c o n s t r a i n t 2 8 ‘ FOREIGN KEY ( ‘ l u o g o r e s i d e n z a ‘ )
REFERENCES ‘LUOGO‘ ( ‘ c o d i c e i s t a t ‘ ) ,
CONSTRAINT ‘ n e w f k c o n s t r a i n t 2 9 ‘ FOREIGN KEY ( ‘ l u o g o d o m i c i l i o ‘ )
REFERENCES ‘LUOGO‘ ( ‘ c o d i c e i s t a t ‘ ) ,
CONSTRAINT ‘ n e w f k c o n s t r a i n t 2 0 ‘ FOREIGN KEY ( ‘ t i t o l o o n o r i f i c o ‘ )
REFERENCES ‘TITOLO ONORIFICO‘ ( ‘ c o d i c e ‘ ) ,
CONSTRAINT ‘ n e w f k c o n s t r a i n t 2 1 ‘ FOREIGN KEY ( ‘ s t a t o c i t t a d i n a n z a ‘ )
REFERENCES ‘STATO‘ ( ‘ nome ‘ ) ,
CONSTRAINT ‘ n e w f k c o n s t r a i n t 2 2 ‘ FOREIGN KEY ( ‘ s t a t o r e s i d e n z a ‘ )
REFERENCES ‘STATO‘ ( ‘ nome ‘ ) ,
CONSTRAINT ‘ n e w f k c o n s t r a i n t 2 3 ‘ FOREIGN KEY ( ‘ s t a t o r e s i d e n z a ‘ )
REFERENCES ‘STATO‘ ( ‘ nome ‘ ) ,
CONSTRAINT ‘ n e w f k c o n s t r a i n t 2 4 ‘ FOREIGN KEY ( ‘ s t a t o d o m i c i l i o ‘ )
REFERENCES ‘STATO‘ ( ‘ nome ‘ ) ,
CONSTRAINT ‘ n e w f k c o n s t r a i n t 2 5 ‘ FOREIGN KEY ( ‘ s t a t o n a s c i t a ‘ )
REFERENCES ‘STATO‘ ( ‘ nome ‘ ) ,
CONSTRAINT ‘ n e w f k c o n s t r a i n t 2 6 ‘ FOREIGN KEY ( ‘ cn ‘ )
REFERENCES ‘DATI LDAP ‘ ( ‘ cn ‘ ) ,
CONSTRAINT ‘ n e w f k c o n s t r a i n t 2 7 ‘ FOREIGN KEY ( ‘ l u o g o n a s c i t a ‘ )
REFERENCES ‘LUOGO‘ ( ‘ c o d i c e i s t a t ‘ )
) ENGINE=InnoDB DEFAULT CHARSET=l a t i n 1 ROW FORMAT=DYNAMIC
COMMENT= ’ I d e n t i t a d e l l U n i v e r s i t a d i Parma ’ ;
SET c h a r a c t e r s e t c l i e n t = @ s a v e d c s c l i e n t ;
−−
−− Dumping d a t a f o r t a b l e
−−
‘IDENTITA‘
LOCK TABLES ‘IDENTITA ‘ WRITE;
/∗ ! 4 0 0 0 0 ALTER TABLE ‘IDENTITA‘ DISABLE KEYS ∗/ ;
/∗ ! 4 0 0 0 0 ALTER TABLE ‘IDENTITA‘ ENABLE KEYS ∗/ ;
UNLOCK TABLES ;
−−
−− T a b l e s t r u c t u r e f o r t a b l e
−−
‘INCARICHI ‘
DROP TABLE IF EXISTS ‘ INCARICHI ‘ ;
65
SET @ s a v e d c s c l i e n t
= @@character set client ;
SET c h a r a c t e r s e t c l i e n t = u t f 8 ;
CREATE TABLE ‘ INCARICHI ‘ (
‘ s i g l a ‘ char ( 2 ) NOT NULL COMMENT ’ Co di c e d e g l i i n c a r i c h i ’ ,
‘ nome ‘ varchar ( 3 2 ) NOT NULL COMMENT ’ D e s c r i z i o n e p e r e s t e s o ’ ,
PRIMARY KEY ( ‘ s i g l a ‘ )
) ENGINE=InnoDB DEFAULT CHARSET=l a t i n 1 COMMENT= ’ I n c a r i c h i ’ ;
SET c h a r a c t e r s e t c l i e n t = @ s a v e d c s c l i e n t ;
−−
−− Dumping d a t a f o r t a b l e
−−
‘INCARICHI ‘
LOCK TABLES ‘ INCARICHI ‘ WRITE;
/∗ ! 4 0 0 0 0 ALTER TABLE ‘INCARICHI ‘ DISABLE KEYS ∗/ ;
/∗ ! 4 0 0 0 0 ALTER TABLE ‘INCARICHI ‘ ENABLE KEYS ∗/ ;
UNLOCK TABLES ;
−−
−− T a b l e s t r u c t u r e f o r t a b l e
−−
‘LUOGO‘
DROP TABLE IF EXISTS ‘LUOGO‘ ;
= @@character set client ;
SET @ s a v e d c s c l i e n t
SET c h a r a c t e r s e t c l i e n t = u t f 8 ;
CREATE TABLE ‘LUOGO‘ (
‘ c o d i c e i s t a t ‘ char ( 6 ) NOT NULL COMMENT ’ C odi c e ISTAT ’ ,
‘ c o d i c e a g e n z i a e n t r a t e ‘ char ( 4 ) NOT NULL COMMENT ’ Co di c e c a t a s t a l e ’ ,
‘ d e s c r i z i o n e ‘ varchar ( 3 2 ) NOT NULL COMMENT ’Nome p e r e s t e s o ’ ,
‘ comune ‘ varchar ( 3 2 ) NOT NULL COMMENT ’Nome p e r e s t e s o d e l comune ’ ,
‘ p r o v i n c i a ‘ char ( 2 ) NOT NULL COMMENT ’ S i g l a a u t o m o b i l i s t i c a d e l l a p r o v i n c i a ’ ,
PRIMARY KEY ( ‘ c o d i c e i s t a t ‘ ) ,
KEY ‘ n e w f k c o n s t r a i n t ‘ ( ‘ p r o v i n c i a ‘ ) ,
CONSTRAINT ‘ n e w f k c o n s t r a i n t ‘ FOREIGN KEY ( ‘ p r o v i n c i a ‘ )
REFERENCES ‘PROVINCIA‘ ( ‘ s i g l a ‘ )
) ENGINE=InnoDB DEFAULT CHARSET=l a t i n 1 COMMENT= ’ L o c a l i t a i t a l i a n i ’ ;
SET c h a r a c t e r s e t c l i e n t = @ s a v e d c s c l i e n t ;
−−
−− Dumping d a t a f o r t a b l e
−−
‘LUOGO‘
LOCK TABLES ‘LUOGO‘ WRITE;
/∗ ! 4 0 0 0 0 ALTER TABLE ‘LUOGO‘ DISABLE KEYS ∗/ ;
/∗ ! 4 0 0 0 0 ALTER TABLE ‘LUOGO‘ ENABLE KEYS ∗/ ;
UNLOCK TABLES ;
−−
−− T a b l e s t r u c t u r e f o r t a b l e
−−
‘PROFILO‘
66
DROP TABLE IF EXISTS ‘PROFILO ‘ ;
SET @ s a v e d c s c l i e n t
= @@character set client ;
SET c h a r a c t e r s e t c l i e n t = u t f 8 ;
CREATE TABLE ‘PROFILO‘ (
‘ s i g l a ‘ char ( 1 1 ) NOT NULL COMMENT ’ Co di c e d e l p r o f i l o ( 1 1 c a r a t t e r i ) ’ ,
‘ nome ‘ varchar ( 3 2 ) NOT NULL COMMENT ’ D e s c r i z i o n e p e r e s t e s o ’ ,
PRIMARY KEY ( ‘ s i g l a ‘ )
) ENGINE=InnoDB DEFAULT CHARSET=l a t i n 1 COMMENT= ’ P r o f i l o d e l r u o l o ’ ;
SET c h a r a c t e r s e t c l i e n t = @ s a v e d c s c l i e n t ;
−−
−− Dumping d a t a f o r t a b l e
−−
‘PROFILO‘
LOCK TABLES ‘PROFILO‘ WRITE;
/∗ ! 4 0 0 0 0 ALTER TABLE ‘PROFILO‘ DISABLE KEYS ∗/ ;
/∗ ! 4 0 0 0 0 ALTER TABLE ‘PROFILO‘ ENABLE KEYS ∗/ ;
UNLOCK TABLES ;
−−
−− T a b l e s t r u c t u r e f o r t a b l e
−−
‘PROVINCIA‘
DROP TABLE IF EXISTS ‘PROVINCIA ‘ ;
= @@character set client ;
SET @ s a v e d c s c l i e n t
SET c h a r a c t e r s e t c l i e n t = u t f 8 ;
CREATE TABLE ‘PROVINCIA‘ (
‘ s i g l a ‘ char ( 2 ) NOT NULL,
‘ nome ‘ varchar ( 3 2 ) NOT NULL,
PRIMARY KEY ( ‘ s i g l a ‘ )
) ENGINE=InnoDB DEFAULT CHARSET=l a t i n 1 COMMENT= ’ E l e n c o d e l l e p r o v i n c e i t a l i a n e ’ ;
SET c h a r a c t e r s e t c l i e n t = @ s a v e d c s c l i e n t ;
−−
−− Dumping d a t a f o r t a b l e
−−
‘PROVINCIA‘
LOCK TABLES ‘PROVINCIA‘ WRITE;
/∗ ! 4 0 0 0 0 ALTER TABLE ‘PROVINCIA‘ DISABLE KEYS ∗/ ;
/∗ ! 4 0 0 0 0 ALTER TABLE ‘PROVINCIA‘ ENABLE KEYS ∗/ ;
UNLOCK TABLES ;
−−
−− T a b l e s t r u c t u r e f o r t a b l e
−−
‘RUOLO‘
DROP TABLE IF EXISTS ‘RUOLO‘ ;
SET @ s a v e d c s c l i e n t
= @@character set client ;
SET c h a r a c t e r s e t c l i e n t = u t f 8 ;
CREATE TABLE ‘RUOLO‘ (
‘ i d s g e ‘ char ( 6 ) NOT NULL COMMENT ’ Co di c e IDSGE ’ ,
67
‘ s i s a ‘ char ( 6 ) NOT NULL COMMENT ’ Co di c e SISA ’ ,
‘ d a t a i n i z i o ‘ date NOT NULL COMMENT ’ Data d i i n i z i o d e l r u o l o ’ ,
‘ d a t a f i n e ‘ date default NULL COMMENT ’ Data d i t e r m i n a z i o n e d e l r u o l o ’ ,
‘ c o d r u o l o ‘ char ( 2 ) NOT NULL COMMENT ’ C odi c e d e l r u o l o ’ ,
‘ p r o f i l o ‘ char ( 2 ) NOT NULL COMMENT ’ P r o f i l o ’ ,
‘ s t a t o r u o l o ‘ char ( 2 ) NOT NULL COMMENT ’ S t a t o r u o l o ’ ,
‘ c a r r i e r a ‘ char ( 6 ) NOT NULL COMMENT ’ C a r r i e r a u n i v e r s i t a r i a ’ ,
‘ i n c a r i c h i ‘ char ( 2 ) NOT NULL COMMENT ’ I n c a r i c h i ’ ,
‘ a r e e ‘ char ( 2 ) NOT NULL COMMENT ’ Area d i d a t t i c a ’ ,
‘ s e t t o r e ‘ char ( 2 ) NOT NULL COMMENT ’ S e t t o r e d i d a t t i c o ’ ,
‘ d i p a r t i m e n t o ‘ char ( 2 ) NOT NULL COMMENT ’ D i p a r t i m e n t o d i a p p a r t e n e n z a ’ ,
‘ s e r v i z i o ‘ char ( 2 ) NOT NULL COMMENT ’ S e r v i z i o ’ ,
‘ s e z i o n e ‘ char ( 2 ) NOT NULL COMMENT ’ S e z i o n e ’ ,
‘ i d e n t i t a ‘ varchar ( 3 2 ) NOT NULL COMMENT ’ I d e n t i t a ’ ,
PRIMARY KEY ( ‘ i d s g e ‘ ) ,
KEY ‘ n e w f k c o n s t r a i n t 1 0 ‘ ( ‘ c o d r u o l o ‘ ) ,
KEY ‘ n e w f k c o n s t r a i n t 1 1 ‘ ( ‘ p r o f i l o ‘ ) ,
KEY ‘ n e w f k c o n s t r a i n t 1 2 ‘ ( ‘ s t a t o r u o l o ‘ ) ,
KEY ‘ n e w f k c o n s t r a i n t 1 4 ‘ ( ‘ c a r r i e r a ‘ ) ,
KEY ‘ n e w f k c o n s t r a i n t 1 5 ‘ ( ‘ i n c a r i c h i ‘ ) ,
KEY ‘ n e w f k c o n s t r a i n t 1 6 ‘ ( ‘ a r e e ‘ ) ,
KEY ‘ n e w f k c o n s t r a i n t 1 7 ‘ ( ‘ s e t t o r e ‘ ) ,
KEY ‘ n e w f k c o n s t r a i n t 1 8 ‘ ( ‘ d i p a r t i m e n t o ‘ ) ,
KEY ‘ n e w f k c o n s t r a i n t 1 9 ‘ ( ‘ s e r v i z i o ‘ ) ,
KEY ‘ n e w f k c o n s t r a i n t 3 0 ‘ ( ‘ i d e n t i t a ‘ ) ,
CONSTRAINT ‘ n e w f k c o n s t r a i n t 3 0 ‘ FOREIGN KEY ( ‘ i d e n t i t a ‘ )
REFERENCES ‘IDENTITA ‘ ( ‘ i d i d e n t i t a ‘ ) ,
CONSTRAINT ‘ n e w f k c o n s t r a i n t 1 0 ‘ FOREIGN KEY ( ‘ c o d r u o l o ‘ )
REFERENCES ‘CODICE RUOLO‘ ( ‘ s i g l a ‘ ) ,
CONSTRAINT ‘ n e w f k c o n s t r a i n t 1 1 ‘ FOREIGN KEY ( ‘ p r o f i l o ‘ )
REFERENCES ‘PROFILO‘ ( ‘ s i g l a ‘ ) ,
CONSTRAINT ‘ n e w f k c o n s t r a i n t 1 2 ‘ FOREIGN KEY ( ‘ s t a t o r u o l o ‘ )
REFERENCES ‘STATI RUOLO‘ ( ‘ s i g l a ‘ ) ,
CONSTRAINT ‘ n e w f k c o n s t r a i n t 1 4 ‘ FOREIGN KEY ( ‘ c a r r i e r a ‘ )
REFERENCES ‘CARRIERA‘ ( ‘ m a t r i c o l a ‘ ) ,
CONSTRAINT ‘ n e w f k c o n s t r a i n t 1 5 ‘ FOREIGN KEY ( ‘ i n c a r i c h i ‘ )
REFERENCES ‘ INCARICHI ‘ ( ‘ s i g l a ‘ ) ,
CONSTRAINT ‘ n e w f k c o n s t r a i n t 1 6 ‘ FOREIGN KEY ( ‘ a r e e ‘ )
REFERENCES ‘AREA‘ ( ‘ s i g l a ‘ ) ,
CONSTRAINT ‘ n e w f k c o n s t r a i n t 1 7 ‘ FOREIGN KEY ( ‘ s e t t o r e ‘ )
REFERENCES ‘SETTORI‘ ( ‘ s i g l a ‘ ) ,
CONSTRAINT ‘ n e w f k c o n s t r a i n t 1 8 ‘ FOREIGN KEY ( ‘ d i p a r t i m e n t o ‘ )
REFERENCES ‘DIPARTIMENTI‘ ( ‘ s i g l a ‘ ) ,
CONSTRAINT ‘ n e w f k c o n s t r a i n t 1 9 ‘ FOREIGN KEY ( ‘ s e r v i z i o ‘ )
REFERENCES ‘ SERVIZIO ‘ ( ‘ s i g l a ‘ )
) ENGINE=InnoDB DEFAULT CHARSET=l a t i n 1
COMMENT= ’ R u o l i r i c o p e r t i a l l i n t e r n o d e l l u n i v e r s i t a ’ ;
SET c h a r a c t e r s e t c l i e n t = @ s a v e d c s c l i e n t ;
−−
−− Dumping d a t a f o r t a b l e
‘RUOLO‘
68
−−
LOCK TABLES ‘RUOLO‘ WRITE;
/∗ ! 4 0 0 0 0 ALTER TABLE ‘RUOLO‘ DISABLE KEYS ∗/ ;
/∗ ! 4 0 0 0 0 ALTER TABLE ‘RUOLO‘ ENABLE KEYS ∗/ ;
UNLOCK TABLES ;
−−
−− T a b l e s t r u c t u r e f o r t a b l e
−−
‘ SEDI ‘
DROP TABLE IF EXISTS ‘ SEDI ‘ ;
= @@character set client ;
SET @ s a v e d c s c l i e n t
SET c h a r a c t e r s e t c l i e n t = u t f 8 ;
CREATE TABLE ‘ SEDI ‘ (
‘ c o d i c e ‘ char ( 6 ) NOT NULL COMMENT ’ Co di c e a 6 c i f r e d e l l e s e d i ’ ,
‘ d e s c r i z i o n e ‘ varchar ( 3 2 ) NOT NULL COMMENT ’ D e s c r i z i o n e p e r e s t e s o ’ ,
‘ i n d i r i z z o ‘ varchar ( 6 4 ) NOT NULL COMMENT ’ I n d i r i z z o d e l l a s e d e ’ ,
PRIMARY KEY ( ‘ c o d i c e ‘ )
) ENGINE=InnoDB DEFAULT CHARSET=l a t i n 1 COMMENT= ’ S e d i d e l l U n i v e r s i t a d i Parma ’ ;
SET c h a r a c t e r s e t c l i e n t = @ s a v e d c s c l i e n t ;
−−
−− Dumping d a t a f o r t a b l e
−−
‘ SEDI ‘
LOCK TABLES ‘ SEDI ‘ WRITE;
/∗ ! 4 0 0 0 0 ALTER TABLE ‘ SEDI ‘ DISABLE KEYS ∗/ ;
/∗ ! 4 0 0 0 0 ALTER TABLE ‘ SEDI ‘ ENABLE KEYS ∗/ ;
UNLOCK TABLES ;
−−
−− T a b l e s t r u c t u r e f o r t a b l e
−−
‘SERVIZIO ‘
DROP TABLE IF EXISTS ‘ SERVIZIO ‘ ;
= @@character set client ;
SET @ s a v e d c s c l i e n t
SET c h a r a c t e r s e t c l i e n t = u t f 8 ;
CREATE TABLE ‘ SERVIZIO ‘ (
‘ s i g l a ‘ char ( 2 ) NOT NULL COMMENT ’ Co di c e p e r i l s e r v i z i o ’ ,
‘ nome ‘ varchar ( 3 2 ) NOT NULL COMMENT ’ D e s c r i z i o n e p e r e s t e s o ’ ,
‘ s e d e s e r v i z i o ‘ char ( 6 ) NOT NULL COMMENT ’ Sede d e l s e r v i z i o ’ ,
PRIMARY KEY ( ‘ s i g l a ‘ ) ,
KEY ‘ n e w f k c o n s t r a i n t 8 ‘ ( ‘ s e d e s e r v i z i o ‘ ) ,
CONSTRAINT ‘ n e w f k c o n s t r a i n t 8 ‘ FOREIGN KEY ( ‘ s e d e s e r v i z i o ‘ )
REFERENCES ‘ SEDI ‘ ( ‘ c o d i c e ‘ )
) ENGINE=InnoDB DEFAULT CHARSET=l a t i n 1 COMMENT= ’ S e r v i z i ’ ;
SET c h a r a c t e r s e t c l i e n t = @ s a v e d c s c l i e n t ;
−−
−− Dumping d a t a f o r t a b l e
‘SERVIZIO ‘
69
−−
LOCK TABLES ‘ SERVIZIO ‘ WRITE;
/∗ ! 4 0 0 0 0 ALTER TABLE ‘SERVIZIO ‘ DISABLE KEYS ∗/ ;
/∗ ! 4 0 0 0 0 ALTER TABLE ‘SERVIZIO ‘ ENABLE KEYS ∗/ ;
UNLOCK TABLES ;
−−
−− T a b l e s t r u c t u r e f o r t a b l e
−−
‘SETTORI‘
DROP TABLE IF EXISTS ‘SETTORI ‘ ;
= @@character set client ;
SET @ s a v e d c s c l i e n t
SET c h a r a c t e r s e t c l i e n t = u t f 8 ;
CREATE TABLE ‘SETTORI‘ (
‘ s i g l a ‘ char ( 2 ) NOT NULL COMMENT ’ Co di c e d e l s e t t o r e ’ ,
‘ nome ‘ varchar ( 3 2 ) NOT NULL COMMENT ’ D e s c r i z i o n e p e r e s t e s o ’ ,
PRIMARY KEY ( ‘ s i g l a ‘ )
) ENGINE=InnoDB DEFAULT CHARSET=l a t i n 1 COMMENT= ’ S e t t o r i d i d a t t i c i ’ ;
SET c h a r a c t e r s e t c l i e n t = @ s a v e d c s c l i e n t ;
−−
−− Dumping d a t a f o r t a b l e
−−
‘SETTORI‘
LOCK TABLES ‘SETTORI‘ WRITE;
/∗ ! 4 0 0 0 0 ALTER TABLE ‘SETTORI‘ DISABLE KEYS ∗/ ;
/∗ ! 4 0 0 0 0 ALTER TABLE ‘SETTORI‘ ENABLE KEYS ∗/ ;
UNLOCK TABLES ;
−−
−− T a b l e s t r u c t u r e f o r t a b l e
−−
‘SEZIONE‘
DROP TABLE IF EXISTS ‘SEZIONE ‘ ;
SET @ s a v e d c s c l i e n t
= @@character set client ;
SET c h a r a c t e r s e t c l i e n t = u t f 8 ;
CREATE TABLE ‘SEZIONE ‘ (
‘ s i g l a ‘ char ( 2 ) NOT NULL COMMENT ’ Co di c e p e r l e s e z i o n i ’ ,
‘ nome ‘ varchar ( 3 2 ) NOT NULL COMMENT ’ D e s c r i z i o n e p e r e s t e s o ’ ,
‘ s e d e s e z i o n e ‘ char ( 6 ) default NULL COMMENT ’ Sede d e l l a s e z i o n e ’ ,
KEY ‘ n e w f k c o n s t r a i n t 9 ‘ ( ‘ s e d e s e z i o n e ‘ ) ,
CONSTRAINT ‘ n e w f k c o n s t r a i n t 9 ‘ FOREIGN KEY ( ‘ s e d e s e z i o n e ‘ )
REFERENCES ‘ SEDI ‘ ( ‘ c o d i c e ‘ )
) ENGINE=InnoDB DEFAULT CHARSET=l a t i n 1 COMMENT= ’ S e z i o n i ’ ;
SET c h a r a c t e r s e t c l i e n t = @ s a v e d c s c l i e n t ;
−−
−− Dumping d a t a f o r t a b l e
−−
‘SEZIONE‘
70
LOCK TABLES ‘SEZIONE ‘ WRITE;
/∗ ! 4 0 0 0 0 ALTER TABLE ‘SEZIONE‘ DISABLE KEYS ∗/ ;
/∗ ! 4 0 0 0 0 ALTER TABLE ‘SEZIONE‘ ENABLE KEYS ∗/ ;
UNLOCK TABLES ;
−−
−− T a b l e s t r u c t u r e f o r t a b l e
−−
‘STATI RUOLO‘
DROP TABLE IF EXISTS ‘STATI RUOLO ‘ ;
SET @ s a v e d c s c l i e n t
= @@character set client ;
SET c h a r a c t e r s e t c l i e n t = u t f 8 ;
CREATE TABLE ‘STATI RUOLO‘ (
‘ s i g l a ‘ char ( 2 ) NOT NULL COMMENT ’ Co di c e d e l l o s t a t o d e l r u o l o ’ ,
‘ nome ‘ char ( 3 2 ) NOT NULL COMMENT ’ D e s c r i z i o n e p e r e s t e s o ’ ,
PRIMARY KEY ( ‘ s i g l a ‘ )
) ENGINE=InnoDB DEFAULT CHARSET=l a t i n 1 COMMENT= ’ S t a t i d e l r u o l o ’ ;
SET c h a r a c t e r s e t c l i e n t = @ s a v e d c s c l i e n t ;
−−
−− Dumping d a t a f o r t a b l e
−−
‘STATI RUOLO‘
LOCK TABLES ‘STATI RUOLO‘ WRITE;
/∗ ! 4 0 0 0 0 ALTER TABLE ‘STATI RUOLO‘ DISABLE KEYS ∗/ ;
/∗ ! 4 0 0 0 0 ALTER TABLE ‘STATI RUOLO‘ ENABLE KEYS ∗/ ;
UNLOCK TABLES ;
−−
−− T a b l e s t r u c t u r e f o r t a b l e
−−
‘STATO‘
DROP TABLE IF EXISTS ‘STATO‘ ;
= @@character set client ;
SET @ s a v e d c s c l i e n t
SET c h a r a c t e r s e t c l i e n t = u t f 8 ;
CREATE TABLE ‘STATO‘ (
‘ nome ‘ varchar ( 3 2 ) NOT NULL COMMENT ’ ’ ’Nome p e r e s t e s o ’ ’ ’ ,
‘ c o d i c e 2 ‘ char ( 2 ) NOT NULL COMMENT ’ ’ ’ Co di ce a 2 c a r a t t e r i ’ ’ ’ ,
‘ c o d i c e 3 ‘ char ( 3 ) NOT NULL COMMENT ’ ’ ’ Co di ce a 3 c a r a t t e r i ’ ’ ’ ,
‘ codice IANA ‘ char ( 3 ) NOT NULL COMMENT ’ ’ ’ Co di ce IANA ’ ’ ’ ,
‘ codice ISTAT ‘ char ( 3 ) NOT NULL COMMENT ’ ’ ’ Co di ce ISTAT ’ ’ ’ ,
‘ c o d i c e a g e n z i a e n t r a t e ‘ char ( 3 ) NOT NULL
COMMENT ’ ’ ’ Co di ce d e l l ’ ’ A g e n z i e d e l l e E n t r a t e ’ ’ ’ ,
PRIMARY KEY ( ‘ nome ‘ )
) ENGINE=InnoDB DEFAULT CHARSET=l a t i n 1 COMMENT= ’ S t a t i s o v r a n i ’ ;
SET c h a r a c t e r s e t c l i e n t = @ s a v e d c s c l i e n t ;
−−
−− Dumping d a t a f o r t a b l e
−−
‘STATO‘
71
LOCK TABLES ‘STATO‘ WRITE;
/∗ ! 4 0 0 0 0 ALTER TABLE ‘STATO‘ DISABLE KEYS ∗/ ;
/∗ ! 4 0 0 0 0 ALTER TABLE ‘STATO‘ ENABLE KEYS ∗/ ;
UNLOCK TABLES ;
−−
−− T a b l e s t r u c t u r e f o r t a b l e
−−
‘TIPO CORSO‘
DROP TABLE IF EXISTS ‘TIPO CORSO ‘ ;
SET @ s a v e d c s c l i e n t
= @@character set client ;
SET c h a r a c t e r s e t c l i e n t = u t f 8 ;
CREATE TABLE ‘TIPO CORSO‘ (
‘ c o d i c e ‘ char ( 2 ) NOT NULL COMMENT ’ Co di c e a 2 c a r a t t e r i ’ ,
‘ nome ‘ varchar ( 3 2 ) NOT NULL COMMENT ’ Tipo p e r e s t e s o ’ ,
PRIMARY KEY ( ‘ c o d i c e ‘ )
) ENGINE=InnoDB DEFAULT CHARSET=l a t i n 1 COMMENT= ’ Tipo d i c o r s o d i l a u r e a ’ ;
SET c h a r a c t e r s e t c l i e n t = @ s a v e d c s c l i e n t ;
−−
−− Dumping d a t a f o r t a b l e
−−
‘TIPO CORSO‘
LOCK TABLES ‘TIPO CORSO‘ WRITE;
/∗ ! 4 0 0 0 0 ALTER TABLE ‘TIPO CORSO‘ DISABLE KEYS ∗/ ;
/∗ ! 4 0 0 0 0 ALTER TABLE ‘TIPO CORSO‘ ENABLE KEYS ∗/ ;
UNLOCK TABLES ;
−−
−− T a b l e s t r u c t u r e f o r t a b l e
−−
‘TITOLO ONORIFICO‘
DROP TABLE IF EXISTS ‘TITOLO ONORIFICO ‘ ;
= @@character set client ;
SET @ s a v e d c s c l i e n t
SET c h a r a c t e r s e t c l i e n t = u t f 8 ;
CREATE TABLE ‘TITOLO ONORIFICO‘ (
‘ c o d i c e ‘ i n t ( 1 1 ) NOT NULL COMMENT ’ Co di c e numerico i n c r e m e n t a l e ’ ,
‘ nome ‘ varchar ( 3 2 ) NOT NULL COMMENT ’Nome d e l t i t o l o o n o r i f i c o ’ ,
PRIMARY KEY ( ‘ c o d i c e ‘ )
) ENGINE=InnoDB DEFAULT CHARSET=l a t i n 1
COMMENT= ’ T i t o l o o n o r i f i c o d e l l e I d e n t i t a ’ ;
SET c h a r a c t e r s e t c l i e n t = @ s a v e d c s c l i e n t ;
−−
−− Dumping d a t a f o r t a b l e
−−
‘TITOLO ONORIFICO‘
LOCK TABLES ‘TITOLO ONORIFICO‘ WRITE;
/∗ ! 4 0 0 0 0 ALTER TABLE ‘TITOLO ONORIFICO‘ DISABLE KEYS ∗/ ;
/∗ ! 4 0 0 0 0 ALTER TABLE ‘TITOLO ONORIFICO‘ ENABLE KEYS ∗/ ;
UNLOCK TABLES ;
72
/∗ ! 4 0 1 0 3 SET TIME ZONE=@OLD TIME ZONE ∗/ ;
/∗ ! 4 0 1 0 1
/∗ ! 4 0 0 1 4
/∗ ! 4 0 0 1 4
/∗ ! 4 0 1 0 1
/∗ ! 4 0 1 0 1
/∗ ! 4 0 1 0 1
/∗ ! 4 0 1 1 1
SET
SET
SET
SET
SET
SET
SET
SQL MODE=@OLD SQL MODE ∗/ ;
FOREIGN KEY CHECKS=@OLD FOREIGN KEY CHECKS ∗/ ;
UNIQUE CHECKS=@OLD UNIQUE CHECKS ∗/ ;
CHARACTER SET CLIENT=@OLD CHARACTER SET CLIENT ∗/ ;
CHARACTER SET RESULTS=@OLD CHARACTER SET RESULTS ∗/ ;
COLLATION CONNECTION=@OLD COLLATION CONNECTION ∗/ ;
SQL NOTES=@OLD SQL NOTES ∗/ ;
−− Dump c o m p l e t e d on 2009−02−03 1 6 : 3 2 : 2 2
73
Appendice C
Istruzioni per importare il
database dallo script
Per provare il DB (attraverso il dump dell’appendice B è ovviamente necessario innanzitutto scaricare 1 ed installare MySQL (sulla macchina in cui è stato provato, con sistema
operativo Ubuntu 8.10, la procedura è veramente banale2 ) e successivamente da shell
digitare:
• se vogliamo cancellare un precedente database con lo stesso nome:
mysqladmin drop unipr -u root -p
• importare quindi il database:
mysql unipr -u root -p < nome_del_file_dump.sql
1
All’indirizzo http://dev.mysql.com/downloads/mysql/5.1.html sono presenti i download per la
versione 5.1 di MySQL
2
Basta difatti installare il pacchetto mysql-server
74
Bibliografia
[1] Marco Atzeni, Stefano Ceri, Stefano Paraboschi, and Riccardo Torlone. Basi di dati
- Modelli e linguaggi di interrogazione. McGraw-Hill, 2002.
[2] Nello Coppeto. Dbms a confronto: panoramiche sui diversi scenari di sviluppo dei
server database, 2007.
[3] Giulio Destri. Introduzione ai sistemi informativi aziendali. Monte Università
Parma Editore, 2007.
[4] Maria Laura Mantovani. Identificazione delle persone. http://wiki.unimore.it/
mediawiki/index.php/Identificazione_delle_persone.
[5] Maria Laura Mantovani.
Identity and access management.
marialaura.
[email protected].
[6] Microsoft. Serie microsoft gestione di identità e accessi. http://www.microsoft.
com/italy/technet/security/topics/identity/p1fund_4.mspx.
[7] Marco Panella. Identity and access management (iam) e authentication and authorization infrastructure (aai) in ambiente federato. www.siti.unipr.it/?download=
IAM_AAI_20080512.ppt.
[8] Avi Silberschatz. Database System Concepts. McGraw-Hill, 2006.
[9] Wikipedia. Identity management. http://en.wikipedia.org/wiki/Identity_
management.
[10] Wikipedia. Web service. http://it.wikipedia.org/wiki/Web_service.
75