INFN-AAI architettura del sistema e strategia di implementazione

INFN-AAI architettura del sistema e strategia di implementazione Enrico M.V. Fasanelli INFN - sezione di Lecce Riunione comitato di revisione progetto AAI Firenze 21-22 maggio 2008

Agenda A&A nell INFN Anatomia della INFN-AAI Strategia di implementazione Un primo prodotto : la protoaai 2

A&A nell INFN Nell ultimo anno sono state effettuate due indagini per il censimento dei sistemi di Autenticazione ed Autorizzazione in uso nelle sedi dell INFN Due risultati interessanti Sono in uso nell INFN praticamente tutti i possibili sistemi di AA Nell ultimo anno c è stato un aumento delle sedi che utilizzano LDAP 3

Esempio: la posta elettronica Il sistema più gettonato è quello basato su file locali ai server, ma non mancano Kerberos, LDAP, NIS. C è anche una sede che basa l Autenticazione su Windows AD AUTENTICAZIONE Sistemi di Autenticazione in uso nelle sedi INFN per l accesso ai servizi di posta elettronica 4

Esempio: la posta elettronica Come per l Autenticazione, sono usati praticamente tutti i sistemi. Non presente nel grafico (ma implementato in alcune sedi) c è l autorizzazione basata su certificati X.509 (per l uso dei server SMTP) AUTORIZZAZIONE Sistemi di Autorizzazione in uso nelle sedi INFN per l accesso ai servizi di posta elettronica 5

Distribuzione dell Autenticazione 6

Distribuzione dell Autorizzazione 7

Anatomia della INFN-AAI Quali vincoli ci hanno portato a definire la struttura della INFN-AAI Autenticazione, Autorizzazione ed architetturali Le componenti funzionali della INFN-AAI Le condizioni al contorno che hanno influito sulla definizione dell architettura. 9

Autenticazione: i vincoli (1) Kerberos5 È usato in circa un terzo delle sedi. È indispensabile per tutte le sedi che basano i propri servizi su OpenAFS Autenticazione Unix (hash MD5, SHA-1, ) Servizi di login, posta, web Informazioni distribuite via NIS, LDAP 10

Autenticazione: i vincoli (2) Certificati X.509 Accesso a GRID Accesso ad applicazioni web (non solo locali) Accesso a server SMTP 11

I servizi centralizzati (1) DataWeb Fornisce servizi via applicazioni Web, per le quali le due fasi di Autenticazione ed Autorizzazione sono gestite da un software home-made. List-server (SYMPA) Supporta autenticazione via certificati X.509 ed LDAP Supporta autorizzazione (per l accesso e per la configurazione di mailing-list) via LDAP 12

I servizi centralizzati (2) TRIP Basato su Proxy RADIUS. Il server RADIUS utilizzato, può demandare Autenticazione ed Autorizzazione ad un server LDAP 13

Autorizzazione: vincoli? Di fatto tutte le applicazioni in uso nell INFN possono usare LDAP per l autorizzazione Ma le sedi che usano LDAP hanno scelto tutte configurazioni differenti Questo non è un problema, ma implica, per ognuna di queste sedi un impegnativo lavoro per l implementazione definitiva. 14

Architettura: vincoli! Autoconsistenza in ogni sede Non dipendenza dalla connettività di rete Possibilità di estendere la AAI per esigenze locali (es. dipartimenti di fisica) Tutte le informazioni vicino ai servizi centralizzati. Accesso autenticato al sistema stesso (ACI) Fault-tolerant 15

Anatomia funzionale della INFN-AAI Autenticazione Kerberos, ma non solo Autorizzazione LDAP 16

non solo Kerberos Oltre all autenticazione attraverso Kerberos la INFN-AAI permetterà anche l utilizzo di certificati X.509 e, in una prima fase transitoria, degli hash di password ereditati dal mondo Unix. 17

