Architettura del Directory Service D Ateneo Alessandro Cantelli

Transcript

1 Architettura del Directory Service D Ateneo Alessandro Cantelli Seminario Ingegneria Bologna, 2/03/2006

2 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

3 Identity Management System 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

4 Perché un Directory Service? 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 , 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

5 Standard X.500 Scelta tecnologica orientata agli standard Lo standard più diffuso, per l implementazione di Directory Service, è l X.500 dell International Telecommunications 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 Information Tree

6 Directory Information Tree (DIT) Es. Distinguished Name di Alessandro Cantelli cn=alessandro Cantelli,ou=SeRTA,ou=CeSIA, dc=personale,dc=dir,dc=unibo,dc=it 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=aldo Schiavina cn=alessandro Cantelli

7 DAP vs LDAP 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 protocolli OSI 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 RFC 2251 (LDAP v3) nel 1997.

8 Directory Service di Ateneo (DSA) Ambiti serviti: Portale AlmaWelcome Posta (presso Cineca) Posta (basato su Exchange) Biblioteche universitarie Laboratori ed aule informatiche Ospedale universitario Sant Orsola-Malpighi Convenzione con le biblioteche comunali

9 Demo Ambito Serviti

10 Le risorse gestite sono: I numeri della directory (DSA) utenti del personale docente; docenti a contratto utenti del personale tecnicoamministrativo dottorandi studenti; laureati frequentatori ospiti dell Ateneo gruppi di sicurezza per la profilazione unità organizzative risorse informatiche Eventuali risorse aggiuntive locali

11 Personale docente Dati anagrafici Afferenza (Facoltà e Dipartimento) Incarichi per autorizzare l accesso a risorse o gestire le mailing list automatiche (p. es. FacStat.preside@unibo.it) Corsi tenuti Account personale per: posta elettronica accesso a risorse informatiche eventuali ulteriori utilizzi, anche locali

12 Dati anagrafici Struttura d appartenenza Incarichi es. per autorizzare l accesso a risorse o gestire le mailing list automatiche (p.es. FacLing.personale@unibo.it) Account per Personale tecnico amministrativo posta elettronica accesso alla propria Workstation Accesso ad applicazioni informatiche finalizzate al supporto del proprio lavoro

13 Studenti Dati anagrafici Corso di Laurea Account per: posta elettronica utilizzo risorse informatiche in laboratori Portale Eventuali applicazioni informatiche finalizzate alla didattica/ricerca

14 Integrazione È 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

15 Struttura logica dir studenti personale hq stat lettere Polo Forli Polo Cesena Polo Rimini struttura struttura struttura

16 Architettura Fisica 32 3 GHOD 32 3 GHOD URP DJQD URP DJQD

17 Evoluzione Temporale del Progetto DSA Early phases Analisi studenti.local Test dir.unibo.it Broker & DB studenti.dir.unibo.it personale.dir.unibo.it web directory browser WebServices per l integrazione delle applicazioni Liste di distribuzione Docenti - Studenti MIIS Nuova infrastruttura AD Windows 2003 WS security e WS federation Adeguamento anagrafica unica

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

19 Ambienti di sviluppo A cosa serve: Ambiente isolato Prove funzionali, non di carico Active Directory Windows 2003 Migrato Ambiente Virtuale 0,,6 64/6HUYHU 0,,6'DWDEDVH : LQGRZV 0,,6%,* /$% Y&38±50 *E

20 Ambiente di produzione

21 Evoluzione dell ambiente di produzione MIIS script Broker2k5 Cluster Ms SqlServer 2005

22 Esperienze maturate Il progetto di implementazione di un identity management 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

23 Perché MIIS 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

24 Flussi gestiti Personale Studenti database di produzione Dsa Preiscritti e Preaccreditati AgentiDsa Legenda Codice custom ADAM 1 ADAM x Management Agent MIIS

25 Il flusso di aggiornamento, fase 1 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, , 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

26 Il flusso di aggiornamento, fase 2 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

27 Il flusso di aggiornamento, fase 3 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 (Identity Integration 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

28 Flussi aggiuntivi 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

29 Gestione dei preimmatricolati

30 Gestione dei preaccreditati UserCreation

31 Domande?