Architettura del Directory Service...

Seminario Ingegneria

Bologna, 2/03/2006

Architettura del Directory ServiceD’Ateneo

Alessandro Cantelli

Architettura del Directory Service D’Ateneo – Bologna, xx/xx/xxxx

• Introduzione ai sistemi di Identity Management e Directory Service

• Struttura logica e fisica della Directory d’Ateneo

• Evoluzione temporale del progetto

• Ambienti di lavoro (sviluppo e produzione) e loro evoluzione

• Microsoft Identity Integration Server

• Flussi di dati gestiti

Agenda


• Si è sentita la necessità di un unico sistema di Autenticazione/Autorizzazione che permettesse di identificare e profilare tutte le risorse umane presenti in Ateneo (Personale Docente e Tecnico Amministrativo, Studenti, Collaboratori, Ospiti, etc.), superando le difficoltà introdotte dall’esistenza di più anagrafiche e più metodi eterogenei per la gestione dell’accesso alle risorse informatiche.

• Un unico sistema di autenticazione consente di applicare semplicemente politiche sicure nella gestione delle credenziali, in ottemperanza a quanto previsto dall’Allegato B del D.Lgs. 196/03 e di favorire l’utente che deve ricordarsi solo una coppia di credenziali per accedere a più risorse

Identity Management System


• Elevato numero di risorse da gestire in Ateneo• Esistenza di elenchi e metodi eterogenei per la

gestione delle risorse• Esigenza di realizzare un unico elenco organizzato

coerente, certificato, aggiornato, contestuale, utilizzabile ovunque e fruibile per diverse esigenze di tutte le risorse. In particolare per le persone interessa rendere disponibile tutta una serie di informazioni tra cui quelle anagrafiche, l’email, i numeri di telefono e fax ed altri dati, insieme alla loro appartenenza a unità operative che compongono l’organizzazione, secondo quanto viene descritto nell’organigramma dell’organizzazione stessa

• Architettura distribuita scalabile e versatile

Perché un Directory Service?


• Scelta tecnologica orientata agli standard• Lo standard più diffuso, per l’implementazione di

Directory Service, è l’X.500 dell’InternationalTelecommunications Union (ITU)

• La prima versione risale al 1988, a cui ne è seguita una nel 1993

• Approccio distribuito: più repository di informazioni locali ad ogni singola organizzazione, detti Directory System Agent, si scambiano informazioni con altri Directory System Agent mediante il protocollo Directory System Protocol e sono organizzati in maniera gerarchica secondo il Directory InformationTree

Standard X.500


Es. Distinguished Name di Alessandro Cantelli

cn=Alessandro Cantelli,ou=SeRTA,ou=CeSIA,dc=personale,dc=dir,dc=unibo,dc=it

Directory Information Tree (DIT)

Root

dc=it dc=ch dc=edu

dc=unibo dc=garr dc=cern dc=mit

dc=dir

dc=personale dc=studenti

ou=CeSIA ou=CS

ou=SeRTA

cn=Alessandro Cantelli

cn=Aldo Schiavina


• I Directory System Agent sono accessibili mediante l’interfaccia offerta dai cosiddetti Directory User Agent (DUA).

• Un DUA accede alla Directory mediante il Directory Access Protocol (DAP)

• DAP si basa, secondo lo standard X.500, sulla pila di protocolliOSI standard, risultando quindi intrinsecamente pesante e di scarsa diffusione

• E’ stato allora progettato un protocollo più leggero, che consentisse l’uso di X.500 su Internet, basato quindi sulla suite di protocolli TCP/IP.

• Tale protocollo è stato chiamato Lightweight Directory Access Protocol (LDAP) e standardizzato dalla IETF (Internet Engineering Task Force) prima con la RFC 1487 nel 1993, poi con la successiva RFC 1777 nel 1995 (LDAP v2) ed, infine, con la RFC2251 (LDAP v3) nel 1997.

DAP vs LDAP


• Ambiti serviti:– Portale– AlmaWelcome– Posta Studenti @studio.unibo.it (presso Cineca)– Posta Dipendenti @unibo.it (basato su Exchange)– Biblioteche universitarie– Laboratori ed aule informatiche– Ospedale universitario Sant’Orsola-Malpighi– Convenzione con le biblioteche comunali

Directory Service di Ateneo (DSA)


• http://www.unibo.it• https://www.dsa.unibo.it• http://mail.unibo.it• https://posta.studio.unibo.it• https://www.almawelcome.unibo.it

Demo Ambito Serviti


• Le risorse gestite sono:• 3.500 utenti del personale docente; 3.500

docenti a contratto• 3.500 utenti del personale tecnico-

amministrativo• 10.000 dottorandi• 220.000 studenti; 4.000 laureati frequentatori• 1.000 ospiti dell’Ateneo• 600.000 gruppi di sicurezza per la profilazione• 10.000 unità organizzative• 6.000 risorse informatiche• Eventuali risorse aggiuntive locali

I numeri della directory (DSA)


• Dati anagrafici• Afferenza (Facoltà e Dipartimento)• Incarichi

– per autorizzare l’accesso a risorse o gestire le mailing list automatiche (p. es. [email protected])

• Corsi tenuti• Account personale per:

– posta elettronica– accesso a risorse informatiche– eventuali ulteriori utilizzi, anche locali

Personale docente


• Dati anagrafici• Struttura d’appartenenza• Incarichi

– es. per autorizzare l’accesso a risorse o gestire le mailing list automatiche (p.es. [email protected])

• Account per – posta elettronica– accesso alla propria Workstation

• Accesso ad applicazioni informatiche finalizzate al supporto del proprio lavoro

Personale tecnico amministrativo


• Dati anagrafici• Corso di Laurea• Account per:

