Architettura di INFN-AAI Plus Enrico M. V. Fasanelli Tutorial INFN-AAI Plus CNAF Dicembre 2010

Architettura Hardware: IAM GODiVA Due DB server Oracle in configurazione RAC (in questo momento, in realtà il tutto si basa su un unico DB server in una macchina virtuale) Due Application Server su cluster di Apache Tomcat su due macchine virtuali (il numero di nodi del cluster può aumentare a piacere per soddisfare le esigenze dei Job) Load-Balancer (effettuato dal router Cisco) CNAF Dicembre 2010Architettura di INFN-AAI Plus - Enrico M. V. Fasanelli - Tutorial AAI Plus2

Architettura Hardware: AAI LDAP Tre 389-DS master server e su macchine virtuali Due 389 slave server LNF e CNAF) entrambi raggiungibili come ds.infn.it Kerberos5 Due slaveKDC-containers e pronti per ricevere i DB di autenticazione dei vari REALM CNAF Dicembre 2010Architettura di INFN-AAI Plus - Enrico M. V. Fasanelli - Tutorial AAI Plus3

Architettura di GODiVA

Il flusso dei dati: Anagrafica dei Dipendenti Il DataBase autoritativo per le anagrafiche dei Dipendenti (in senso lato) è quello della Direzione degli Affari del Personale (adesso diretta da Eleonora Bovo) dell’Amministrazione Centrale. È (ad oggi) il modulo HR di una installazione delle Oracle Enterprise Businnes Suite (Oracle Application) della Direzione Affari del Personale che è la base dati utilizzata dallo stipendiale (SIPERT) Ad oggi, questi dati popolano la parte Dipendenti del modulo HR del Sistema Informativo Ad oggi, i dati che vengono copiati in GODiVA provengono dal Sistema Informativo. CNAF Dicembre 2010Architettura di INFN-AAI Plus - Enrico M. V. Fasanelli - Tutorial AAI Plus5

GODiVA Blocks OU=People,DC=INFN,DC=IT CNAF Dicembre 2010Architettura di INFN-AAI Plus - Enrico M. V. Fasanelli - Tutorial AAI Plus6

Il flusso dei dati Anagrafica dei Dipendenti Da notare che ci sono due sincronie dal momento in cui una Identità viene inserita nell’HR del “payroll” a quando tale anagrafica è disponibile in GODiVA-DB C’è un ritardo (ma non è poi un guaio così grave) C’è sempre una “serie di operazioni” che vengono eseguite in HR del Sistema Informativo prima che tali dati vengano resi disponibili a GODiVA-DB I soli dati anagrafici dei Dipendenti sono, per GODiVA, in sola lettura (una qualunque modifica verrebbe resettata dalla successiva sincronia) CNAF Dicembre 2010Architettura di INFN-AAI Plus - Enrico M. V. Fasanelli - Tutorial AAI Plus7

GODiVA o GOVA? GODiVA ha accesso read-only solo ai dati anagrafici ed amministrativi (essenzialmente quelli legati ai contratti) dei Dipendenti. Usa tali dati per le gestioni dei ruoli, dei permessi, ecc. che poi scrive anche nel Directory Server di INFN-AAI Gestisce l’assegnazione di un UUID per ogni Identità (anche per i Dipendenti) Gestisce il provisioning di default (NetworkAccess) CNAF Dicembre 2010Architettura di INFN-AAI Plus - Enrico M. V. Fasanelli - Tutorial AAI Plus8

Il flusso dei dati: Anagrafica degli Associati Il workflow informatizzato relativo alle associazioni è di gestito dal Servizio Coordinamento Banche Dati e Ricerca (DataWeb) Fino alla scorsa estate, DataWeb utilizzava esclusivamente un proprio DB MySQL Dal 19 Agosto 2010, la parte dei dati anagrafici degli Associati è stata portata in GODiVA-DB (l’accesso è garantito via GODiVA-API) I dati anagrafici relativi agli Associati vengono poi forniti al Sistema Informativo attraverso una sincronia periodica CNAF Dicembre 2010Architettura di INFN-AAI Plus - Enrico M. V. Fasanelli - Tutorial AAI Plus9

GODiVA Blocks OU=People,DC=INFN,DC=IT CNAF Dicembre 2010Architettura di INFN-AAI Plus - Enrico M. V. Fasanelli - Tutorial AAI Plus10

La logica di GODiVA-Engine GODiVA svolge il suo lavoro trattando con: Dominio Identità RuoloAnagrafica Servizio CNAF Dicembre 2010Architettura di INFN-AAI Plus - Enrico M. V. Fasanelli - Tutorial AAI Plus11

