INFN-AAI Technical Design Report

Presentazione sul tema: "INFN-AAI Technical Design Report"— Transcript della presentazione:

1 INFN-AAI Technical Design Report
Enrico M.V. Fasanelli Dael Maselli Silvia Arezzini

2 Agenda Introduzione Il TDR: Core Services Uno sguardo in avanti

3 Review del CDR & INFN-AAI
La review del CDR ha dato origine a 2 tipi di azioni Rapida (ma precisa) valutazione di alcuni consigli --> addendum1 al CDR Promessa di rimandi al TDR Autorizzazione/Gruppi/Ruoli: IAM Struttura del DIT Robustezza (operatività locale), Disaster Recovery Implementazione di IdP SAML e federazioni PKI & VOMS

4 Review del CDR & CCR I “compiti” per la CCR erano:
Coinvolgimento del management IAM Man-power specialmente per Windows

5 TDR modulare Nel CDR (+addendum) erano chiaramente indicate le risorse necessarie per proseguire le attività. Le risorse non si sono liberate, ma abbiamo voluto continuare ugualmente. L’unico modo per farlo era di dividere il lavoro relativo al TDR in moduli Questo modulo descrive i servizi del nucleo di INFN-AAI

6 Agenda Introduzione Il TDR: Core Services Uno sguardo in avanti

7 TDR: Core Services Il supporto per IAM: GOVA Autenticazione
Autorizzazione Backup & Disaster Recovery Schema Applicazioni Web ed IdP SAML Specifiche Hardware

8 IAM Due pezzi di IAM Definizione legale/amministrativa della gestione delle Identità e dei diritti di accesso (non solo a sistemi informatici) Workflow dell’acquisizione e gestione dei dati personali Workflow del [de-]provisioning di diritti Strumento informatico che implementi quanto sopra

9 IAM & GOVA Gestione Ospiti Visitatori ed Associati
Eredita dalla Gestione Visitatori Implementa una parte nuova di Gestione Ospiti Ingloba la parte di Gestione Associati, ora fatta da DataWeb Importa dati dei dipendenti presi da HR

10 Autenticazione Come definito nel CDR saranno supportati Kerberos5
Certificati X.509 Coppia username/password importate dal mondo unix (solo per il periodo di tempo necessario per la transizione a Kerberos5) Password importate nel server LDAP e usate per bind LDAP Migrazione a Kerberos5 via plug-in

11 Autorizzazione Autorizzazione suddivisa in 2 livelli:
appartenenza ad un gruppo / ruolo diritto sulla risorsa, entitlement La maggior parte delle applicazioni permetto di esternalizzare la gestione dei gruppi ma NON gli entitlements Tuttavia i nuovi sistemi e applicazioni home-made iniziano ad utilizzare LDAP anche per la gestione degli entitlement

12 Autorizzazione (gruppi)
Ci sono varie strutture per rappresentare i gruppi in un sistema LDAP (group, groupOfUniqueNames,…) Per assicurarci la compatibilità con tutte le strutture GOVA gestirà l’appartenenza ai gruppi e li inserirà in LDAP nelle varie modalità supportate Utilizzando una struttura opportuna dei nomi come infn.ccr.members, lnf.computing.members o user.dmaselli.friends sarà possibile una gestione personalizzata dei vari gruppi

13 Autorizzazione (entitlements)
Per le applicazioni che ne potranno fare uso verranno gestite le autorizzazioni di accesso alle risorse tramite opportuni entitlements nelle entry degli utenti urn:mace:infn.it:entitlement:gova:visitors:admi urn:mace:infn.it:entitlement:dataweb:preventivi:cn:ccr:aai:writer potranno derivare in modo automatico dall’appartenenza ad un gruppo o essere associati staticamente ai singoli utenti

14 Backup & Disaster Recovery
Grazie ad un plug-in scritto appositamente per 389DS saranno tracciate tutte le modifiche alla directory Questo permetterà di effettuare un rollback ad ogni istante nella storia dei dati Utile anche per conoscere ad esempio lo stato di una entry ad un certo point-in-time Chiunque sia autorizzato potrà effettuare autonomamente tali operazioni (sempre via GOVA)

15 Schema Lo schema delle objectClass è stato studiato per rispettare al massimo gli standard e seguire le linee guida di organizzazioni come Internet2 o TERENA per garantire l’interoperabilita’ e lo scambio di conoscenze con realta’ esterne all’ente E’ in fase di definizione una objectClass infnPerson per alcuni attributi che non hanno trovato posto nelle objectClass standard, SCHAC o eduPerson

16 Applicazioni Web Ad oggi quasi tutte le applicazioni sono accessibili via web Internet2 ha sviluppato un protocollo per la gestione delle AA per il web: SAML 2.0 Consente di ottenere il Single Sign On Evita che le credenziali transitino attraverso le applicazioni Permette la federazione di AAI di più istituti

17 Applicazioni Web (SAML 2.0)
Il sistema si basa su due componenti L’Identity Provider (IdP) è un server web che controlla le autenticazioni e gestisce le informazioni di autorizzazione degli utenti di un singolo istituto (idp.infn.it) Con Service Provider si intende un’applicazione a cui si chiede un servizio