• posta elettronica• utilizzo risorse informatiche in laboratori• Portale

• Eventuali applicazioni informatiche finalizzate alla didattica/ricerca

Studenti


• È stata creata una piattaforma comune per l’integrazione di informazioni a partire da sei diverse anagrafiche in una unica base di dati distribuita per tutto l’Ateneo; è in corso un’attività di integrazione nell’ambito dell’«Anagrafica unica»

• Nell’ultima esportazione completa della directory per l’aggiornamento del dominio studenti erano presenti più di un milione di oggetti

Integrazione


strutturastrutturastruttura

dir

studenti

personale

lettere

PoloForli

PoloRimini

PoloCesena

hq stat

Struttura logica


323GHOOD

URPDJQD

323GHOOD

URPDJQD

Architettura Fisica


Early phases

Analisi

studenti.local

Test

dir.unibo.it

studenti.dir.unibo.it

personale.dir.unibo.it

2001 | 2002 | 2003 | 2004 | 2005 | 2006

Broker & DB

web directory browserWebServices per l’integrazione delle applicazioniListe di distribuzione Docenti - Studenti

MIISNuova infrastruttura AD Windows 2003

WS security e WS federation

Adeguamento anagrafica unica

Evoluzione Temporale del Progetto DSA


• Sono stati realizzati tre ambienti di lavoro:– Sviluppo (SMALL LAB)– Test (BIG LAB)– Produzione

Ambienti di lavoro


A cosa serve:•Ambiente isolato•Prove funzionali, non di carico

6 4 / � 6HUYHU0 ,,6�' DWDEDVH

0 ,,6�

0 ,,6%,* / $ %

Y&3 8 �±� 5 0 � * E

: LQGRZ V�

Active DirectoryWindows 2003 MigratoWindows 2003 MigratoAmbiente Virtuale

Ambienti di sviluppo


Ambiente di produzione


•MIIS script

Cluster Ms SqlServer 2005Broker2k5

Evoluzione dell’ambiente di produzione


• Il progetto di implementazione di un identitymanagement ha un impatto sostanziale con l’organizzazione

• È un progetto di lungo respiro, e va comunque affrontato a fasi

• Le priorità della struttura non sono sempre sotto controllo, quindi lo strumento deve essere flessibile (idem per le persone!)

• È fondamentale l’affidabilità del prodotto e il supporto fornito dal produttore con la SP1

Esperienze maturate


• l’IdM scelto è MIIS (Microsoft Identity Integration Server)• Originariamente era stata sviluppata una versione

prototipale con strumenti di programmazione tradizionale• La versione prototipale è stata usata anche nei primi anni di

funzionamento, creando molti problemi di gestione e prestazionali (a causa del numero limitato di persone in grado di operarvi e della mole di dati interessata)

• Era necessario andare su sistemi di mercato (e quindi supportati), scalabili e che permettessero di liberare le risorse specializzate dei progettisti originali

• L’analisi del mercato ha mostrato che questo prodotto era adeguato alle esigenze descritte– l’alternativa era proseguire lo sviluppo in casa di un

sistema analogo, con costi difficilmente controllabili e rischi industriali maggiori

Perché MIIS


Legenda

Codice custom

Management Agent MIIS

database di produzione

Personale

Studenti

DsaPreiscritti e

Preaccreditati

ADAM 1 ADAM x

AgentiDsa

Flussi gestiti


• I dati anagrafici e organizzativi vengono acquisiti dai database di produzione nel database Dsa

• In Dsa vengono normalizzate alcune informazioni (per esempio i numeri telefonici vengono trascritti in un formato omogeneo) e vengono aggiunti alcuni dati specifici estranei alle esigenze dei database di produzione:– informazioni utente (logon, password, ecc.)– contatti (numeri telefonici, email, url)– alias di posta elettronica e informazioni utili per la

gestione di exchange– liste gestite (per i docenti)– informazioni utili alla profilazione per il portale, per la

posta elettronica e per le autorizzazioni utente

Il flusso di aggiornamento, fase 1


• I dati vengono acquisiti nella directory partendo dal database Dsa tramite Miis

• Per facilitare l’utilizzo di Miis, il flusso informativo ha richiesto l’introduzione di un database intermedio (AgentiDsa) che si occupa della normalizzazione delle informazioni in un formato predisposto per questo uso

• Miis permette anche di restituire alcune informazioni dalla directory al database:– ultima data di accesso dell’utente– informazioni di posta elettronica gestite

direttamente con Exchange



• Per alcune applicazioni si è preferito non intervenire direttamente sulla directory (deputata all’attività di autenticazione), ma utilizzare degli AD/AM (Active Directory Application Mode)

• Un AD/AM permette di duplicare parte della directory per usi applicativi con la possibilità di gestire informazioni accessorie

• L’aggiornamento dell’AD/AM per i dati derivati dalla directory viene svolto automaticamente da IIFP (IdentityIntegration Feature Pack)

• Attualmente l’uso principale di AD/AM e IIFP è relativo al sistema Cip (controllo ingresso persone) che permette di dotare biblioteche, laboratori, parcheggi di sistemi di controllo delle autorizzazioni per l’accesso fisico degli utenti



• Per alcuni flussi informativi vi sono delle ulteriori fasi che devono essere eseguite

• In particolare, due flussi (quello dei preimmatricolati e quello dei preaccreditati) richiedono che l’aggiornamento della directory sia immediato

• Per questo motivo i due flussi descritti fanno riferimento a un web service che aggiorna contemporaneamente (ovvero, in un’unica transazione) sia i database interessati sia la directory

Flussi aggiuntivi


Gestione dei preimmatricolati


UserCreation

Gestione dei preaccreditati


Domande?

Architettura del Directory Service...

Documents

Transcript of Architettura del Directory Service...