Dominio I domini sono nodi all’interno di strutture ad albero suddivise alla radice per tipologie. Istituzioni Organigramma Gruppi Scientifici Conferenze CNAF Dicembre 2010Architettura di INFN-AAI Plus - Enrico M. V. Fasanelli - Tutorial AAI Plus12

Identità Le identità sono definite dalle informazioni anagrafiche di un individuo. Includono dati complessi come ad esempio una scansione di un documento di riconoscimento o il certificato X.509 Per ogni identità è possibile definire infiniti dettagli ed associarli anche a domini differenti CNAF Dicembre 2010Architettura di INFN-AAI Plus - Enrico M. V. Fasanelli - Tutorial AAI Plus13

RuoloAnagrafica In GODiVA i RuoliAnagrafica definiscono la relazione tra: Identità Dominio Range temporale di validità Ruolo (qualifica definita per la tipologia dell’albero a cui il nodo di Dominio appartiene) CNAF Dicembre 2010Architettura di INFN-AAI Plus - Enrico M. V. Fasanelli - Tutorial AAI Plus14

Servizio La creazione di un servizio avviene relativamente ad un dominio. Questa serve a definire quali attributi e la relativa posizione dove devono essere materializzati sul server LDAP. I servizi sono definiti nel modo seguente: Descrizione Dominio di materializzazione Attributo per abilitazione all'uso del servizio Lista objectclass Lista entitlement CNAF Dicembre 2010Architettura di INFN-AAI Plus - Enrico M. V. Fasanelli - Tutorial AAI Plus15

Provisioning Una volta che il servizio è definito, è necessario effettuare l’operazione di provisioning che consiste nel valorizzare l’insieme di attributi necessari al suo utilizzo. Il provisioning di un servizio può essere associato All’Identità Al Dominio Al Ruolo Al Ruolo all’interno di un solo Dominio CNAF Dicembre 2010Architettura di INFN-AAI Plus - Enrico M. V. Fasanelli - Tutorial AAI Plus16

Provisioning all’Identità È un caso molto particolare di assegnazione di un servizio (normalmente si accede ad un servizio in quanto si ricopre un determinato ruolo) In questo caso si specifica una istanza che conterrà anche i limiti temporali di validità del provisioning stesso Es. posso abilitare Claudio Bisegni all’utilizzo di GODiVA CNAF Dicembre 2010Architettura di INFN-AAI Plus - Enrico M. V. Fasanelli - Tutorial AAI Plus17

Provisioning al Dominio Operazione che descrive un servizio per un determinato Dominio. Il servizio cosi descritto verrà ereditato da tutte le identità che hanno un qualsiasi Ruolo per uno specifico dominio, per tutta la durata descritta nel relativo RuoloAnagrafica. Es. posso abilitare all’uso del tornello posto vicino all’edificio Alte Energie, tutte le Identità che sono legate ai LNF CNAF Dicembre 2010Architettura di INFN-AAI Plus - Enrico M. V. Fasanelli - Tutorial AAI Plus18

Provisioning al Ruolo Operazione che descrive un servizio per un determinato Ruolo. Il servizio cosi descritto verrà ereditato da tutte le identità che hanno uno specifico Ruolo per un qualsiasi dominio, per tutta la durata descritta nel relativo RuoloAnagrafica Es. posso abilitare l’accesso alla rete wireless via 802.1x a tutti i Dipendenti ed Associati CNAF Dicembre 2010Architettura di INFN-AAI Plus - Enrico M. V. Fasanelli - Tutorial AAI Plus19

Provisioning al Operazione che descrive un servizio per un determinato Ruolo su un determinato Dominio. Il servizio cosi descritto verrà ereditato da tutte le identità che hanno uno specifico Ruolo per uno specifico Dominio, per tutta la durata descritta nel relativo RuoloAnagrafica. Es. posso abilitare l’uso del parcheggio di Roma2 ai soli Dipendenti di Roma2 CNAF Dicembre 2010Architettura di INFN-AAI Plus - Enrico M. V. Fasanelli - Tutorial AAI Plus20

De-Provisioning I servizi il cui provisioning è assegnato all’Identità, vengono rimossi in modo automatico dalla lista di servizi a cui l’utente può accedere, solo se associati ad una istanza con definita validità temporale (alla scadenza della validità). Es. un direttore può permettere ad un dipendente di accedere temporaneamente (magari in sostituzione del titolare) ad un servizio che normalmente è assegnato ad un ruolo, senza assegnare il ruolo (perché magari la cosa richiederebbe una modifica dell’organigramma e quindi una delibera del Direttivo) o prima che il ruolo venga ufficializzato. CNAF Dicembre 2010Architettura di INFN-AAI Plus - Enrico M. V. Fasanelli - Tutorial AAI Plus21