Anatomia di INFN-AAI: LDAP DC=INFN,DC=IT DC=LNF, DC=LE, DC=PI, DC=NA, DC=BA, DC=INFN,DC=IT DC=LNF, DC=INFN,DC=IT 4 server di core Multi-Master Server di periferia 18

Anatomia di INFN-AAI: Kerberos LNF.INFN.IT LE.INFN.IT BA.INFN.IT PI.INFN.IT XX.INFN.IT LNF.INFN.IT LE.INFN.IT KDC KDC KDC XX.INFN.IT KDC Xen KDC Farm KDC periferici 19

Strategia di implementazione Due obiettivi: Permettere una implementazione graduale (fornire uno strumento utilizzabile da subito sia dai servizi centralizzati che dalle sedi man mano che esse abbracceranno la INFN- AAI) Migrazione il più indolore possibile per le sedi 21

Implementazione graduale L architettura con core e periferia permette il dispiegamento della INFN-AAI in fasi successive. I servizi centralizzati potranno utilizzare la INFN-AAI non appena essa sarà popolata (anche con informazioni parziali prese da protoaai) Le sedi avranno, una volta migrate, tutte le funzionalità della INFN-AAI a disposizione 22

Migrazione indolore Esistono strumenti consolidati che permettono il popolamento di un albero LDAP a partire da informazioni tipiche del mondo Unix (NIS o passwd file) È previsto il supporto per la traduzione delle informazioni delle sedi che usano LDAP Sarà possibile importare (in modo completamente trasparente per l utente finale) le password Unix nei KDC Kerberos 23

Le sedi dell INFN Buona parte delle sedi (circa una metà) avranno a disposizione uno strumento di installazione che permetterà loro di passare in pochi giorni alla INFN-AAI. A parte la configurazione di tutti i servizi locali Per le sedi che usano LDAP dovrà essere studiata una implementazione ad sedem. Per la configurazione dei servizi locali, in questi casi, basterà cambiare i server LDAP di riferimento 24

Personale (1) I membri del gruppo AAI-WG hanno acquisito notevole esperienza nel corso dell ultimo anno È importante che il nucleo del futuro AAI-WG possa avvalersi di tali esperienze Sarà comunque necessario fornire supporto per le sedi Implementazione ad sedem per le sedi che usano LDAP Trasferimento di conoscenze a tutte le sedi Sarà necessario individuare e dedicare in modo esclusivo a tale attività, almeno 3 tecnici, oltre ad un gruppo di gestione del progetto, che costituirà il nucleo dell AAI-WG 25

Personale (2) Per il primo anno di lavoro, sarà necessario che il gruppo AAI-WG sia formato da un nucleo di gestione formato da: 1FTE staff con funzioni di responsabile (eventualmente suddiviso su due persone) per il coordinamento delle attività 1FTE staff con riconosciute capacità tecniche che operi alle dipendenze dei coordinatori 1.2FTE staff tecnico (20% del tempo di 6 persone del gruppo AAI-WG) Un pool tecnico 3FTE (3 tecnici dedicati) 26

Milestones Il dispiegamento della INFN-AAI, potrà essere verificato in tre momenti: β-test ed R&D Fase pilota Fase di produzione All interno della quale si potranno individuare anche un ulteriore paio di momenti di verifica 27

protoaai (1) I servizi offerti da DataWeb si basano su autenticazione via CASSiO ed autorizzazione basata su un DB SQL "interno". I nuovi servizi che DataWeb si accinge a fornire (come ad esempio moodle, ma non solo) richiederebbero l'ausilio di una Directory LDAP. È stato implementato un Servizio di Directory quasi-conforme al modello INFN-AAI, per permettere una sostituzione a caldo protoaai INFN-AAI 29

protoaai (2) Differenze rispetto ad INFN-AAI 2 server di core (entrambi ai LNF) Autenticazione via LDAP Compatibilità con l attuale sistema di Autenticazione basato su DB SQL 30