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

Agenda Introduzione Il TDR: Core Services Uno sguardo in avanti

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

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

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

Agenda Introduzione Il TDR: Core Services Uno sguardo in avanti

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

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

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

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

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

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

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

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)

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

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

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

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

Hardware

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

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: 37600 (28K già assegnati, 10K chiesti per la prossima riunione di CCR)

Alcuni approfondimenti GOVA HA-WAN DIT

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

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).

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

GOVA: i tempi

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)

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

Esempio di una entry dn: infnUUID=6e4b0a83-4067-4966-a4c1-5d4797114fef, ou=People, dc=infn, dc=it telephoneNumber: +390694032214 postalAddress: Via Enrico Fermi, 40 - 00044 FRASCATI infnKerberosPrincipal: dmaselli@LNF.INFN.IT 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: 6e4b0a83-4067-4966-a4c1-5d4797114fef 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: dael.maselli@lnf.infn.it

Agenda Introduzione Il TDR: Core Services Uno sguardo in avanti

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)

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

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

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