De-Provisioning Nei casi di servizi il cui provisioning è collegato al Ruolo (o Dominio o nel momento in cui una Identità non è più associata a tale Ruolo (o Dominio o perde anche il diritto di accedere al servizio. Ad ogni variazione di questo tipo, GODiVA ricalcola la lista dei servizi a cui l’utente ha diritto di accedere, in base ai Ruoli che egli ricopre. CNAF Dicembre 2010Architettura di INFN-AAI Plus - Enrico M. V. Fasanelli - Tutorial AAI Plus22

La gestione dei privilegi di accesso (IAM) La gestione delle autorizzazioni è capillare e multi- dominio. Es. un ufficio di segreteria di una sede X che svolge anche funzioni di segreteria per, ad esempio, una Commissione Nazionale, potrà avere accesso completo a tutti i dati relativi alle persone della sede X, ma solo alcuni dati (in questo caso solo ai dati relativi alla Commissione Nazionale in considerazione) di alcune persone (delle sole persone che afferiscono a tale Commissione Nazionale) appartenenti a tutte le altre sedi. CNAF Dicembre 2010Architettura di INFN-AAI Plus - Enrico M. V. Fasanelli - Tutorial AAI Plus23

GODiVA & INFN-AAI GODiVA è da un lato, l’applicazione che serve per gestire le Identità, i ruoli e le autorizzazioni e registra questi dati nel Directory Server di INFN-AAI la prima applicazione INFN-AAI compliant, nel senso che usa direttamente le informazioni presenti in INFN-AAI per i processi di Autenticazione ed Autorizzazione CNAF Dicembre 2010Architettura di INFN-AAI Plus - Enrico M. V. Fasanelli - Tutorial AAI Plus24

Entitlements Gli Entitlements sono i diritti che l’utente ha nei riguardi dell’azione che si vuole compiere. Sono informazioni che devono essere lette un numero elevato di volte (ogni volta che l’applicazione dovrà effettuare una operazione per conto dell’utente) e che non cambiano di frequente. Il supporto migliore per memorizzarle è quindi una Directory Il formato deve identificare in modo univoco l’azione all’interno dell’applicazione, eventualmente limitata ad un dominio CNAF Dicembre 2010Architettura di INFN-AAI Plus - Enrico M. V. Fasanelli - Tutorial AAI Plus25

eduPersonEntitlement (ePE) eduPersonEntitlement è un attributo multi-valore della objectClass eduPerson I valori sono in formato URN (Uniform Resource Name) che hanno un formato del tipo urn:mace:infn.it: dove è una “Namespace Specific String” come definita nell’RFC2141, non case sensitive. Es. diritto di modifica del numero telefonico urn:mace:infn.it:IAM:gestioneAnagrafica:modifica:num eroTelefono CNAF Dicembre 2010Architettura di INFN-AAI Plus - Enrico M. V. Fasanelli - Tutorial AAI Plus26

Provisioning & Entitlement Il provisioning di una applicazione, ossia l’assegnazione del diritto di utilizzo dell’applicazione stessa, avviene definendo un opportuno valore dell’attributo schacUserStatus (schac sta per SCHema for ACcademia ed è uno schema definito da una Task-Force di TERENA) urn:mace:terena.org:schac:UserStatus:it:infn.it:{Applic azione}:enable CNAF Dicembre 2010Architettura di INFN-AAI Plus - Enrico M. V. Fasanelli - Tutorial AAI Plus27

Architettura di INFN-AAI

Architettura del Directory Server La struttura ideale per il Directory Information Tree è, come oramai riconosciuto ed affermato da tutti gli esperti, di tipo “basso e grosso” (e non più “alto e magro” come si consigliava una ventina d’anni fa) La “posizione” di una entità all’interno della struttura organizzativa non viene definita dal suo DN, ma dal valore di attributi specifici DN:UID=enrico,OU=People,DC=LE,DC=INFN,DC=IT DN:UID=enrico,DC=INFN,DC=IT L: LE CNAF Dicembre 2010Architettura di INFN-AAI Plus - Enrico M. V. Fasanelli - Tutorial AAI Plus29

Gestione del pre-installato “Dio ci ha messo 7 giorni per creare il mondo perché non doveva gestire il pre-installato” Riportare tutte le strutture dell’INFN all’interno di un albero “basso e grosso” è una impresa che va oltre le possibilità di INFN-AAI (basti pensare alla gestione delle omonimie…) CNAF Dicembre 2010Architettura di INFN-AAI Plus - Enrico M. V. Fasanelli - Tutorial AAI Plus30

INFN-AAI DIT Sovrapposizione dei due modelli Ramo nazionale e rami locali CNAF Dicembre 2010Architettura di INFN-AAI Plus - Enrico M. V. Fasanelli - Tutorial AAI Plus31

Directory e Relazioni Una Directory è un Data Base ad albero. Non è possibile definire, usando i normali sistemi di gestione delle Directory, nessuna relazione tra le entry Per INFN-AAI è invece essenziale poter mettere in relazione le entry relative al “pre-installato” che sono all’interno dei rami locali, con le corrispondenti entry relative alle identità, che vivono nel ramo nazionale CNAF Dicembre 2010Architettura di INFN-AAI Plus - Enrico M. V. Fasanelli - Tutorial AAI Plus32

GODiVA-Engine Quando viene inserita una Identità nel GODiVA-DB, GODiVA-Engine genera una UUID e la assegna in modo permanente a tale Identità valorizzando l’attributo infnUUID La corrispondente entry nel ramo nazionale della Directory ha come RDN tale UUID (le entry sono opache) dn:infnUUID=f8d35e c8-989c- 3faa58f5cba4,ou=People,dc=infn,dc=it Nel momento in cui in un ramo locale “compare” una entry legata a tale Identità, GODiVA valorizza l’attributo infnLinkedUUID mettendoci il valore di infnUUID CNAF Dicembre 2010Architettura di INFN-AAI Plus - Enrico M. V. Fasanelli - Tutorial AAI Plus33

L’importanza del Codice Fiscale Entry nel ramo nazionale dn:infnUUID=f8d35e c8- 989c- 3faa58f5cba4,ou=People,dc=infn,dc=it uid: enrico infnUUID:f8d35e c8-989c- 3faa58f5cba4 infnLinkedUUID:f8d35e c8- 989c-3faa58f5cba4 sn:Fasanelli givenName:Enrico Maria schacPersonalUniqueID:urn:mace:teren a.org:schac:personalUniqueID:it:CF:FS NNCM61R19B619J l: LE Entry nel ramo locale dn:infnUUID=020f41f5-913a-425f-bb91- aaea40739ff7,ou=People,dc=le,dc=infn,dc =it infnLinkedUUID:f8d35e c8- 989c-3faa58f5cba4 infnUUID: 020f41f5-913a-425f-bb91- aaea40739ff7 schacPersonalUniqueID:urn:mace:terena. org:schac:personalUniqueID:it:CF:FSNNC M61R19B619J uid: enrico cn: Enrico M V Fasanelli givenName: Enrico M V sn: Fasanelli CNAF Dicembre 2010Architettura di INFN-AAI Plus - Enrico M. V. Fasanelli - Tutorial AAI Plus34

Tutto passa da GODiVA La necessità di tenere sincronizzate le entry nazionali con le corrispondenti entry locali obbliga a passare da un sistema che tenga memoria di queste relazioni (in un DB relazionale, appunto) e le “materializzi” in un formato pseudo-relazionale nella Directory Questo però rallenta il passaggio ad INFN-AAI perché alcune parti importanti di GODiVA devono ancora essere sviluppate CNAF Dicembre 2010Architettura di INFN-AAI Plus - Enrico M. V. Fasanelli - Tutorial AAI Plus35

Accesso ai dati (ACI) Oltre alle ACI di default (che permettono al proprietario delle informazioni di vedere qualunque informazione gli appartenga) abbiamo ristretto la possibilità di lettura L’accesso non autenticato permette di leggere il valore dei soli attributi: cn, givenName, sn, mail L’accesso autenticato permette di leggere tutti gli attributi, ad esclusione di schacPersonalUniqueID e userPassword CNAF Dicembre 2010Architettura di INFN-AAI Plus - Enrico M. V. Fasanelli - Tutorial AAI Plus36

Accesso ai server (SSL/TLS) I Directory Server di INFN-AAI sono configurati in modo da dover utilizzare per forza una connessione cifrata Rispondono sulla porta 389, ma esigono che la connessione diventi cifrata (via STARTTLS) Rispondono anche (solo per compatibilità con vecchi client perché è “deprecated”) sulla porta 636 ldaps CNAF Dicembre 2010Architettura di INFN-AAI Plus - Enrico M. V. Fasanelli - Tutorial AAI Plus37

F I N E Architettura di INFN-AAI Plus Enrico M. V. Fasanelli Tutorial INFN-AAI Plus