Architettura di INFN-AAI Plus Enrico M. V. Fasanelli Tutorial INFN-AAI Plus CNAF Marzo 2012

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 Marzo 2012Architettura 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 Marzo 2012Architettura 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 Marzo 2012Architettura di INFN-AAI Plus - Enrico M. V. Fasanelli - Tutorial AAI Plus5

GODiVA Blocks OU=People,DC=INFN,DC=IT CNAF Marzo 2012Architettura 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 Marzo 2012Architettura 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 Marzo 2012Architettura 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 Marzo 2012Architettura di INFN-AAI Plus - Enrico M. V. Fasanelli - Tutorial AAI Plus9

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

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 Marzo 2012Architettura di INFN-AAI Plus - Enrico M. V. Fasanelli - Tutorial AAI Plus11

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 Marzo 2012Architettura di INFN-AAI Plus - Enrico M. V. Fasanelli - Tutorial AAI Plus12

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 Marzo 2012Architettura di INFN-AAI Plus - Enrico M. V. Fasanelli - Tutorial AAI Plus13

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 Marzo 2012Architettura di INFN-AAI Plus - Enrico M. V. Fasanelli - Tutorial AAI Plus14

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 Marzo 2012Architettura di INFN-AAI Plus - Enrico M. V. Fasanelli - Tutorial AAI Plus16

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 Marzo 2012Architettura di INFN-AAI Plus - Enrico M. V. Fasanelli - Tutorial AAI Plus17

INFN-AAI DIT Sovrapposizione dei due modelli Ramo nazionale e rami locali CNAF Marzo 2012Architettura di INFN-AAI Plus - Enrico M. V. Fasanelli - Tutorial AAI Plus18

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 Marzo 2012Architettura di INFN-AAI Plus - Enrico M. V. Fasanelli - Tutorial AAI Plus19

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 Marzo 2012Architettura di INFN-AAI Plus - Enrico M. V. Fasanelli - Tutorial AAI Plus20

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 Marzo 2012Architettura di INFN-AAI Plus - Enrico M. V. Fasanelli - Tutorial AAI Plus21

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ò ha rallentato il passaggio ad INFN-AAI perché alcune parti importanti di GODiVA dovevano ancora essere sviluppate CNAF Marzo 2012Architettura di INFN-AAI Plus - Enrico M. V. Fasanelli - Tutorial AAI Plus22

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 Marzo 2012Architettura di INFN-AAI Plus - Enrico M. V. Fasanelli - Tutorial AAI Plus23

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 Marzo 2012Architettura di INFN-AAI Plus - Enrico M. V. Fasanelli - Tutorial AAI Plus24

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