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 42.1 IAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.2 Identita e ciclo di vita delle Identita . . . . . . . . . . . . . . . . . . . . . 9
2.2.1 Identita . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.2.2 Ciclo di vita delle Identita . . . . . . . . . . . . . . . . . . . . . . . 10
2.3 Implementare un server IAM . . . . . . . . . . . . . . . . . . . . . . . . . 132.3.1 LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.3.2 Database e DBMS . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3 Vincoli progettuali 193.1 Il contesto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.1.1 Fonti: situazione attuale . . . . . . . . . . . . . . . . . . . . . . . . 193.1.2 Identita: situazione attuale . . . . . . . . . . . . . . . . . . . . . . 223.1.3 Risorse disponibili agli utenti . . . . . . . . . . . . . . . . . . . . . 24
3.2 Attuale gestione delle identita e degli accessi . . . . . . . . . . . . . . . . 253.2.1 Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263.2.2 Problematiche della gestione attuale . . . . . . . . . . . . . . . . . 26
3.3 Sicurezza, coerenza e affidabilita . . . . . . . . . . . . . . . . . . . . . . . 27
4 Progetto 304.1 Progetto logico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314.2 Architettura generale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324.3 Fonti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.3.1 DBMS scelto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344.3.2 Database unificato . . . . . . . . . . . . . . . . . . . . . . . . . . . 344.3.3 La gestione delle figure esterne all’Universita . . . . . . . . . . . . 394.3.4 Sicurezza nel trattamento dei dati . . . . . . . . . . . . . . . . . . 42
4.4 Identita unica e ciclo di vita dell’identita . . . . . . . . . . . . . . . . . . 504.5 Dati da replicare sul server LDAP . . . . . . . . . . . . . . . . . . . . . . 53
1
5 Conclusioni 565.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 Iden-tity and Access Management di Ateneo.
Questa tesi e parte costituente dello studio intero di un progetto di Identity and Ac-cess Management dell’Universita di Parma, ma ne approfondisce appunto solo l’aspettorelativo alla gestione delle Identita.
L’obbiettivo in sintesi di tale progetto e quello di uniformare gli accessi ai servizi of-ferti dall’Universita di Parma, in modo da evitare il proliferare di account diversi perogni funzionalita offerta, semplificando notevolmente la vita agli utenti che dei servizine fanno uso ogni giorno.
Per Identity and Access Management si intende (a grandi linee) un sistema hard-ware e software che gestisce gli accessi (ovvero la possibilita di entrare o meno e conquali privilegi) a un sistema informativo e in modo particolare ai servizi che tale sistemaoffre. Si dovra arrivare ad una situazione nella quale ogni utente sara presente una eduna sola volta nel sistema (diventando quindi a tutti gli effetti una identita digitale) econ tali credenziali (sempre le stesse) potra accedere a ogni servizio (secondo le possi-bilita che i sui ruoli all’interno dell’universita gli consentono).Quindi in questa tesi verra posta l’attenzione solamente sulle problematiche dell’ Iden-
tity Management, tralasciando invece l’Access Management.
3
Capitolo 2
Introduzione
In questo capitolo verranno introdotti, dal punto di vista teorico, tutti gli aspetti anal-izzati al momento del progetto, ovvero tutti quei principi fondamentali dell’IdentityManagement (e quelli piu significativi dell’Access Management).
2.1 IAM
Il problema del riconoscimento dell’utente e dell’attribuzione dei relativi permessi e unproblema tipico di tutte quelle situazioni in cui vengono forniti particolari servizi infor-matici (servizi WEB, servizi di accesso a Internet, servizi di accesso a terminali Linux eWindows, 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’accessoalle risorse aziendali.
Esistono due situazioni estreme a tale problematica [7]:
• ogni applicazione (fornitrice del servizio) gestisce gli accessi e le autorizzazioni aipropri servizi in modo autonomo
• centralizzazione degli accessi e delle autorizzazioni
4
Nella prima situazione ad ogni applicazione che gestisce un servizio compete inoltretutto il sistema di management degli accessi e delle identita.
Figura 2.1: Sistema di gestione degli accessi e delle autorizzazioni lasciato alleapplicazioni
Ad ogni credenziale corrisponde un insieme di permessi che l’utente possiede o menoall’interno dei vari servizi. In questo caso l’utente ha credenziali diverse per applicazionidiverse pur rivestendo lo stesso ruolo e diverse per la stessa applicazione se riveste piuruoli 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 permessiconcessi erroneamente
• maggior insicurezza delle credenziali e quindi maggior vulnerabilita delle appli-cazioni
• maggior difficolta nell’aggiungere nuovi servizi o modificare privilegi che possonoavere dei ruoli
5
Questo schema e stato sostituito successivamente dall’implementazione del sistemain cui ogni utente ha un identificativo personale ed il sistema conosce, tramite il supportodi una apposita base di dati, la mappa dei ruoli ricoperti da ciascun utente.
Questa soluzione razionalizza e gestisce le procedure di autenticazione e autoriz-zazione tra un utente e i servizi forniti dalla sua organizzazione; in questo ambiente,la funzione di attribuzione dei permessi dell’applicazione viene sviluppata prendendo ariferimento la base dei dati dei ruoli: nel momento in cui l’utente si collega e si auten-tica vengono estrapolati i ruoli registrati per il suo identificativo; questi ruoli vengonoutilizzati per filtrare gli accessi oppure, per ciascun ruolo, vengono assegnati un insiemedi privilegi che, uniti, garantiscono l’accesso alle singole caratteristiche.Quindi il tutto diviene centralizzato in un unico sistema (indicativamente composto daun unico Database e da un sistema LDAP) detto sistema IAM (o server IAM), alquale le applicazioni si interfacciano in modo trasparente, e che quindi gestisce gli ac-
cessi, 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 inoltrebenefici 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 diquesto tipo? 1
• analizzare i Database (ovvero le varie fonti da cui provendono i dati) esistenti evedere quali sono autoritativi
• decidere quali informazioni prendere, mantenere ed eventualmente aggiungere
• consolidare (una persona puo essere presente in piu fonti) per creare quella chechiamiamo identita digitale 2
• tenere aggiornato automaticamente il database unificato
Si tratta quindi di centralizzare (dove necessario) le fonti in modo tale da crearequelle 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 ag-giungere un nuovo servizio, oppure modificare i privilegi di accesso ad un gruppodi servizi)
• l’evoluzione dei requisiti si riflette nei cambiamenti che devono essere fatti solo inun 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 30per cento
• le decisioni prese si applicano in un punto e si vedono i risultati e le conseguenzedelle decisioni stesse
• il logging e consolidato pertanto si possono applicare regole di privacy, di conser-vazione dei dati di auditing, si possono fare dei report, si monitora la sicurezza inmodo efficace
• eliminato il problema del Deprovisioning (disattivazione) relativo alla gestione delleidentita in sistemi disgiunti
• ridotto il numero di credenziali da conoscere da parte dell’ utente1Per maggiori dettagli consultare [5]2Questo e un passo cruciale dell’Identity Management3Consultare per maggiori informazioni http://www.educause.edu
7
• l’organizzazione puo modificare piu velocemente i diritti di accesso basandosi suiruoli
• nel processo di garantire che una persona e “quello che dice di essere” l’istituzioneincrementa 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 dellagestione dell’autenticazione e degli accessi e ancora lasciata (in maggior parte) alle varieapplicazioni che gestiscono i servizi offerti.Inoltre la gestione dell’Identita, allo stato attuale, ha molti difetti ed e ben lontana dallasituazione 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 Man-agement, che si occupa dello studio e della gestione dell’ Identita e soprattutto del ciclodi 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 riconosciutae alla quale possono essere associati diversi ruoli; quindi e l’insieme delle informazioniche caratterizzano un utente ovvero quelle informazioni relative alla identita e ai diversiruoli 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 peruna corretta identificazione dell’utente
– attributi riguardanti il ruolo (o i ruoli ricoperti) all’interno del sistema (ades. per gli studenti potrebbe interessare il corso di laurea, per i docenti ildipartimento di afferenza)
– attributi necessari per l’accesso alle risorse (ad es. username e password) dettianche credenziali
• ruoli, ovvero funzioni che gli utenti ricoprono nel sistema (ad es. studenti, docentie incarichi dinamici4) ai quali derivano dei privilegi 5
Come si puo facilmente intuire gli elementi costitutivi di un identita sono profonda-mente legati tra di loro: avere dei ruoli all’interno di un sistema comporta inevitabilmenteprivilegi specifici nell’accesso alle risorse e quindi attributi specifici necessari per i ruoliricoperti.
Tornando alla definizione data in precedenza di identita ha un certo rilievo il termineunica, che sta a significare che una persona non puo essere presente nel sistema se nonsolo sotto forma di una sola identita.
4Per quel che riguarda una situzione universitaria quando ad esempio si creano dei gruppi di lavorolegati ad un progetto
5Ovvero le possibilita di accedere alle risorse che il sistema mette a disposizione (ad es. la possibilitadi 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 creden-ziali) ma soprattutto da parte del sistema comporterebbe una disastrosa gestione delleinformazioni 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 diquell’utente).Diviene quindi fondamentale trovare un gruppo di attributi che da soli possano identi-ficare senza ambiguita ogni identita, in modo da potersi riferire a tale identita sempreattraverso 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, edin 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’in-terno del sistema)
10
Figura 2.4: Ciclo di vita dell’identita
• modifiche degli attributi a causa di promozioni, trasferimenti o in generale cambiodi 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 delIdentity LifeCycle Management.
Quindi la gestione del ciclo di vita delle identita comprende i processi e le tecnolo-gie che consentono l’implementazione, l’annullamento dell’implementazione, la gestionee la sincronizzazione di identita digitali e conformi ai criteri governativi. La riuscita dellagestione di identita e accessi si basa soprattutto sull’efficienza della gestione del ciclo divita delle identita digitali [6].I servizi di gestione del ciclo di vita delle identita consentono la creazione di identita diprotezione, 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 controllocompleto.
Esistono tre prospettive dalle quali possiamo analizzare il processo di gestione dell’Identita[9]:
• paradigma rivolto all’Identita (The pure identity paradigm): creazione, gestione ecancellazione delle identita senza considerare gli accessi alle risorse
• paradigma rivolto all’accesso alle risorse (The user access paradigm): ad esempiouna 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 principiassiomatici; 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, nelsenso che tale modello non e vincolato dal contesto nel quale e applicato. Un pure identitymodel non e strettamente legato con la semantica degli attributi delle identita e l’Identitymanagement puo essere definito come un insieme di operazioni su un modello astrattodell’Identita. In pratica, identity management e usato per esprimere come l’informazionedell’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 processibusiness, politiche e tecnologie che facilitano l’organizzazione a controllare gli accessialle risorse. Rappresenta una categoria di soluzioni nelle quali gli amministratori disistema si impiegano verso la gestione dell’autenticazione degli utenti, diritti di accessoe le restrizioni, i profili delgli account, le passwords, e tutti gli altri attributi riguardantii ruoli in relazione alle applicazioni (ovvero ai privilegi).
The service paradigm
In questo paradigma, nel quale le organizzazioni evolvono i loro sistemi nel mondo diservizi convergenti, l’ambito dell’ identity management diviene piu ampio e la sua ap-plicazione nettamente piu critica. Difatti include tutte le risorse della organizzazioneutilizzate 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 acosa serve, vediamo ora e com’e possibile implementarlo realmente e attraverso qualistrumenti software.Ricordandoci che un server IAM e un sistema che permette di gestire le identita degliutenti in un unico punto centralizzato, ed al quale si rivolgono le risorse e i servizi (offertidal sistema) che fanno uso di queste informazioni, ad esempio per gestire autenticazionee 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 malfunziona-menti, guasti o incidenti, non vengano perse le informazioni memorizzate
• deve risulare sicuro, quindi deve avere una serie di meccanismi per assicurare chenon possa essere compromesso e che i dati mantenuti non possano essere accedutida persone non autorizzate
• deve essere indubbiamente performante nelle operazioni di lettura, poiche costi-tuiscono la maggior parte di operazioni che verrano effettuate su di esso
• deve essere possibile interfacciarlo, in modo relativamente semplice, con le tec-nologie di accesso che leggono le informazioni memorizzate, e con procedure auto-matiche 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, comesi vedra, sara possibile utilizzarli singolarmente per implementare un server IAM, mauna buona soluzione, come si potra vedere nel progetto puo essere quella di utilizzarlientrambi, in modo congiunto, per sfruttarne al meglio le caratteristiche.
2.3.1 LDAP
LDAP (Lightweight Directory Access Protocol) e sostanzialmente un protocollo di ges-tione e accesso a directory service. Un directory service (servizio di directory) e utilizzatoper associare nomi ad oggetti, dove ogni oggetto e caratterizzato da una serie di attributicostituiti da una coppia nome - insieme di valori.
13
I directory service sono ottimizzati per effettuare ricerche di oggetti, ricerche che possonoavvenire 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 incui viene utilizzato il servizio, per esempio un utente, un computer, una stampante o unarete, ed ogni oggetto conterra una serie di attributi che servono per descrivere cio cherappresenta (per quello visto in precedenza un Identita nel nostro caso). Una directorye quindi un insieme di oggetti, e un directory service e un servizio che ha lo scopo digestire gli oggetti di una directory ed effettuare ricerche su di essi.LDAP e strutturato attraverso uno schema costituito inoltre da attributi caratterizzantiil contenuto degli oggetti.
Perche LDAP
LDAP e un’ottima soluzione, ha notevoli vantaggi, e sempre piu diffuso e sta diventandoormai uno standard nella gestione centralizzata degli utenti.Per quanto riguarda le implementazioni di server LDAP, ne’ esistono diverse, fra quelleproprietarie ricordiamo DSEE (Directory Server Enterprise Edition) di SUN, eDirectorydi Novell e Active Directory di Microsoft, mentre le piu diffuse implementazioni liberesono 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, strut-turato 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 pa-role l’insieme organizzato di dati utilizzati per il supporto allo svolgimento di attivita [1].
Informalmente e impropriamente, la parola database viene spesso usata come ab-breviazione di Database Management System (DBMS), che si riferisce invece auna vasta categoria di sistemi software che consentono la creazione e la manipolazioneefficiente di database.
Esiste una sottile, ma da non sottovalutare, differenza tra dati ed informazioni ininformatica:i dati sono materiale informativo grezzo, non (ancora) elaborato, e memorizzato in unqualche modo;
14
al contrario l’informazione viene costruita dai dati elaborati cognitivamente cioe trasfor-mati in un qualche schema concettuale successivamente manipolabile e usabile per altriusi cognitivi [3].
L’importanza che i dati (e quindi le informazioni) vengano gestiti nel modo piu corret-to, efficace ed efficente possibile e ovviamente fondamentale per una qualunque societa,o in particolar modo per un’ Universita: essi rappresentano il passato (mantenendo unostorico), il presente (la gestione attuale dei processi business si basa sulla corretta ges-tione delle informazioni) ed ovviamente il futuro (le scelte future dipendono anche dallasituazione attuale e passata).
Panoramica tra i vari DBMS
In questo paragrafo verra proposta una carrellata tra quali siano oggi i DBMS presentisul mercato al fine di scegliere quello piu adatto al progetto.Questa non vuole essere una lista esaustiva e neppure un confronto completo tra le varieproposte 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 dovraquindi scegliere tra le molte licenze a disposizione. Esistono tre categorie di licenze cheOracle offre:
6Basato cioe sul concetto matematico di relazione
15
• Modalita d’uso: in questa categoria sono raccolte le licenze che limitano l’uso chel’utente puo fare del software Oracle. Ci sono tre sotto-categorie:
– le licenze Full Use permettono all’utente finale di utilizzare il software perqualsiasi tipo di applicazione
– la licenza ASFU (Application Specific Full Use) consente un utilizzo limitatodestinato ad un Partner Oracle per una singola e specifica Applicazione alloscopo di rivendita ad un utente finale determinato. Permette all’utente diutilizzare il software solo congiuntamente all’applicazione con cui e’ statovenduto
– le licenze Embedded (ESL) consentono un utilizzo limitato destinate ad unPartner Oracle Solution Provider per la vendita di una soluzione in cui il soft-ware Oracle e’ appunto Embedded, ovvero inserito all’interno nel pacchettoapplicativo fornito dal Partner
• Tipologia: in questa categoria sono raccolte le licenze che si basano sul sistemadell’utente finale.
– la licenza Named User Plus viene utilizzata negli ambienti dove il numero diutenti puo essere identificato e contato
– la licenza Processor e una licenza che si applica su ogni singolo processoreattuo a processare il software Oracle
• Scadenza della licenza: in questa categoria sono raccolte le licenze che pongonolimiti sul tempo di utilizzo del software. Ci sono tre sotto-categorie: A tempodeterminato, indeterminato e a tempo esteso.
MySQL invece dispone di una doppia licenza. Affiancata alla GPL troviamo infattila MySQL Commercial License.Questa permette di rilasciare le proprie modifiche con la licenza che si preferisce, senzaalcun vincolo. Quindi il problema della doppia licenza coinvolge solamente chi scrive unsoftware che si basa su MySQL.
PostGreSQL e rilasciato con la BSD License la quale e considerata una delle licenzepiu permissive.
Costi
Riguardo ai costi dei servizi di Oracle, nel seguito riporteremo alcuni esempi (in dollariamericani).
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 trai 3000 dollari e i 25000 dollari. Tutti questi prezzi sono relativi alla licenza Processorand Perpetual, questo significa che andranno applicati ad ogni singolo processore per unadurata di tempo illimitata. In caso si voglia installare questi software su piu macchinedunque 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 Release2, consente a chiunque di provare a costo zero tutte le funzionalita presenti in OracleDatabase 10g. La versione light di Oracle offre infatti gli stessi strumenti del fratellomaggiore, 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 unadimensione 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 loe Oracle, e proprio la sicurezza. Solo chi ha il sorgente puo modificare il software al finedi risolvere eventuali bug.Nel caso di Oracle, si e definito un record di inefficienza quando furono segnalati bugcritici da Alexander Kornbrust, CEO della tedesca Red-Database-Security Gmbh e so-lo dopo 650 giorni furono risolti e rilasciate le patch. Dalla Next Generation SecuritySoftware Ltd (Ngs), David Litchfield, uno dei bug hunter piu prolifici nel campo deidatabase, ha dimostrato inoltre la non piena efficienza delle patch rilasciate da Oracle.Molti analisti hanno evidenziato come Oracle tenti di migliorare la sicurezza dei propriprodotti insistendo sulla via del security through obscurity ad oltranza, anche nei con-fronti dei propri clienti, senza disporre pero di un piano di fondo per rendere i propriprodotti intrinsecamente sicuri.
17
Al contrario MySQL essendo un sistema aperto, e parzialmente libero, sfrutta la possi-bilita di analisi e rilascio di patch sia dalla community che segue lo sviluppo del codicesorgente del database sia dagli sviluppatori ufficiali. E garantita in questo modo un’elevata disponibilita al rilascio di patch e questo contribuisce sicuramente ad un incre-mento totale della sicurezza del DBMS.A maggior ragione PostgreSQL essendo in continuo sviluppo da parte della ricercauniversitaria di tutto il pianeta ha sicuramente dalla sua un gruppo di sviluppatori chesi 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 contornofondamentale 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 delsistema IAM centralizzato viene applicato, cioe quelle parti che non vengono modificatedal progetto, ma alle quale esso si riferisce.In particolare vengono illustrate le fonti, ovvero da dove provengono le informazionirelative 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 conun unica fonte dati centralizzata.Difatti la gestione quotidiana di una struttura come puo essere l’Universita di Parma sidiversifica in alcuni settori, gestiti da diverse segreterie e in conseguenza diverse fontedati.
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 dilavoro)
• 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 contrattoe 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 settorepost-laurea) e dottorandi (dal serivizio borse e dottorandi)
A questi vanno aggiunti le informazioni dei dipendenti ospedalieri che hanno accessoa servizi dell’Universita.
Da tutte queste diversificate fonti, attraverso vari sistemi (invio di files DBF o txt) eprocedure (php e perl principalmente), si inviano i dati ai Database e quindi al sistemaLDAP (presenti presso il SITI) che permettono l’accesso diversificato ai vari utenti chefanno richiesta dei serivizi. Non e presente nessun tipo di controllo sulle identita, quindiuna persona potrebbe essere tranquillamente presente in piu fonti e di conseguenza piuvolte 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 necessaria-mente la divisione dei doveri e dei diritti.In un ambiente Universitario, e nel caso specifico del sistema informativo e dei serviziche esso offre, questo di traduce in diversi privilegi che ogni ruolo possiede.Basti pensare per esempio cosa succederebbe se chiunque possa avere accesso (anchein scrittura) a fonti dati riguardanti i corsi di laurea o ancora peggio la gestione deglistipendi del personale.Distinguere e formalizzare il piu possibile i ruoli che avranno accesso al sistema aiutaquindi 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 consegui-mento di un titolo
• future matricole (coloro che ad esempio non sono riusciti ad entrare in corsi anumero 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 esaustivoperche non comprende (almeno in modo diretto) tutti quei casi misti ovvero di personeche ricoprono contemporaneamente piu ruoli (ad esempio il caso piu semplice di studentiche 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, perogni ruolo:
• studenti:
22
– creazione credenziali: la creazione delle credenziali avviene una volta che lostudente ha pagato la prima rata delle tasse e contestualmente all’inserimentodei dati in GISS.Successivamente una procedura batch estrae i dati dal database GISS e liinserisce in un file di testo di tipo CSV in cui sono contenuti tutti i datinecessari alla gestione dei servizi. Alcune procedure bash+perl in automaticogenerano il file ldif per popolare il server master LDAP
– modifica credenziali: gli studenti possono modificare autonomamente la pass-word 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 giaiscritti. Gli attributi sono modificati utilizzando delle procedure bash+perlsimili a quelle usate per la creazione
– cancellazione: la cessazione della casella di posta elettronica, due anni dopol’ultima iscrizione, non comporta la cancellazione dal server LDAP, ma sololo spostamento ad un altro ramo
• personale strutturato:
– creazione credenziali: o dati anagrafici sono inviati al Settore Innovazione Tec-nologie Informatiche dove sono generati gli indirizzi email seguendo il [email protected]
– modifica credenziali: gli utenti possono modificare autonomamente la pass-word attraverso una pagina web protetta da SSL. Le password scadono ogni180 giorni. Se l’utente dimentica la password o lascia passare 200 giornidall’ultimo cambio, il sistema non permette piu di accedere ai servizi e l’u-tente deve rivolgersi al Servizio Supporto al Settore Innovazione TecnologieInformatiche
– modifica attributi: tutti i mesi sono inviate le informazioni relative ai dipen-denti attivi. Per differenza con l’elenco del mese precedente, tramite proce-dure analoghe a quelle usate per la generazione degli account, il Settore Inno-vazione Tecnologie Informatiche modifica le informazioni relative a eventualitrasferimenti, promozioni, riassunzioni, ecc.
– cancellazione: per il momento non viene mai effettuata la cancellazione del-l’account del personale strutturato ma viene solo registrata la cessazionemodificando alcuni valore di attributi
23
• ditte esterne: per il momento non esiste la necessita di rilasciare delle credenzialia tutti i fornitori esterni in quanto tali.
• professori a contratto : per il momento, sono trattati come gli strutturati, ma iltrasferimento dei loro dati al Settore Innovazione Tecnologie Informatiche avvienecon evidente ritardo rispetto sia all’inizio del contratto sia, soprattutto, all’iniziodelle attivita didattiche (questo evidentemente e un limite di tale gestione del ciclodi vita)
• studenti esterni e future matricole : la gestione del loro ciclo di vita e tuttoraabbastanza lontana da essere una situazione ideale (ovviamente con una situazionepiu 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 diautenticazione e autorizzazione si possono suddividere in servizi web, servizi di rete
e postazioni computer. Per motivi di completezza (e ovviamente per dare idea dellaloro dimensione e importanza per utenti e per il sistema)vengono elencate le principalirisorse 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, Giurispruden-za, Ingegneria, Letteree Filosofia, Medici-na Veterinaria, ScienzePolitiche
Yagiss Comunicazione esami ascelta
Fac. Ingegneria
WebGISS Servizi diversi alla didat-tica: esenzione maggio-razione, ecc. (interfaccia alsistema informativo GISS)
Studenti iscritti e docentidell’Ateneo
CSAWeb Cedolini stipendiali Personale strutturato del-l’Ateneo
Er-GO Domande di benefici per ildiritto allo studio
Studenti iscritti dell’Ateneo
Campusnet Servizi diversi per la didatti-ca
Fac. Medicina e Chirurgia,Scienze MM.FF.NN.
Dspace Deposito delle tesi di dot-torato
Dottorandi dell’Ateneo
Dokeos o Moodle Sistemi di supporto alladidattica frontale
Corsi dell’Ateneo, sia perstudenti interni che esterni
Varie applicazioniinterne
Form per il Nucleo di Valu-tazione; catalogo delle Pub-blicazioni; ecc.
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 infor-mazioni degli utenti mantenute nei diversi database.I database servono quindi per mantenere i dati degli utenti che vengono prelevati dallefonti (come descritto nel paragrafo 3.1.1), mentre il server LDAP e utilizzato per renderedisponibili questi dati alle applicazioni.
25
3.2.1 Database
Nella figura 3.1 viene illustrato come le informazioni provenienti dalle fonti vengonoinserite nei database attraverso vari sistemi, come l’invio di files DBF o txt, e procedurephp e perl.I database mantenuti sono due: uno per gli studenti ed uno per il personale, il che echiaramente contro la logica di mantenere un’identita unica per ogni utente, basti infattipensare ad uno studente che diventa docente: in questo caso vengono creati due utentidistinti, uno nel database degli studenti ed uno nel database del personale.L’obiettivo del progetto e esattamente quello di evitare situazioni di questo genere ecreare una identita digitale unica per ogni persona.
3.2.2 Problematiche della gestione attuale
Mantenere piu database distinti comporta diversi problemi se vogliamo costruire unsistema dove gestire un’unica identita per ogni persona; difatti, se una persona ricopre piuruoli, come puo essere per un docente-studente, vengono mantenuti due utenti separatiper una stessa persona, rendendo impossibile realizzare l’obiettivo dell’identita digitaleunica.Lo sdoppiarsi possibile delle Identita implica una duplicazione della gestione del ciclo divita (ogni modifica andrebbe gestita due volte, sempre se si fosse a conoscenza di talesituazione, altrimenti si ci ritroverebbe in una situazione di incoerenza).Questo problema lo si risolvera progettando un database unico nel quale memorizzaree mantenere le informazioni degli utenti e le informazioni relative a tutti i ruoli da essiricoperti.
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 motivotralasciare l’analisi dettagliata delle problematiche riguardanti la sicurezza dei dati.La sicurezza dell’Identita, e di conseguenza delle sue caratteristiche (attributi, privile-gi...), e di vitale importanza per una struttura con molti utenti come lo e l’Universitadi 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 diDati.
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 datidando privilegi diversi)
• politiche di prevenzione
27
Con ridondanza intendiamo la replica dell’intero Database su supporti diversi (serv-er ubicati in luoghi differenti ad esempio) in modo da evitare danni irreparabili in casodi guasti, furti al Database originale.La replica comporta pero problematiche di coerenza dei dati: non e ammissibile che nellerepliche esistano dati non aggiornati; cio comporta la realizzazione di politiche di aggior-namento (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) discript 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 dapoter ricostruire i cambiamenti in caso di guasti
• politiche di backup: salvare il contenuto del Database (o di un sottoinsieme) susupporti diversificati riduce il richio di perdita dei dati
Un altro aspetto fondamentale della sicurezza dei dati riguarda la gestione delle op-erazioni sul Database; immaginiamo che durante una scrittura sul database ci sia unguasto alla rete. Cosa puo succedere nel Database? Le modifiche sono state apportatetutte o solo una parte?Se fosse cosı ci troveremmo di fronte ad uno stato non coerente perche non rappresen-terebbe la realta: diventa quindi fondamentale l’uso (da parte ad esempio dei servizi)delle transazioni, ovvero di operazioni atomiche, che permettono percio di passare dauno 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 apportateper 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 essereinfluenzata da altri cambiamenti di altre transazioni a lei concorrenti
• Durabilita: le modifiche apportate da una transazione rimangono anche dopodanni al database
Garantire percio che tutte le operazioni (che in altri termini gestiscono il ciclo divita) 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 copieaggiornate (ridondanza) e un controllo sicuro degli accessi garantisce che la Base di datie 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 sullescelte inerenti l’Identita (Database, ciclo di vita, sicurezza nel trattamento dei dati).Ipotizzando che la gestione degli accessi sia gia implementata (quindi anche lo schemadell’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 unpunto 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 lagestione del ciclo di vita dell’identita con un server IAM.Per quel che riguarda la creazione, le varie modifiche o la cancellazione riguardanti leidentita innanzitutto si verra a contatto con le varie fonti (diversificate come ora perruoli 1) prima di interagire (attraverso opportuni strumenti di sincronizzazione) con ilserver IAM.Quando un utente vorra accedere ad una risorsa, attraverso vari strumenti di autenti-cazione, vi potra accedere solo dopo che tale risorsa abbia gestito nel modo migliorel’accesso tramite il server IAM.Nei paragrafi successivi vedremo come tale server IAM verra implementato e quali sianole problematiche conseguenti a tale scelta.
1Non e pensabile di poter modificare le fonti poiche esse sono strettamente legate con le varie segreteriedi 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 offertidall’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 DBcentralizzato il quale popolera in parte il server LDAP, che attraverso sistemi di bilan-ciamento del carico e protocolli sicuri gestira le richieste dei servizi in modo veloce esicuro.
32
Figura 4.2: Obbiettivi del progetto
33
4.3 Fonti
4.3.1 DBMS scelto
Senza soffermarci su discorsi di performance ma cercando solamente dei test effettuatitra le ultime versioni di MySQL, PostgreSQL e Oracle XE si nota subito una differenzadi tempi di risposta tra MySQL e PostgreSQL (tempi eccellenti) e Oracle. MySQL ePostgreSQL, al contrario di Oracole XE, non usano un server web che comunica con unserver database, ma si basa su un programma compilato, quindi molto piu veloce.Scartando percio l’ipotesi Oracle restano due prodotti snelli, leggeri, flessibili, altamenteconfigurabili.La scelta per il DBMS del progetto cade su MySQL, poiche vince la sfida con PostgreSQLper la maturita del prodotto (incrementata dalla recente aquisizione di una ditta come laSun) e soprattutto la maggiore facilita di utilizzo dovuta a strumenti di gestione, moltocomodi per gli sviluppatori web, come phpmyadmin.Altri motivi sono i costi (nessuno per le licenze) e l’amplio utilizzo che se ne fa sia pressoil 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 (inun 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’internodell’Universita, in modo da poter diversificare efficacemente e in modo centralizzato iprivilegi per accedere ai servizi offerti. Elenchiamo piu in dettaglio i requisiti richiesti alDatabase unificato2:
• Per ogni Identita si deve tenere traccia di:
– Cognome2Tali 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 EduPerson3Sono necessari per i processi di autorizzazione e autenticazione
36
Una volta definiti tutti i vincoli del problema di puo procedere alla realizzazione delloschema relazionale (basato cioe su relazioni e associazioni [1]).Si puo quindi pensare di creare l’entita fondamentale Identita, contenente tutte leinformazioni anagrafiche, alla quale si associano i ruoli che conterranno informazionispecifiche a seconda del ruolo ricoperto.Lo schema relazionale del Database unificato con queste informazioni e rappresentatonella figura successiva:
37
38
Il passo successivo e quello si passare dallo schema astratto alla struttura in tabelletipica 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 statoattuale oltre ad essere poco efficace e anche incompleta perche alcuni ruoli non vengonoproprio (o comunque in maniera non informatizzata) gestiti.E necessario procedere all’identificazione (per la legge anti-terrorismo recentemente en-trata in vigore), di tutte quelle figure (che richiedano credenziali di accesso ai serviziofferti dal sistema), non presenti (come indicato nei paragrafi precedenti), nelle fonti delsistempa;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 diParma)[4].La procedura e accessibile al solo personale incaricato per l’identificazione a norma delD. Lgs. 196/2003.E necessario almeno un incaricato per ogni struttura.L’incarico e conferito dal responsabile del trattamento dati nelle rispettive strutture diappartenenza.L’accesso deve essere controllato tramite LDAP (autenticazione) e profilo di autoriz-zazione.
• la procedura e fornita mediante interfaccia web sicura in modo da essere accessibilein modo distribuito senza onere di gestione della parte client
• la procedura deve acquisire i dati anagrafici, il documento di identita, gli estremidell’incarico e registrarli in un deposito dove tali dati siano facilmente reperibili
• i dati precedentemente acquisiti devono essere correlati con i dati provenienti dallefonti (GISS, WebGISS, ...) ed andare con essi a popolare il database LDAP
• la procedura prevede la popolazione di due tabelle: la tabella IDENTITA e latabella RUOLI. Per maggiori dettagli riguardo alle tabelle coinvolte si guardi ilprogetto del Database Unificato
• alle persone a cui viene affidato almeno un incarico devono percio essere date lecredenziali che permetteranno quindi l’accesso ai servizi d’ateneo mediante l’aut-enticazione LDAP e il profilo previsto dalle policy di ateneo
• la procedura deve permettere di sanare la situazione esistente relativa alle creden-ziali assegnate dal servizio di posta elettronica: molte delle credenziali assegnatein passato non sono piu da considerare valide perche si e persa traccia dei relativirichiedenti o referenti o perche e mancato il controllo costante sulla validita deidati. Le credenziali da tenere vanno associate all’identificazione effettuata con lanuova procedura
40
Ecco in dettaglio le operazioni a carico dell’operatore necessarie per una correttaidentificazione e per l’ottenimento delle credenziali:
1. procurarsi un documento valido e il tesserino del codice fiscale della persona daidentificare
2. preparare un foglio con la copia del documento di identita (fronte e retro) e deltesserino del codice fiscale in un unica facciata (se possibile). In alternativa in unafacciata 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 usandole proprie credenziali di accesso UNIPR
5. se la persona possiede gia le credenziali di accesso ai servizi informatici recuperareil suo nominativo dalla Lista Attesa e andare al punto 6.Se la persona non possiede ancora le credenziali di accesso ai servizi informaticiprocedere 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 Fiscaleandare ad inserire il file corrispondente al FAX precedentemente inviato.Il nome del file e composto da due parti: una prima parte costituita dal numero delvostro numero di FAX; una seconda parte costituita dall’ora in cui avete inviato ilFAX.I FAX inviati al FAX server rimangono in giacenza fino alla mezzanotte dopo diche vengono automaticamente rimossi
8. procedere con Registra i Dati appena inseriti
9. controllare se i dati della persona sono corretti e procedere con Conferma inseri-mento di questi dati nel DB
10. a questo punto procedere con l’assegnazione dell’Incarico: una volta compilati icampi 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 es-sere modificata a seconda delle esigenze, e come descritto richiede un sistema di creazionecredenziali web.
41
4.3.4 Sicurezza nel trattamento dei dati
La sicurezza del trattamento dei dati deve essere una caratteristica di un qualunquesistema 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 successivamentegli aspetti di affidabilita discussi nel paragrafo 3.3.La regolamentazione di tali questioni e principalmente affidata al decreto Legislativo del30 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 inun sistema, definisce5 :
• trattamento: qualunque operazione o complesso di operazioni, effettuati anchesenza l’ausilio di strumenti elettronici, concernenti la raccolta, la registrazione, l’or-ganizzazione, la conservazione, la consultazione, l’elaborazione, la modificazione,la selezione, l’estrazione, il raffronto, l’utilizzo, l’interconnessione, il blocco, la co-municazione, la diffusione, la cancellazione e la distruzione di dati, anche se nonregistrati in una banca di dati
• dato personale: qualunque informazione relativa a persona fisica, persona giuridi-ca, ente od associazione, identificati o identificabili, anche indirettamente, medianteriferimento a qualsiasi altra informazione, ivi compreso un numero di identificazionepersonale
• dati identificativi: i dati personali che permettono l’identificazione diretta del-l’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 reli-gioso, filosofico, politico o sindacale
4Per il testo completo visitare www.http://www.camera.it/parlam/leggi/deleghe/Testi/03196dl.
htm5Questa 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 dicasellario giudiziale, di anagrafe delle sanzioni amministrative dipendenti da reatoe 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 diconseguenza 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 utilizzatiin 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 sonoraccolti o successivamente trattati
∗ conservati in una forma che consenta l’identificazione dell’interessato perun periodo di tempo non superiore a quello necessario agli scopi per iquali essi sono stati raccolti o successivamente trattati
– I dati personali trattati in violazione della disciplina rilevante in materia ditrattamento 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 com-patibili agli scopi per i quali i dati sono raccolti
– conservati per fini esclusivamente personali e non destinati ad una comuni-cazione 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 economicie ammesso solo con il consenso espresso dell’interessato
43
– Il consenso puo riguardare l’intero trattamento ovvero una o piu operazionidello stesso
• Art. 31 (Obblighi di sicurezza): I dati personali oggetto di trattamento sonocustoditi e controllati, anche in relazione alle conoscenze acquisite in base al pro-gresso tecnico, alla natura dei dati e alle specifiche caratteristiche del trattamento,in modo da ridurre al minimo, mediante l’adozione di idonee e preventive misuredi sicurezza, i rischi di distruzione o perdita, anche accidentale, dei dati stessi,di accesso non autorizzato o di trattamento non consentito o non conforme allefinalita della raccolta
• Art. 34 (Trattamenti con strumenti elettronici): Il trattamento di dati personalieffettuato con strumenti elettronici e consentito solo se sono adottate le seguentimisure 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 con-sentito ai singoli incaricati e addetti alla gestione o alla manutenzione deglistrumenti elettronici
– protezione degli strumenti elettronici e dei dati rispetto a trattamenti illecitidi dati, ad accessi non consentiti e a determinati programmi informatici
– adozione di procedure per la custodia di copie di sicurezza, il ripristino delladisponibilita dei dati e dei sistemi
– tenuta di un aggiornato documento programmatico sulla sicurezza
Ora caliamoci nei requisiti riguardanti il trattamento dei dati mediante strumentielettronici (allegato B dlgs. 196/2003):
• Sistema di autenticazione informatica:
– Il trattamento di dati personali con strumenti elettronici e consentito agli in-caricati dotati di credenziali di autenticazione che consentano il superamentodi una procedura di autenticazione relativa a uno specifico trattamento o aun insieme di trattamenti
44
– Le credenziali di autenticazione consistono in un codice per l’identificazionedell’incaricato associato a una parola chiave riservata conosciuta solamentedal medesimo oppure in un dispositivo di autenticazione in possesso e usoesclusivo dell’incaricato, eventualmente associato a un codice identificativo oa 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 neces-sarie cautele per assicurare la segretezza della componente riservata dellacredenziale e la diligente custodia dei dispositivi in possesso ed uso esclusivodell’incaricato
– La parola chiave, quando e prevista dal sistema di autenticazione, e compostada almeno otto caratteri oppure, nel caso in cui lo strumento elettronico nonlo permetta, da un numero di caratteri pari al massimo consentito; essa noncontiene riferimenti agevolmente riconducibili all’incaricato ed e modificatada quest’ultimo al primo utilizzo e, successivamente, almeno ogni sei mesi
– Il codice per l’identificazione, laddove utilizzato, non puo essere assegnato adaltri incaricati, neppure in tempi diversi
– Le credenziali di autenticazione non utilizzate da almeno sei mesi sono dis-attivate, salvo quelle preventivamente autorizzate per soli scopi di gestionetecnica
– Le credenziali sono disattivate anche in caso di perdita della qualita checonsente all’incaricato l’accesso ai dati personali
– Sono impartite istruzioni agli incaricati per non lasciare incustodito e acces-sibile lo strumento elettronico durante una sessione di trattamento
– Quando l’accesso ai dati e agli strumenti elettronici e consentito esclusiva-mente mediante uso della componente riservata della credenziale per l’au-tenticazione, sono impartite idonee e preventive disposizioni scritte volte aindividuare chiaramente le modalita con le quali il titolare puo assicurare ladisponibilita di dati o strumenti elettronici in caso di prolungata assenza oimpedimento dell’incaricato che renda indispensabile e indifferibile intervenireper esclusive necessite di operativite e di sicurezza del sistema. In tal casola custodia delle copie delle credenziali e organizzata garantendo la relativa
45
segretezza e individuando preventivamente per iscritto i soggetti incaricatidella loro custodia, i quali devono informare tempestivamente l’incaricatodell’intervento effettuato.
• Sistema di autorizzazione:
– I profili di autorizzazione, per ciascun incaricato o per classi omogenee diincaricati, sono individuati e configurati anteriormente all’inizio del tratta-mento, in modo da limitare l’accesso ai soli dati necessari per effettuare leoperazioni di trattamento
– Periodicamente, e comunque almeno annualmente, e verificata la sussistenzadelle 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 diprogrammi mediante l’attivazione di idonei strumenti elettronici da aggiornarecon cadenza almeno semestrale
– Gli aggiornamenti periodici dei programmi per elaboratore volti a prevenirela vulnerabilita di strumenti elettronici e a correggerne difetti sono effettuatialmeno annualmente
– Sono impartite istruzioni organizzative e tecniche che prevedono il salvataggiodei dati con frequenza almeno settimanale
• Documento programmatico sulla sicurezza:
– Entro il 31 marzo di ogni anno, il titolare di un trattamento di dati sensi-bili o di dati giudiziari redige anche attraverso il responsabile, se designato,un documento programmatico sulla sicurezza contenente idonee informazioniriguardo:
∗ l’elenco dei trattamenti di dati personali
∗ la distribuzione dei compiti e delle responsabilita nell’ambito delle strut-ture 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 lorocustodia e accessibilita
46
∗ la descrizione dei criteri e delle modalita per il ripristino della disponibilitadei dati in seguito a distruzione o danneggiamento
∗ la previsione di interventi formativi degli incaricati del trattamento, perrenderli edotti dei rischi che incombono sui dati, delle misure disponibiliper prevenire eventi dannosi, dei profili della disciplina sulla protezionedei dati personali piu rilevanti in rapporto alle relative attivita, delleresponsabilita che ne derivano e delle modalita per aggiornarsi sulle mis-ure minime adottate dal titolare. La formazione e programmata gia almomento dell’ingresso in servizio, nonche in occasione di cambiamentidi mansioni, o di introduzione di nuovi significativi strumenti, rilevantirispetto al trattamento di dati personali
∗ la descrizione dei criteri da adottare per garantire l’adozione delle misureminime di sicurezza in caso di trattamenti di dati personali affidati, inconformita 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 unifi-cato, 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 trascu-rare.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 deveessere trattato in modo ottimale (ved. 3.1.2)
• Per l’articolo 16 i dati nel nostro progetto vengono conservati per fini esclusiva-mente 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 rispet-tate sia in termini di autenticazione per l’accesso ai dati sia in termini di sicurezzadei 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 unaed una sola credenziale per l’autenticazione
– Le problematiche di lunghezza minima della password e difficolta della pass-word sono gia verificati allo stato attuale
– L’univocita delle credenziali (password e username ad esempio) sono unacaratteristica fondamentale del progetto
– Allo stato attuale non esiste alcuna procedura che permetta la disattivazionedi credenziali di autenticazione non utilizzate da almeno sei mesi, quindiquesta 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 (semplificatoanche 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 proce-dure 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 proceduredi 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 neldatabase
– gruppo other, a cui e negato tutto
– altri gruppi specifici
Tutte queste procedure sono facilmente realizzabili in MySQL oltre che per via tes-tuale anche attraverso ottimi strumenti come phpmyadmin e MySQLAdministra-
tor.
6Ovvero 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 sistemasorge un problema non banale: quale attributo (o quale insieme di attributi) puo essereutilizzato come chiave identificativa dell’identita? Esso deve essere univoco (il che puoescludere la scelta ovvia e banale del codice fiscale) e il piu possibile facile da ricordareper l’utente poiche diverra molto probabilmente l’UserID in un sistema centralizzato nelsistema 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 perdistinguere omonimi)
• chiavi costruite ad hoc che siamo piu memoniche di un contatore, ad esempio:
– matricola (prima matricola per gli studenti) + data di nascita (nella formagg/mm/aaaa)
– matricola (prima matricola per gli studenti) + prima password (implica persicurezza il cambio della prima password)
– altri costruiti ad hoc...
Per quello visto all’interno del progetto, non risulta necessario modificare l’attualepolicy di gestione del ciclo di vita dell’identita, ma anche se in un futuro si dovesse averela necessita di modificare tali politiche non sara necesario stravolgere l’architettura delprogetto.
Vediamo in dettaglio quali possano essere i passi necessari per il corretto funziona-mento del ciclo di vita dell’Identita rispetto alle Fonti e al Server IAM (come illustratoin 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 (mediantecanali sicuri, quindi cifrati) al Database IAM ogni sera
50
3. un controllo presente nel database (ad esempio uno script PERL) verifica chel’ 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 Identita7;se cio fosse verificato si aggiungerebbe la nuova Identita e il suo ruolo collega-to altrimenti si aggiungerebbe solamente il nuovo ruolo ricoperto (saremmoquindi nel caso di Modifica di Ruolo8)
• cancellazione di un Identita: si e valutato nel progetto piu opportuno non cancel-lare mai un Identita dal server IAM, ma se questo fosse necessario verrebbe vistacome una comune modifica da trasferire dalla fonte al Database IAM la sera stessadella cancellazione (come nel caso della creazione)
• modifica di attributi: come nei casi precedenti le modifiche di attributi sonoinviate la sera dalle fonti al Database IAM
• modifica credenziali d’accesso: deve essere fornita una pagina web che abbiaaccesso diretto al Database e che quindi possa permettere alle Identita di cambiarele credenziali come ritengono
Come si puo facilmente intuire dai passi descritti sopra, i dati presenti nelle fonti nonsono 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 LDAPche li rendera disponibili anche alle risorse. Si puo pensare che questo ultimo passaggiopossa 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).
7Possiamo pensare difatti che due identita con stesso nome, cognome, codice fiscale e nate lo stessogiorno siano la stessa persona
8Questo perche l’Identita e gia presente ma non ha associato il nuovo ruolo9Vedere 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 effettuauna modifica in una fonte alle 11 di mattina, l’informazione potra essere effettivamentevisibile 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 centralizza-to, ma per interfacciarsi con le risorse, per la gestione dell’autenticazione e dell’au-torizzazione centralizzate, diventa necessario replicare alcune informazioni su un serverLDAP.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
• 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 gestionedell’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 neldatabase (principalemente per motivi di efficienza), una diversa soluzione poteva esserequella di avere un numero ristretto di dati in LDAP e nel caso una applicazione avessebisogno di ulteriori informazioni su un utente, “collegarla” direttamente al databaseimplementando, per esempio, un web service per questo scopo.Questi dati verranno in seguito organizzati e gestiti opportunamente dal server LDAPche permettera quindi l’accesso alle risorse.
55
Capitolo 5
Conclusioni
In questa tesi si sono analizzati e formalizzati tutti gli elementi e le problematiche (ocomunque quelli fondamentali) riguardanti l’Identity Management (Capitolo 1), succes-sivamente 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 (realiz-zazione di una Base di Dati, problematiche varie di sicurezza e affidabilita, linguaggioSQL) 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 Databasedi gestione dell’Identita sia il lato LDAP per la gestione delle richieste dei servizi) cheverificasse tutti i requisiti che deve possedere per essere:
• funzionale
• sicuro
• affidabile
• performante
Dopo l’effettiva implementazione di tale progetto sia la gestione delle Identita verrarazionalizzata (andando quindi a risolvere le problematiche dell’attuale gestione) sial’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 attraversoquesto 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 delciclo di vita
Quel che riguarda il primo punto e sicuramente l’aspetto piu interessante: difattipassare informazioni tramite file di testo dalle varie segreterie al centro di calcolo non euna soluzione ideale.Una soluzione sarebbe quella di introdurre i Web Service:un Web Service (servizio web) e un sistema software progettato per supportare l’inter-operabilita tra diversi elaboratori su di una medesima rete[10];la caratteristica fondamentale di un Web Service sta nell’offrire un’interfaccia softwareutilizzando la quale altri sistemi possono interagire con il Web Service stesso attivando leoperazioni descritte nell’interfaccia tramite appositi messaggi inclusi in una busta: talimessaggi sono, solitamente, trasportati tramite il protocollo HTTP e formattati secondolo standard XML.Proprio grazie all’utilizzo di standard basati su XML, tramite un’architettura basata suiWeb Service (chiamata, con terminologia inglese, Service oriented Architecture - SOA)applicazioni software scritte in diversi linguaggi di programmazione e implementate sudiverse piattaforme hardware possono quindi essere utilizzate, tramite le interfacce chequeste espongono pubblicamente e mediante l’utilizzo delle funzioni che sono in gradodi 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: lapossibilita dell’interoperabilita fra diversi software (ad esempio, tra Java e Python) ediverse piattaforme hardware (come Windows e Linux) e resa possibile dall’uso di stan-dard aperti.L’interazione tra servizi, fonti e server IAM avvanteggierebbe notevolmente tutta l’ar-chitettura.
57
Figura 5.1: Architettura con Web Service
58
Appendice A
Glossario
• Ruolo: insieme di privilegi all’interno del sistema dovute alla funzione che siricopre all’interno dell’Universita
• Identita: entita unica che accede al sistema e che deve essere riconosciuta e allaquale possono essere associati diversi ruoli; quindi e l’insieme delle informazioniche caratterizzano un utente che sono le informazioni relative alla identita e aidiversi ruoli e/o attributi che questo puo avere
• Risorsa informatica (o brevemente risorsa) intendiamo un servizio reso disponi-bile ad un insieme di utenti registrati, ovvero di cui si conosce l’identita, che hauno scopo preciso ed utile all’utente che ne fa uso, ed e accessibile attraverso mezziinformatici (ad esempio attraverso un computer). Esempi di risorse sono la postaelettronica, l’accesso ad un computer oppure l’accesso ad una rete locale (serviziad esempio offerti dall’Universita di Parma).
• Server IAM: sistema software ed hardware centralizzato (indicativamente com-posto da un unico Database e da un sistema LDAP) che gestisce in modo ottimaleil ciclo di vita delle Identita ed al quale le applicazioni si interfacciano gestendopercio 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 10.11
−−−− Host : l o c a l h o s t Database : unipr
−− −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− Server ver s ion 5.0.67−0 ubuntu6
/∗ !40101 SET @OLD CHARACTER SET CLIENT=@@CHARACTER SET CLIENT ∗/ ;
/∗ !40101 SET @OLD CHARACTER SET RESULTS=@@CHARACTER SET RESULTS ∗/ ;
/∗ !40101 SET @OLD COLLATION CONNECTION=@@COLLATION CONNECTION ∗/ ;
/∗ !40101 SET NAMES ut f 8 ∗/ ;
/∗ !40103 SET @OLD TIME ZONE=@@TIME ZONE ∗/ ;
/∗ !40103 SET TIME ZONE=’+00:00 ’ ∗/ ;
/∗ !40014 SET @OLD UNIQUE CHECKS=@@UNIQUE CHECKS, UNIQUE CHECKS=0 ∗/ ;
/∗ !40014 SET @OLD FOREIGN KEY CHECKS=@@FOREIGN KEY CHECKS, FOREIGN KEY CHECKS=0 ∗/ ;
/∗ !40101 SET @OLD SQL MODE=@@SQL MODE, SQL MODE=’NO AUTO VALUE ON ZERO’ ∗/ ;
/∗ !40111 SET @OLD SQL NOTES=@@SQL NOTES, SQL NOTES=0 ∗/ ;
−−−− Table s t r u c t u r e f o r t a b l e ‘AREA‘
−−
DROP TABLE IF EXISTS ‘AREA‘ ;
SET @saved c s c l i e n t = @@cha ra c t e r s e t 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 = ut f8 ;
CREATE TABLE ‘AREA‘ (
‘ s i g l a ‘ char (2 ) NOT NULL COMMENT ’ Codice d e l l area d i d a t t i c a ’ ,
‘nome ‘ varchar (32) NOT NULL COMMENT ’ Des c r i z i one per 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 = @saved c s c l i e n t ;
−−
60
−− Dumping data f o r t a b l e ‘AREA‘
−−
LOCK TABLES ‘AREA‘ WRITE;
/∗ !40000 ALTER TABLE ‘AREA‘ DISABLE KEYS ∗/ ;
/∗ !40000 ALTER TABLE ‘AREA‘ ENABLE KEYS ∗/ ;
UNLOCK TABLES;
−−−− Table s t r u c t u r e f o r t a b l e ‘CARRIERA‘
−−
DROP TABLE IF EXISTS ‘CARRIERA‘ ;
SET @saved c s c l i e n t = @@cha ra c t e r s e t 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 = ut f8 ;
CREATE TABLE ‘CARRIERA‘ (
‘ matr ico la ‘ char (6 ) NOT NULL COMMENT ’ Matr ico la d e l l o s tudente ’ ,
‘ anno pr ima immatr ico laz ione ‘ int (11) NOT NULL
COMMENT ’Anno di prima immatr i co laz ione ’ ,
‘ d a t a l a u r e a t r i e nna l e ‘ date default NULL
COMMENT ’Data d e l l a l au r ea 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 au r ea s p e c i a l i s t i c a ’ ,
‘ c o r s o d i l au r ea appa r t enenza ‘ char (4 ) NOT NULL
COMMENT ’ Corso d i l au r ea d i appartenenza ’ ,
PRIMARY KEY ( ‘ matr ico la ‘ ) ,
KEY ‘ n ew fk cons t ra in t5 ‘ ( ‘ c o r s o d i l au r ea appa r t enenza ‘ ) ,
CONSTRAINT ‘ n ew fk cons t ra in t5 ‘ FOREIGN KEY ( ‘ c o r s o d i l au r ea appa r t enenza ‘ )
REFERENCES ‘CORSO LAUREA‘ ( ‘ codice ‘ )
) ENGINE=InnoDB DEFAULT CHARSET=l a t i n 1 COMMENT=’ Car r i e r e d e l l o s tudente ’ ;
SET c h a r a c t e r s e t c l i e n t = @saved c s c l i e n t ;
−−−− Dumping data f o r t a b l e ‘CARRIERA‘
−−
LOCK TABLES ‘CARRIERA‘ WRITE;
/∗ !40000 ALTER TABLE ‘CARRIERA‘ DISABLE KEYS ∗/ ;
/∗ !40000 ALTER TABLE ‘CARRIERA‘ ENABLE KEYS ∗/ ;
UNLOCK TABLES;
−−−− Table 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 @saved c s c l i e n t = @@cha ra c t e r s e t 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 = ut f8 ;
CREATE TABLE ‘CODICE RUOLO‘ (
‘ s i g l a ‘ char (2 ) NOT NULL COMMENT ’ Codice de l ruo lo ’ ,
‘nome ‘ varchar (32) NOT NULL COMMENT ’Nome per e s t e s o de l ruo lo ’ ,
61
PRIMARY KEY ( ‘ s i g l a ‘ )
) ENGINE=InnoDB DEFAULT CHARSET=l a t i n 1 COMMENT=’ Codice Ruolo ’ ;
SET c h a r a c t e r s e t c l i e n t = @saved c s c l i e n t ;
−−−− Dumping data f o r t a b l e ‘CODICE RUOLO‘
−−
LOCK TABLES ‘CODICE RUOLO‘ WRITE;
/∗ !40000 ALTER TABLE ‘CODICE RUOLO‘ DISABLE KEYS ∗/ ;
/∗ !40000 ALTER TABLE ‘CODICE RUOLO‘ ENABLE KEYS ∗/ ;
UNLOCK TABLES;
−−−− Table 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 @saved c s c l i e n t = @@cha ra c t e r s e t 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 = ut f8 ;
CREATE TABLE ‘CORSO LAUREA‘ (
‘ codice ‘ char (4 ) NOT NULL COMMENT ’ Codice a 4 c i f r e ’ ,
‘ durata ‘ int (11) NOT NULL COMMENT ’ Durata in anni ’ ,
‘nome ‘ varchar (32) NOT NULL COMMENT ’Nome per e s t e s o ’ ,
‘ t i poco r so ‘ char (2 ) NOT NULL COMMENT ’ Tipo d i co r so ’ ,
‘ f a c o l t a ‘ char (2 ) NOT NULL COMMENT ’ Faco l ta d i appartenenza ’ ,
PRIMARY KEY ( ‘ cod ice ‘ ) ,
KEY ‘ n ew fk cons t ra in t3 ‘ ( ‘ t i poco r so ‘ ) ,
KEY ‘ n ew fk cons t ra in t4 ‘ ( ‘ f a c o l t a ‘ ) ,
CONSTRAINT ‘ n ew fk cons t ra in t4 ‘ FOREIGN KEY ( ‘ f a c o l t a ‘ )
REFERENCES ‘FACOLTA‘ ( ‘ s i g l a ‘ ) ,
CONSTRAINT ‘ n ew fk cons t ra in t3 ‘ FOREIGN KEY ( ‘ t i poco r so ‘ )
REFERENCES ‘TIPO CORSO‘ ( ‘ codice ‘ )
) ENGINE=InnoDB DEFAULT CHARSET=l a t i n 1 COMMENT=’ Cors i d i l au r ea ’ ;
SET c h a r a c t e r s e t c l i e n t = @saved c s c l i e n t ;
−−−− Dumping data f o r t a b l e ‘CORSO LAUREA‘
−−
LOCK TABLES ‘CORSO LAUREA‘ WRITE;
/∗ !40000 ALTER TABLE ‘CORSO LAUREA‘ DISABLE KEYS ∗/ ;
/∗ !40000 ALTER TABLE ‘CORSO LAUREA‘ ENABLE KEYS ∗/ ;
UNLOCK TABLES;
−−−− Table 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 ‘ ;
SET @saved c s c l i e n t = @@cha ra c t e r s e t 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 = ut f8 ;
CREATE TABLE ‘DATI LDAP‘ (
‘ cn ‘ varchar (32) NOT NULL COMMENT ’Common name ’ ,
‘ mail ‘ varchar (32) NOT NULL COMMENT ’ Mail as segnata ’ ,
‘ p a s swo rd i n i z i a l e ‘ varchar (32) NOT NULL COMMENT ’ Password i n i z i a l e ’ ,
‘ uid ‘ varchar (32) NOT NULL COMMENT ’UID ’ ,
‘ uid number ‘ int (11) NOT NULL,
PRIMARY KEY ( ‘ cn ‘ )
) ENGINE=InnoDB DEFAULT CHARSET=l a t i n 1
COMMENT=’ Dati u t i l i per l ’ ’ a c c e s so a l l e r i s o r s e ( incompleto ) ’ ;
SET c h a r a c t e r s e t c l i e n t = @saved c s c l i e n t ;
−−−− Dumping data f o r t a b l e ‘DATI LDAP‘
−−
LOCK TABLES ‘DATI LDAP‘ WRITE;
/∗ !40000 ALTER TABLE ‘DATI LDAP‘ DISABLE KEYS ∗/ ;
/∗ !40000 ALTER TABLE ‘DATI LDAP‘ ENABLE KEYS ∗/ ;
UNLOCK TABLES;
−−−− Table s t r u c t u r e f o r t a b l e ‘DIPARTIMENTI‘
−−
DROP TABLE IF EXISTS ‘DIPARTIMENTI ‘ ;
SET @saved c s c l i e n t = @@cha ra c t e r s e t 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 = ut f8 ;
CREATE TABLE ‘DIPARTIMENTI‘ (
‘nome ‘ varchar (32) NOT NULL COMMENT ’Nome de l d ipart imento ’ ,
‘ s i g l a ‘ char (2 ) NOT NULL COMMENT ’ Codice de l d ipart imento ’ ,
‘ s ede d ipart imento ‘ char (6 ) default NULL COMMENT ’ Sede de l d ipart imento ’ ,
PRIMARY KEY ( ‘ s i g l a ‘ ) ,
KEY ‘ n ew fk cons t ra in t7 ‘ ( ‘ s ede d ipart imento ‘ ) ,
CONSTRAINT ‘ n ew fk cons t ra in t7 ‘ FOREIGN KEY ( ‘ s ede d ipart imento ‘ )
REFERENCES ‘SEDI ‘ ( ‘ codice ‘ )
) ENGINE=InnoDB DEFAULT CHARSET=l a t i n 1
COMMENT=’ Dipart iment i d e l l Un ive 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 = @saved c s c l i e n t ;
−−−− Dumping data f o r t a b l e ‘DIPARTIMENTI‘
−−
LOCK TABLES ‘DIPARTIMENTI‘ WRITE;
/∗ !40000 ALTER TABLE ‘DIPARTIMENTI‘ DISABLE KEYS ∗/ ;
/∗ !40000 ALTER TABLE ‘DIPARTIMENTI‘ ENABLE KEYS ∗/ ;
UNLOCK TABLES;
−−−− Table 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 @saved c s c l i e n t = @@cha ra c t e r s e t 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 = ut f8 ;
CREATE TABLE ‘FACOLTA‘ (
‘ s i g l a ‘ char (2 ) NOT NULL COMMENT ’ Codice a 2 c i f r e ’ ,
‘nome ‘ varchar (32) NOT NULL COMMENT ’Nome per e s t e s o ’ ,
PRIMARY KEY ( ‘ s i g l a ‘ )
) ENGINE=InnoDB DEFAULT CHARSET=l a t i n 1
COMMENT=’ Faco l ta d e l l ’ ’ Un ive 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 = @saved c s c l i e n t ;
−−−− Dumping data f o r t a b l e ‘FACOLTA‘
−−
LOCK TABLES ‘FACOLTA‘ WRITE;
/∗ !40000 ALTER TABLE ‘FACOLTA‘ DISABLE KEYS ∗/ ;
/∗ !40000 ALTER TABLE ‘FACOLTA‘ ENABLE KEYS ∗/ ;
UNLOCK TABLES;
−−−− Table s t r u c t u r e f o r t a b l e ‘IDENTITA‘
−−
DROP TABLE IF EXISTS ‘IDENTITA ‘ ;
SET @saved c s c l i e n t = @@cha ra c t e r s e t 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 = ut f8 ;
CREATE TABLE ‘IDENTITA‘ (
‘ i d i d en t i t a ‘ varchar (32) NOT NULL COMMENT ’E−Mail as segnata ’ ,
‘ cognome ‘ varchar (32) NOT NULL COMMENT ’Cognome ’ ,
‘nome ‘ varchar (32) NOT NULL COMMENT ’Nome ’ ,
‘ s e s so ‘ char (1 ) NOT NULL COMMENT ’ Sesso ’ ,
‘ da ta nasc i ta ‘ date NOT NULL COMMENT ’Data d i na s c i t a ’ ,
‘ c o d i c e f i s c a l e ‘ varchar (16) NOT NULL COMMENT ’ Codice f i s c a l e ’ ,
‘ c ap domic i l i o ‘ varchar (5 ) NOT NULL COMMENT ’CAP domi c i l i o ’ ,
‘ cap re s idenza ‘ varchar (5 ) NOT NULL COMMENT ’CAP re s i d enza ’ ,
‘ ma i l pe r sona l e ‘ varchar (32) default NULL COMMENT ’E Mail pe r sona l e ’ ,
‘ t e l e f o n o r e s i d e n z a ‘ varchar (32) default NULL COMMENT ’ Tele fono r e s i d enza ’ ,
‘ t e l e f o n o d om i c i l i o ‘ varchar (32) default NULL COMMENT ’ Tele fono dom i c i l i o ’ ,
‘ t e l e f o n o c e l l u l a r e ‘ varchar (32) default NULL COMMENT ’ Tele fono c e l l u l a r e ’ ,
‘ fax ‘ varchar (32) default NULL COMMENT ’Fax ’ ,
‘ v i a dom i c i l i o ‘ varchar (32) NOT NULL COMMENT ’ Via dom i c i l i o ’ ,
‘ v i a r e s i d enza ‘ varchar (32) NOT NULL COMMENT ’ Via r e s i d enza ’ ,
‘ t i t o l o o n o r i f i c o ‘ int (11) default NULL COMMENT ’ Ti to l o o n o r i f i c o ’ ,
‘ s t a t o c i t t ad i nanza ‘ varchar (32) NOT NULL COMMENT ’ Stato d i c i t t ad inanza ’ ,
‘ s t a t o r e s i d en za ‘ varchar (32) NOT NULL COMMENT ’ Stato d i r e s i d enza ’ ,
‘ s t a t o dom i c i l i o ‘ varchar (32) NOT NULL COMMENT ’ Stato d i dom i c i l i o ’ ,
‘ s t a t o na s c i t a ‘ varchar (32) NOT NULL COMMENT ’ Stato d i na s c i t a ’ ,
‘ cn ‘ varchar (32) NOT NULL COMMENT ’Common Name ’ ,
64
‘ l uogo na s c i t a ‘ char (6 ) NOT NULL COMMENT ’Luogo d i na s c i t a ’ ,
‘ l uogo r e s id enza ‘ char (6 ) NOT NULL COMMENT ’Luogo d i r e s i d enza ’ ,
‘ l uogo domi c i l i o ‘ char (6 ) NOT NULL COMMENT ’Luogo d i dom i c i l i o ’ ,
PRIMARY KEY ( ‘ i d i d en t i t a ‘ ) ,
KEY ‘ n ew fk cons t ra in t20 ‘ ( ‘ t i t o l o o n o r i f i c o ‘ ) ,
KEY ‘ n ew fk cons t ra in t21 ‘ ( ‘ s t a t o c i t t ad i nanza ‘ ) ,
KEY ‘ n ew fk cons t ra in t23 ‘ ( ‘ s t a t o r e s i d en za ‘ ) ,
KEY ‘ n ew fk cons t ra in t24 ‘ ( ‘ s t a t o dom i c i l i o ‘ ) ,
KEY ‘ n ew fk cons t ra in t25 ‘ ( ‘ s t a t o na s c i t a ‘ ) ,
KEY ‘ n ew fk cons t ra in t26 ‘ ( ‘ cn ‘ ) ,
KEY ‘ n ew fk cons t ra in t27 ‘ ( ‘ l uogo na s c i t a ‘ ) ,
KEY ‘ n ew fk cons t ra in t28 ‘ ( ‘ l uogo r e s id enza ‘ ) ,
KEY ‘ n ew fk cons t ra in t29 ‘ ( ‘ l uogo domi c i l i o ‘ ) ,
CONSTRAINT ‘ n ew fk cons t ra in t28 ‘ FOREIGN KEY ( ‘ l uogo r e s id enza ‘ )
REFERENCES ‘LUOGO‘ ( ‘ c o d i c e i s t a t ‘ ) ,
CONSTRAINT ‘ n ew fk cons t ra in t29 ‘ FOREIGN KEY ( ‘ l uogo domi c i l i o ‘ )
REFERENCES ‘LUOGO‘ ( ‘ c o d i c e i s t a t ‘ ) ,
CONSTRAINT ‘ n ew fk cons t ra in t20 ‘ FOREIGN KEY ( ‘ t i t o l o o n o r i f i c o ‘ )
REFERENCES ‘TITOLO ONORIFICO‘ ( ‘ codice ‘ ) ,
CONSTRAINT ‘ n ew fk cons t ra in t21 ‘ FOREIGN KEY ( ‘ s t a t o c i t t ad i nanza ‘ )
REFERENCES ‘STATO‘ ( ‘ nome ‘ ) ,
CONSTRAINT ‘ n ew fk cons t ra in t22 ‘ FOREIGN KEY ( ‘ s t a t o r e s i d en za ‘ )
REFERENCES ‘STATO‘ ( ‘ nome ‘ ) ,
CONSTRAINT ‘ n ew fk cons t ra in t23 ‘ FOREIGN KEY ( ‘ s t a t o r e s i d en za ‘ )
REFERENCES ‘STATO‘ ( ‘ nome ‘ ) ,
CONSTRAINT ‘ n ew fk cons t ra in t24 ‘ FOREIGN KEY ( ‘ s t a t o dom i c i l i o ‘ )
REFERENCES ‘STATO‘ ( ‘ nome ‘ ) ,
CONSTRAINT ‘ n ew fk cons t ra in t25 ‘ FOREIGN KEY ( ‘ s t a t o na s c i t a ‘ )
REFERENCES ‘STATO‘ ( ‘ nome ‘ ) ,
CONSTRAINT ‘ n ew fk cons t ra in t26 ‘ FOREIGN KEY ( ‘ cn ‘ )
REFERENCES ‘DATI LDAP‘ ( ‘ cn ‘ ) ,
CONSTRAINT ‘ n ew fk cons t ra in t27 ‘ FOREIGN KEY ( ‘ l uogo na 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 ROWFORMAT=DYNAMIC
COMMENT=’ Id en t i t a d e l l Un ive 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 = @saved c s c l i e n t ;
−−−− Dumping data f o r t a b l e ‘IDENTITA‘
−−
LOCK TABLES ‘IDENTITA‘ WRITE;
/∗ !40000 ALTER TABLE ‘IDENTITA‘ DISABLE KEYS ∗/ ;
/∗ !40000 ALTER TABLE ‘IDENTITA‘ ENABLE KEYS ∗/ ;
UNLOCK TABLES;
−−−− Table 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 @saved c s c l i e n t = @@cha ra c t e r s e t 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 = ut f8 ;
CREATE TABLE ‘ INCARICHI ‘ (
‘ s i g l a ‘ char (2 ) NOT NULL COMMENT ’ Codice d e g l i i n c a r i c h i ’ ,
‘nome ‘ varchar (32) NOT NULL COMMENT ’ Des c r i z i one per 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 = @saved c s c l i e n t ;
−−−− Dumping data f o r t a b l e ‘INCARICHI‘
−−
LOCK TABLES ‘INCARICHI ‘ WRITE;
/∗ !40000 ALTER TABLE ‘INCARICHI‘ DISABLE KEYS ∗/ ;
/∗ !40000 ALTER TABLE ‘INCARICHI‘ ENABLE KEYS ∗/ ;
UNLOCK TABLES;
−−−− Table s t r u c t u r e f o r t a b l e ‘LUOGO‘
−−
DROP TABLE IF EXISTS ‘LUOGO‘ ;
SET @saved c s c l i e n t = @@cha ra c t e r s e t 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 = ut f8 ;
CREATE TABLE ‘LUOGO‘ (
‘ c o d i c e i s t a t ‘ char (6 ) NOT NULL COMMENT ’ Codice ISTAT ’ ,
‘ c od i c e a g en z i a en t r a t e ‘ char (4 ) NOT NULL COMMENT ’ Codice c a t a s t a l e ’ ,
‘ d e s c r i z i on e ‘ varchar (32) NOT NULL COMMENT ’Nome per e s t e s o ’ ,
‘ comune ‘ varchar (32) NOT NULL COMMENT ’Nome per e s t e s o de l comune ’ ,
‘ p rov inc ia ‘ char (2 ) NOT NULL COMMENT ’ S i g l a au t omob i l i s t i c a d e l l a p rov inc i a ’ ,
PRIMARY KEY ( ‘ c o d i c e i s t a t ‘ ) ,
KEY ‘ n ew fk cons t ra in t ‘ ( ‘ prov inc ia ‘ ) ,
CONSTRAINT ‘ n ew fk cons t ra in t ‘ FOREIGN KEY ( ‘ prov inc ia ‘ )
REFERENCES ‘PROVINCIA‘ ( ‘ s i g l a ‘ )
) ENGINE=InnoDB DEFAULT CHARSET=l a t i n 1 COMMENT=’ Loca 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 = @saved c s c l i e n t ;
−−−− Dumping data f o r t a b l e ‘LUOGO‘
−−
LOCK TABLES ‘LUOGO‘ WRITE;
/∗ !40000 ALTER TABLE ‘LUOGO‘ DISABLE KEYS ∗/ ;
/∗ !40000 ALTER TABLE ‘LUOGO‘ ENABLE KEYS ∗/ ;
UNLOCK TABLES;
−−−− Table 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 @saved c s c l i e n t = @@cha ra c t e r s e t 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 = ut f8 ;
CREATE TABLE ‘PROFILO‘ (
‘ s i g l a ‘ char (11) NOT NULL COMMENT ’ Codice de l p r o f i l o (11 c a r a t t e r i ) ’ ,
‘nome ‘ varchar (32) NOT NULL COMMENT ’ Des c r i z i one per 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 de l ruo lo ’ ;
SET c h a r a c t e r s e t c l i e n t = @saved c s c l i e n t ;
−−−− Dumping data f o r t a b l e ‘PROFILO‘
−−
LOCK TABLES ‘PROFILO‘ WRITE;
/∗ !40000 ALTER TABLE ‘PROFILO‘ DISABLE KEYS ∗/ ;
/∗ !40000 ALTER TABLE ‘PROFILO‘ ENABLE KEYS ∗/ ;
UNLOCK TABLES;
−−−− Table s t r u c t u r e f o r t a b l e ‘PROVINCIA‘
−−
DROP TABLE IF EXISTS ‘PROVINCIA‘ ;
SET @saved c s c l i e n t = @@cha ra c t e r s e t 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 = ut f8 ;
CREATE TABLE ‘PROVINCIA‘ (
‘ s i g l a ‘ char (2 ) NOT NULL,
‘nome ‘ varchar (32) NOT NULL,
PRIMARY KEY ( ‘ s i g l a ‘ )
) ENGINE=InnoDB DEFAULT CHARSET=l a t i n 1 COMMENT=’ Elenco d e l l e prov ince 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 = @saved c s c l i e n t ;
−−−− Dumping data f o r t a b l e ‘PROVINCIA‘
−−
LOCK TABLES ‘PROVINCIA‘ WRITE;
/∗ !40000 ALTER TABLE ‘PROVINCIA‘ DISABLE KEYS ∗/ ;
/∗ !40000 ALTER TABLE ‘PROVINCIA‘ ENABLE KEYS ∗/ ;
UNLOCK TABLES;
−−−− Table s t r u c t u r e f o r t a b l e ‘RUOLO‘
−−
DROP TABLE IF EXISTS ‘RUOLO‘ ;
SET @saved c s c l i e n t = @@cha ra c t e r s e t 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 = ut f8 ;
CREATE TABLE ‘RUOLO‘ (
‘ idsge ‘ char (6 ) NOT NULL COMMENT ’ Codice IDSGE ’ ,
67
‘ s i s a ‘ char (6 ) NOT NULL COMMENT ’ Codice SISA ’ ,
‘ d a t a i n i z i o ‘ date NOT NULL COMMENT ’Data d i i n i z i o de l ruo lo ’ ,
‘ da ta f i n e ‘ date default NULL COMMENT ’Data d i te rminaz ione de l ruo lo ’ ,
‘ cod ruo lo ‘ char (2 ) NOT NULL COMMENT ’ Codice de l ruo lo ’ ,
‘ p r o f i l o ‘ char (2 ) NOT NULL COMMENT ’ P r o f i l o ’ ,
‘ s t a t o ruo l o ‘ char (2 ) NOT NULL COMMENT ’ Stato ruo lo ’ ,
‘ c a r r i e r a ‘ char (6 ) NOT NULL COMMENT ’ Car r i e ra 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 ’ ,
‘ aree ‘ 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 ’ Se t to r e d i d a t t i c o ’ ,
‘ d ipart imento ‘ char (2 ) NOT NULL COMMENT ’ Dipartimento d i appartenenza ’ ,
‘ s e r v i z i o ‘ char (2 ) NOT NULL COMMENT ’ S e r v i z i o ’ ,
‘ s e z ione ‘ char (2 ) NOT NULL COMMENT ’ Sez ione ’ ,
‘ i d en t i t a ‘ varchar (32) NOT NULL COMMENT ’ Id en t i t a ’ ,
PRIMARY KEY ( ‘ idsge ‘ ) ,
KEY ‘ n ew fk cons t ra in t10 ‘ ( ‘ cod ruo lo ‘ ) ,
KEY ‘ n ew fk cons t ra in t11 ‘ ( ‘ p r o f i l o ‘ ) ,
KEY ‘ n ew fk cons t ra in t12 ‘ ( ‘ s t a t o ruo l o ‘ ) ,
KEY ‘ n ew fk cons t ra in t14 ‘ ( ‘ c a r r i e r a ‘ ) ,
KEY ‘ n ew fk cons t ra in t15 ‘ ( ‘ i n c a r i c h i ‘ ) ,
KEY ‘ n ew fk cons t ra in t16 ‘ ( ‘ aree ‘ ) ,
KEY ‘ n ew fk cons t ra in t17 ‘ ( ‘ s e t t o r e ‘ ) ,
KEY ‘ n ew fk cons t ra in t18 ‘ ( ‘ d ipart imento ‘ ) ,
KEY ‘ n ew fk cons t ra in t19 ‘ ( ‘ s e r v i z i o ‘ ) ,
KEY ‘ n ew fk cons t ra in t30 ‘ ( ‘ i d en t i t a ‘ ) ,
CONSTRAINT ‘ n ew fk cons t ra in t30 ‘ FOREIGN KEY ( ‘ i d en t i t a ‘ )
REFERENCES ‘IDENTITA‘ ( ‘ i d i d en t i t a ‘ ) ,
CONSTRAINT ‘ n ew fk cons t ra in t10 ‘ FOREIGN KEY ( ‘ cod ruo lo ‘ )
REFERENCES ‘CODICE RUOLO‘ ( ‘ s i g l a ‘ ) ,
CONSTRAINT ‘ n ew fk cons t ra in t11 ‘ FOREIGN KEY ( ‘ p r o f i l o ‘ )
REFERENCES ‘PROFILO‘ ( ‘ s i g l a ‘ ) ,
CONSTRAINT ‘ n ew fk cons t ra in t12 ‘ FOREIGN KEY ( ‘ s t a t o ruo l o ‘ )
REFERENCES ‘STATI RUOLO‘ ( ‘ s i g l a ‘ ) ,
CONSTRAINT ‘ n ew fk cons t ra in t14 ‘ FOREIGN KEY ( ‘ c a r r i e r a ‘ )
REFERENCES ‘CARRIERA‘ ( ‘ matr ico la ‘ ) ,
CONSTRAINT ‘ n ew fk cons t ra in t15 ‘ FOREIGN KEY ( ‘ i n c a r i c h i ‘ )
REFERENCES ‘INCARICHI ‘ ( ‘ s i g l a ‘ ) ,
CONSTRAINT ‘ n ew fk cons t ra in t16 ‘ FOREIGN KEY ( ‘ aree ‘ )
REFERENCES ‘AREA‘ ( ‘ s i g l a ‘ ) ,
CONSTRAINT ‘ n ew fk cons t ra in t17 ‘ FOREIGN KEY ( ‘ s e t t o r e ‘ )
REFERENCES ‘SETTORI‘ ( ‘ s i g l a ‘ ) ,
CONSTRAINT ‘ n ew fk cons t ra in t18 ‘ FOREIGN KEY ( ‘ d ipart imento ‘ )
REFERENCES ‘DIPARTIMENTI‘ ( ‘ s i g l a ‘ ) ,
CONSTRAINT ‘ n ew fk cons t ra in t19 ‘ 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=’ Ruol i r i c o p e r t i a l l i n t e rno 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 = @saved c s c l i e n t ;
−−−− Dumping data f o r t a b l e ‘RUOLO‘
68
−−
LOCK TABLES ‘RUOLO‘ WRITE;
/∗ !40000 ALTER TABLE ‘RUOLO‘ DISABLE KEYS ∗/ ;
/∗ !40000 ALTER TABLE ‘RUOLO‘ ENABLE KEYS ∗/ ;
UNLOCK TABLES;
−−−− Table s t r u c t u r e f o r t a b l e ‘SEDI ‘
−−
DROP TABLE IF EXISTS ‘SEDI ‘ ;
SET @saved c s c l i e n t = @@cha ra c t e r s e t 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 = ut f8 ;
CREATE TABLE ‘SEDI ‘ (
‘ cod ice ‘ char (6 ) NOT NULL COMMENT ’ Codice a 6 c i f r e d e l l e s ed i ’ ,
‘ d e s c r i z i on e ‘ varchar (32) NOT NULL COMMENT ’ Des c r i z i one per e s t e s o ’ ,
‘ i n d i r i z z o ‘ varchar (64) NOT NULL COMMENT ’ I n d i r i z z o d e l l a sede ’ ,
PRIMARY KEY ( ‘ cod ice ‘ )
) ENGINE=InnoDB DEFAULT CHARSET=l a t i n 1 COMMENT=’ Sedi d e l l Un ive 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 = @saved c s c l i e n t ;
−−−− Dumping data f o r t a b l e ‘SEDI ‘
−−
LOCK TABLES ‘SEDI ‘ WRITE;
/∗ !40000 ALTER TABLE ‘SEDI ‘ DISABLE KEYS ∗/ ;
/∗ !40000 ALTER TABLE ‘SEDI ‘ ENABLE KEYS ∗/ ;
UNLOCK TABLES;
−−−− Table s t r u c t u r e f o r t a b l e ‘SERVIZIO‘
−−
DROP TABLE IF EXISTS ‘SERVIZIO ‘ ;
SET @saved c s c l i e n t = @@cha ra c t e r s e t 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 = ut f8 ;
CREATE TABLE ‘SERVIZIO ‘ (
‘ s i g l a ‘ char (2 ) NOT NULL COMMENT ’ Codice per i l s e r v i z i o ’ ,
‘nome ‘ varchar (32) NOT NULL COMMENT ’ Des c r i z i one per e s t e s o ’ ,
‘ s e d e s e r v i z i o ‘ char (6 ) NOT NULL COMMENT ’ Sede de l s e r v i z i o ’ ,
PRIMARY KEY ( ‘ s i g l a ‘ ) ,
KEY ‘ n ew fk cons t ra in t8 ‘ ( ‘ s e d e s e r v i z i o ‘ ) ,
CONSTRAINT ‘ n ew fk cons t ra in t8 ‘ FOREIGN KEY ( ‘ s e d e s e r v i z i o ‘ )
REFERENCES ‘SEDI ‘ ( ‘ codice ‘ )
) 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 = @saved c s c l i e n t ;
−−−− Dumping data f o r t a b l e ‘SERVIZIO‘
69
−−
LOCK TABLES ‘SERVIZIO ‘ WRITE;
/∗ !40000 ALTER TABLE ‘SERVIZIO‘ DISABLE KEYS ∗/ ;
/∗ !40000 ALTER TABLE ‘SERVIZIO‘ ENABLE KEYS ∗/ ;
UNLOCK TABLES;
−−−− Table s t r u c t u r e f o r t a b l e ‘SETTORI‘
−−
DROP TABLE IF EXISTS ‘SETTORI ‘ ;
SET @saved c s c l i e n t = @@cha ra c t e r s e t 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 = ut f8 ;
CREATE TABLE ‘SETTORI‘ (
‘ s i g l a ‘ char (2 ) NOT NULL COMMENT ’ Codice de l s e t t o r e ’ ,
‘nome ‘ varchar (32) NOT NULL COMMENT ’ Des c r i z i one per 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 = @saved c s c l i e n t ;
−−−− Dumping data f o r t a b l e ‘SETTORI‘
−−
LOCK TABLES ‘SETTORI‘ WRITE;
/∗ !40000 ALTER TABLE ‘SETTORI‘ DISABLE KEYS ∗/ ;
/∗ !40000 ALTER TABLE ‘SETTORI‘ ENABLE KEYS ∗/ ;
UNLOCK TABLES;
−−−− Table s t r u c t u r e f o r t a b l e ‘SEZIONE‘
−−
DROP TABLE IF EXISTS ‘SEZIONE ‘ ;
SET @saved c s c l i e n t = @@cha ra c t e r s e t 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 = ut f8 ;
CREATE TABLE ‘SEZIONE‘ (
‘ s i g l a ‘ char (2 ) NOT NULL COMMENT ’ Codice per l e s e z i o n i ’ ,
‘nome ‘ varchar (32) NOT NULL COMMENT ’ Des c r i z i one per e s t e s o ’ ,
‘ s ed e s e z i one ‘ char (6 ) default NULL COMMENT ’ Sede d e l l a s e z i on e ’ ,
KEY ‘ n ew fk cons t ra in t9 ‘ ( ‘ s ede s e z i one ‘ ) ,
CONSTRAINT ‘ n ew fk cons t ra in t9 ‘ FOREIGN KEY ( ‘ s ede s e z i one ‘ )
REFERENCES ‘SEDI ‘ ( ‘ codice ‘ )
) ENGINE=InnoDB DEFAULT CHARSET=l a t i n 1 COMMENT=’ Se z i on i ’ ;
SET c h a r a c t e r s e t c l i e n t = @saved c s c l i e n t ;
−−−− Dumping data f o r t a b l e ‘SEZIONE‘
−−
70
LOCK TABLES ‘SEZIONE‘ WRITE;
/∗ !40000 ALTER TABLE ‘SEZIONE‘ DISABLE KEYS ∗/ ;
/∗ !40000 ALTER TABLE ‘SEZIONE‘ ENABLE KEYS ∗/ ;
UNLOCK TABLES;
−−−− Table 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 @saved c s c l i e n t = @@cha ra c t e r s e t 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 = ut f8 ;
CREATE TABLE ‘STATI RUOLO‘ (
‘ s i g l a ‘ char (2 ) NOT NULL COMMENT ’ Codice d e l l o s t a to de l ruo lo ’ ,
‘nome ‘ char (32) NOT NULL COMMENT ’ Des c r i z i one per 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 de l ruo lo ’ ;
SET c h a r a c t e r s e t c l i e n t = @saved c s c l i e n t ;
−−−− Dumping data f o r t a b l e ‘STATI RUOLO‘
−−
LOCK TABLES ‘STATI RUOLO‘ WRITE;
/∗ !40000 ALTER TABLE ‘STATI RUOLO‘ DISABLE KEYS ∗/ ;
/∗ !40000 ALTER TABLE ‘STATI RUOLO‘ ENABLE KEYS ∗/ ;
UNLOCK TABLES;
−−−− Table s t r u c t u r e f o r t a b l e ‘STATO‘
−−
DROP TABLE IF EXISTS ‘STATO‘ ;
SET @saved c s c l i e n t = @@cha ra c t e r s e t 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 = ut f8 ;
CREATE TABLE ‘STATO‘ (
‘nome ‘ varchar (32) NOT NULL COMMENT ’ ’ ’Nome per e s t e s o ’ ’ ’ ,
‘ cod i ce 2 ‘ char (2 ) NOT NULL COMMENT ’ ’ ’ Codice a 2 c a r a t t e r i ’ ’ ’ ,
‘ cod i ce 3 ‘ char (3 ) NOT NULL COMMENT ’ ’ ’ Codice a 3 c a r a t t e r i ’ ’ ’ ,
‘ codice IANA ‘ char (3 ) NOT NULL COMMENT ’ ’ ’ Codice IANA ’ ’ ’ ,
‘ codice ISTAT ‘ char (3 ) NOT NULL COMMENT ’ ’ ’ Codice ISTAT ’ ’ ’ ,
‘ c od i c e a g en z i a en t r a t e ‘ char (3 ) NOT NULL
COMMENT ’ ’ ’ Codice d e l l ’ ’ Agenzie d e l l e Entrate ’ ’ ’ ,
PRIMARY KEY ( ‘ nome ‘ )
) ENGINE=InnoDB DEFAULT CHARSET=l a t i n 1 COMMENT=’ S t a t i s ov ran i ’ ;
SET c h a r a c t e r s e t c l i e n t = @saved c s c l i e n t ;
−−−− Dumping data f o r t a b l e ‘STATO‘
−−
71
LOCK TABLES ‘STATO‘ WRITE;
/∗ !40000 ALTER TABLE ‘STATO‘ DISABLE KEYS ∗/ ;
/∗ !40000 ALTER TABLE ‘STATO‘ ENABLE KEYS ∗/ ;
UNLOCK TABLES;
−−−− Table 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 @saved c s c l i e n t = @@cha ra c t e r s e t 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 = ut f8 ;
CREATE TABLE ‘TIPO CORSO‘ (
‘ codice ‘ char (2 ) NOT NULL COMMENT ’ Codice a 2 c a r a t t e r i ’ ,
‘nome ‘ varchar (32) NOT NULL COMMENT ’ Tipo per e s t e s o ’ ,
PRIMARY KEY ( ‘ cod ice ‘ )
) ENGINE=InnoDB DEFAULT CHARSET=l a t i n 1 COMMENT=’ Tipo d i co r so d i l au r ea ’ ;
SET c h a r a c t e r s e t c l i e n t = @saved c s c l i e n t ;
−−−− Dumping data f o r t a b l e ‘TIPO CORSO‘
−−
LOCK TABLES ‘TIPO CORSO‘ WRITE;
/∗ !40000 ALTER TABLE ‘TIPO CORSO‘ DISABLE KEYS ∗/ ;
/∗ !40000 ALTER TABLE ‘TIPO CORSO‘ ENABLE KEYS ∗/ ;
UNLOCK TABLES;
−−−− Table 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‘ ;
SET @saved c s c l i e n t = @@cha ra c t e r s e t 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 = ut f8 ;
CREATE TABLE ‘TITOLO ONORIFICO‘ (
‘ codice ‘ int (11) NOT NULL COMMENT ’ Codice numerico incrementa l e ’ ,
‘nome ‘ varchar (32) NOT NULL COMMENT ’Nome de l t i t o l o o n o r i f i c o ’ ,
PRIMARY KEY ( ‘ cod ice ‘ )
) ENGINE=InnoDB DEFAULT CHARSET=l a t i n 1
COMMENT=’ Ti to l o o n o r i f i c o d e l l e I d en t i t a ’ ;
SET c h a r a c t e r s e t c l i e n t = @saved c s c l i e n t ;
−−−− Dumping data f o r t a b l e ‘TITOLO ONORIFICO‘
−−
LOCK TABLES ‘TITOLO ONORIFICO‘ WRITE;
/∗ !40000 ALTER TABLE ‘TITOLO ONORIFICO‘ DISABLE KEYS ∗/ ;
/∗ !40000 ALTER TABLE ‘TITOLO ONORIFICO‘ ENABLE KEYS ∗/ ;
UNLOCK TABLES;
72
/∗ !40103 SET TIME ZONE=@OLD TIME ZONE ∗/ ;
/∗ !40101 SET SQL MODE=@OLD SQL MODE ∗/ ;
/∗ !40014 SET FOREIGN KEY CHECKS=@OLD FOREIGN KEY CHECKS ∗/ ;
/∗ !40014 SET UNIQUE CHECKS=@OLD UNIQUE CHECKS ∗/ ;
/∗ !40101 SET CHARACTER SET CLIENT=@OLD CHARACTER SET CLIENT ∗/ ;
/∗ !40101 SET CHARACTER SET RESULTS=@OLD CHARACTER SET RESULTS ∗/ ;
/∗ !40101 SET COLLATION CONNECTION=@OLD COLLATION CONNECTION ∗/ ;
/∗ !40111 SET SQL NOTES=@OLD SQL NOTES ∗/ ;
−− Dump completed on 2009−02−03 16:32 :22
73
Appendice C
Istruzioni per importare il
database dallo script
Per provare il DB (attraverso il dump dell’appendice B e ovviamente necessario innanzi-tutto scaricare 1 ed installare MySQL (sulla macchina in cui e stato provato, con sistemaoperativo Ubuntu 8.10, la procedura e veramente banale2) e successivamente da shelldigitare:
• 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
1All’indirizzo http://dev.mysql.com/downloads/mysql/5.1.html sono presenti i download per laversione 5.1 di MySQL
2Basta 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 deiserver database, 2007.
[3] Giulio Destri. Introduzione ai sistemi informativi aziendali. Monte UniversitaParma 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.
[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 autho-rization 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