18 Applicazioni Web (SAML 2.0)
Utente: tramite browser, accede al SP SP: ridirige il browser verso l’IdP IdP: identifica l’utente tramite login IdP: crea una assertion, ossia un pacchetto XML firmato RSA contente le informazioni dell’utente IdP: ridirige il browser verso il SP allegando in una l’assertion SP: controlla la firma RSA e applica le autorizzazioni necessarie all’utente

19 Hardware

20 Specifiche Hardware Totale 14 macchine Hardware 3 Oracle DB
3 Application Server 4 Directory Server 4 Kerberos5 KDC 1 CPU 4-core RAM 8GB Alimentatore ridondato 2x1GB Ethernet Scheda RAID Write back cache >= 256MB 3+ HDD 15Krpm RAID 1 + hot spare Standard rack mount 19” HBA Fibre Channel, solo per 2 macchine Oracle DB LNF

21 Costi dell’Hardware Da una offerta di E4 del 5/6/2009
1 CPU 4-core, RAM 8GB, Alimentatore ridondato, 2x1GB Ethernet, Scheda RAID (Write back cache = 256MB), 3+HDD 15Krpm (RAID 1 + hot spare), Standard rack mount 19”, IPMI: 2150+IVA *12=30960 2 con HBA FC: 5220+IVA=6264 Totale: (28K già assegnati, 10K chiesti per la prossima riunione di CCR)

22 Alcuni approfondimenti
GOVA HA-WAN DIT

23 GOVA: prima fase Creazione Database GOVA Porting Associati su GOVA
Sviluppo Gestione degli Ospiti

24 GOVA: seconda fase Adattamento di GOVA per autenticare e autorizzare via LDAP (AAI) Implementazione del protocollo AAI per scrivere su LDAP (AAI) in java (API) Gestione delle autorizzazioni di una anagrafica in GOVA (usando il framework definito al punto precedente).

25 GOVA: terza fase Analisi Workflow IAM
Modifica di GOVA per la gestione dei workflow e per la gestione delle autorizzazioni per le anagrafiche.

26 GOVA: i tempi

27 GOVA: HA-WAN Il sistema GOVA, così come disegnato è un elemento critico di tutta la INFN-AAI. Per garantire la continuità del servizio si è pensato ad una configurazione in HA sia su LAN, che su WAN. Rimane da verificare quale modalità di HA (si sta pensando ad Heartbeat su una VLAN VPLS condivisa dalle 2 sedi. In teoria dovrebbe rispondere alle specifiche richieste, ma non si la si è ancora provata)

28 DIT MIX (In medio stat virtus) di due modelli
Accesso in scrittura, controllato Solo GOVA GOVA o LDAP

29 Esempio di una entry dn: infnUUID=6e4b0a a4c1-5d fef, ou=People, dc=infn, dc=it telephoneNumber: postalAddress: Via Enrico Fermi, FRASCATI infnKerberosPrincipal: schacPersonalPosition: Collaboratore Tecnico E.R. memberOf: cn=infn.csn.ccr.esperimento.aai.resploc.lnf.membri, ou=Groups, dc=infn, dc=it memberOf: cn=infn.csn.ccr.esperimento.webtools.respnaz.membri, ou=Groups, dc=infn, dc=it memberOf: cn=infn.csn.ccr.esperimento.webtools.resploc.lnf.membri, ou=Groups, dc=infn, dc=it memberOf: cn=Calcolo, ou=Groups, dc=lnf, dc=infn,dc=it uid: dmaselli infnUUID: 6e4b0a a4c1-5d fef schacPersonalUniqueID: urn:mace:terena.org:schac:personalUniqueID:it:CF:MSLDLA81B27H501C sn: Maselli givenName: Dael cn: Maselli Dael l: LNF eduPersonEntitlement: urn:mace:infn.it:entitlement:iam:gova:visitors:write eduPersonEntitlement: urn:mace:infn.it:entitlement:iam:gova:dipendenti:read+dc=lnf,dc=infn,dc=it eduPersonEntitlement: urn:mace:infn.it:entitlement:prenotazioneaule:lnf:write mail:

30 Agenda Introduzione Il TDR: Core Services Uno sguardo in avanti

31 Altri moduli del TDR - I IAM
Definizione dei workflow ed integrazione dei workflow in GOVA Definizione del DOcumento delle Procedure di Accreditamento degli Utenti (DOPAU) necessario per aderire alle federazioni di AAI (progetto IDEM del GARR)

32 Altri moduli del TDR - II
Implementazione di INFN-AAI nelle sedi Analisi dei vari scenari ed esame sede per sede, con indicazioni specifiche Aggiornamento dello schema con le classi di oggetti necessarie alle esigenze locali

33 Altri moduli del TDR - III
Integrazione con Windows Necessaria, ma serve almeno una persona dedicata

34 Altri moduli del TDR - IV
PKI & VOMS Lo scorso anno sembrava una grosso capitolo, ma alla luce di quanto detto al WS INFN-GRID, sembra che VOMS vada nella direzione di SAML