I punti cardine dell'architettura di INFN-AAI risiedono nell'implementazione e nell'uso di un sistema allo stesso tempo solido e flessibile di autenticazione e autorizzazione. A suo tempo, gli strumenti software scelti per la realizzazione dell'architettura INFN-AAI furono kerberos 5 (autenticazione) e ldap (autorizzazione). Si trattava e si tratta ancora oggi di ottime soluzioni software, utilizzate in numerosi contesti, anche per infrastrutture piu' grandi e complesse del nostro ente. Ma la particolarissima conformazione dell' INFN, caratterizzato da necessita' sia di tipo centralizzato che di tipo fortemenente localizzato su sede, fin dall' inizio indirizzo' i gestori dell' infrastruttura verso realizzazioni non tradizionali nel panorama delle implementazioni di infrastrutture AA. La stesura del CDR alla quale molti di noi hanno partecipato ne fu una chiara testimonianza. In particolare fin dall' inizio ci si rese conto che la presenza di un unico sistema centrale di autenticazione e autorizzazione avrebbe costituito una base certamente solida per le richieste del momento e per gli sviluppi futuri, ma di sicuro non cosi' flessibile come invece si desiderava per renderla utilizzabile in maniera funzionale per ogni sede. La via che ne segui' fu una via di compromesso che ancora oggi ci accompagna nel cammino di implementazione di AAI. Per l'autorizzazione si verifico' che l'uso di ldap articolato su ramo nazionale e rami locali avrebbe potuto costituire una buona risposta, grazie alla presenza di implementazioni software (389 Directory Server) capaci della necessaria flessibilita' pur mantenendo l'integrita' di un sistema unico. Per l'autenticazione invece si evidenziarono da subito numerosi problemi, in particolare legati al fatto che solo poche sedi avevano esperienza di kerberos (in particolare esistevano solo alcune celle afs con gestori locali esperti). L'analisi che segue e' riferita alla possibilita' che oggi abbiamo di realizzare un unico dominio/realm INFN a cui tutti possano agganciarsi. E' vero ci sono pro e contro, ma si tratta di una possibilita' concreta, verificata e tale da poter essere implementata in tempi rapidi. Costituendo, comunque, una novita', si ritiene corretta una gradualita' che ne veda la traduzione operativa articolata in fasi successive.

In particolare dobbiamo tenere conto di alcuni fattori importanti:

1) Al momento NON tutti usano kerberos5 per la autenticazione. Come si sa infatti, al fine di permettere a tutto l'ente l' aggancio ad un sistema unico, e' permesso mantenere username e password all'interno di ldap. Questa soluzione e' TEMPORANEA. Non permette di unificare le password per l'accesso ai servizi nazionali con quelle per l'accesso ai servizi di sede, pur mantenendo la stessa username, e questo è spesso fonte di incomprensioni e difficoltà di utilizzo di INFN-AAI.

2) L'infrastruttura AAI dell'ente deve essere rivolta alla realizzazione anche del Single Sign On. Si tratta di una richiesta non solo ragionevole per i nostri tempi, ma anche essenziale per la realizzazione di funzionalita' avanzate indispensabili per un buon funzionamento degli strumenti informatici diponibili, in particolare per le attivita' di Office Automation nelle quali siamo oggi in generale piuttosto arretrati.

3) Il permanere di INFN-AAI in uno stato di proto-implementazione non ne favorisce l'uso evoluto che invece viene praticato in molte altre organizzazioni internazionali. Questo uso passa attraverso canali istituzionali che oggi sono finalmente presenti, basti pensare infatti alla recente istituzione di un ufficio AAI alll'interno della divisione informatica dell' Amministrazione Centrale. E' certo pero' che occorrono risorse di personale dedicate e preparate in questo campo specifico prima di poter procedere ad una implementazione effettiva e rivolta a tutto il personale.

La proposta e' pertanto la seguente:

Ci sono ad oggi fondamentalmente due possibilita': A) versione UNICO e SOLO: implementazione di UN UNICO REALM INFN.IT a cui tutti devono agganciarsi B) versione MISTA: implementazione di una soluzione con un unico realm INFN.IT comunque presente e funzionante e con realm locali manutenuti dalle singole sedi.

Il programma di passaggio a kerberos per tutto l'ente potrebbe quindi essere il seguente:

- studio sempre piu' approfondito dei meccanismi e degli strumenti di gestione di un unico realm INFN.IT anche alla luce delle considerazioni che emergono nel seguito di questo documento; - mantenimento dello status-quo almeno sino a fine anno 2012 e programma di passaggio a KERBEROS5 con una delle due soluzioni (UNICO e SOLO oppure MISTO) a partire da gennaio 2013, con presentazione della relativa proposta nell' ottobre 2012 (riunione di CCR di inizio ottobre); - indirizzamento delle sedi che desiderano passare all'autenticazione kerberos5 verso la soluzione realm unico, comunque gia' esistente ed operativo. E' possibile comunque, per le sedi che lo desiderassero, provvedere al setup di un dominio separato, con la consapevolezza, pero' che in futuro potrebbe essere presa la decisione di passare a unico realm. - mantenimento delle sedi con realm locale nella situazione attuale, studiando nel frattempo adeguati meccanismi di migrazione che impattino il minimo indispensabile sugli utenti.

E' chiaro, da questa introduzione, che come piu' volte detto in occasioni pubbliche, si ritiene migliore la soluzione realm unico, pur avendo la piena consapevolezza della necessita' di un opportuno servizio nazionale che ne curi il funzionamento, la sicurezza e gli aggiornamneti. L'unica cosa certa e' che un realm nazionale DEVE esistere, al fine di garantire a tutti, anche a coloro che non hanno esperti locali, di far funzionare per i propri utenti l'infrastruttura INFN AAI. Pertanto una parte della discussione e' superflua. Il realm nazionale deve esserci e deve funzionare bene. Se poi riusciremo ad avere solo quello sara' anche meglio, ma questa puo' essere anche una soluzione a lungo termine.

INFN-AAI prevede che il sistema principale di autenticazione via coppia username/password per gli utenti INFN sia basato su Kerberos5

L'architettura inizialmente proposta prevedeva un realm nazionale INFN.IT (che avrebbe dovuto essere il contenitore delle relazioni di fiducia con i realm locali xxx.INFN.IT) ed un realm per ogni sede.

I realm di sede erano previsti essenzialmente per la presenza di celle locali OpenAFS

Il lavoro di Sandro Angius, presentato al WS europeo di OpenAFS del 2009 http://www.dia.uniroma3.it/~afscon09/ mostra come sia possibile agganciare una cella AFS locale al realm nazionale INFN.IT

L'implementazione di kcrap all'interno di TRIP permette di utilizzare il protocollo PEAP-MSCHAPv2 anche con back-end kerberos (vedi presentazione di Sandro Angius al WS CCR-GARR 2012 http://agenda.infn.it/conferenceOtherViews.py?view=standard&confId=4801)

Questo, insieme al lavoro di "renaming" delle username locali (che renderà univoche tutte le username all'interno dell'INFN) apre la strada verso un unico realm INFN.IT

SUGGERIMENTO: ad oggi Kerberos e' fortemente legato ad AFS. Proporrei una discussione interna a tutto il gruppo AFS-INFN (…a meno che tutti i partecipanti non siano gia' stati inclusi in questa discussione) (D.Anzellotti)

1-Il database è replicato su siti geograficamente lontani, quindi è resistente ad eventi distruttivi.(Domenico Diacono)

2-Nel caso di problemi sulla rete locale della sezione, è ancora possibile autenticarsi sui servizi nazionali (AAI). (Domenico Diacono)

3- L'autenticazione TRIP avviene localmente anche per i 'viaggiatori' escludendo vari point of failure rappresentati dalla connettivita` alla sede remota e quindi al radius di appartenenza oltre che al radius-hub che smista le richieste di autenticazione tra le varie sedi; permette inoltre un troubleshooting piu` agevole. (Alessandro Tirel)

3a- Utilizzando il sistema di cui al punto 3 (con kcrap), inoltre, la configurazione del client wireless e' semplificata, grazie all'utilizzo di PEAP-MSCHAPv2 (nativo in tutti i sistemi) (D.Anzellotti)

4- Consente l'utilizzo del principal nazionale dell'utente per l'accesso alle farm di calcolo scientifico (farm di esperimento, Tier vari): il nodo di login puo' essere configurato per appartenere ad un solo REALM kerberos per volta. Configurandolo come appartenente al REALM nazionale si potranno utilizzare i principal nazionali gia' esistenti di tutti gli utenti INFN. (D.Anzellotti)

5- Lo Slave di sede potrebbe essere fornito direttamente dal gruppo di gestione del REALM nazionale, magari come macchina virtuale. Questo farebbe si' che non sia piu' indispensabile un expertise specifico (ed aggiornato!) su gestione/installazione di server Kerberos in ogni sede. (D.Anzellotti)

6- Facilita la strada verso una ulteriore ottimizzazione delle risorse, consentendo di pianificare altri eventuali servizi nazionali (eg: posta elettronica) (D.Anzellotti)

1- Il lavoro di “renaming” delle username locali, con conseguente aggiornamento dei database LDAP, NIS, pts, dei file passwd su sistemi linux e di qualunque altro documento dove appaiano le vecchie username (acl dei piu` disparati CMS, /etc/sudoers, sshd_config, …..) non dovrebbe essere un lavoro difficile ma sara` di sicuro estremamente laborioso, soprattutto dove il Servizio Calcolo e Reti e` sottodimensionato rispetto alle esigenze della sede. (Stefano Stalio - LNGS)

2- Il database nazionale dovra` essere replicato su circa 50 slave (almeno due per sede). Ci saranno 50 host sparsi per tutto l'INFN, gruppi collegati compresi, a rischio di essere bucati e dai quali il db potrebbe essere “rubato” e scansionato con calma con strumenti come JtR. Con conseguenze potenzialmente gravi. (Stefano Stalio - LNGS)

3- La percentuale degli utenti che troverebbe giovamento da un REALM kerberos unico per tutto l'INFN e` probabilmente bassa: sarebbero soprattutto i dipendenti ed associati “girovaghi” che viaggiano spesso in altri sedi INFN per lavoro. I dipendenti e gli associati “stanziali”, i membri stranieri delle collaborazioni sperimentali che dell'INFN conoscono solo il laboratorio che ospita il loro esperimento, gli studenti di fisica che usano le risorse della sezione collegata al loro dipartimento non hanno nessun vantaggio a potersi autenticare in luoghi dove forse non andranno mai o ad accedere a risorse informatiche di cui nemmeno conoscono l'esistenza. (Stefano Stalio - LNGS)

1- Il passaggio ad unico REALM kerberos per l'INFN deve per forza essere subordinato alla creazione di un team di supporto dedicato composto di personale assunto con contratto a tempo indeterminato che garantisca tempi di risposta minimi e disponibilita` paragonabile a quella del GARR NOC. (Stefano Stalio - LNGS)

2- E` indispensabile definire a chi spetta la gestione dei principal (creazione, eliminazione, disabilitazione, cambio forzato della password): ad un'autorita` centrale? alle sezioni di afferenza? chi definisce a quale sezione afferisce un utente? (Stefano Stalio - LNGS)

3- Slave server kerberos con kcrap in ogni sede (D.Anzellotti)

4- Il gruppo di gestione (sia esso interno o "esternalizzato") deve garantire almeno lo stesso tipo di risposta che abbiamo ora per i servizii nazionali AFS/Kerberos (D.Anzellotti)

5- E' necessario pensare a come consentire ai servizi di calcolo i cui utenti utilizzano AFS l'accesso privilegiato allo spazio disco, per permettere azioni mirate all'ottimizzazione dei servizi offerti (eg: creazione/modifica del file .forward nelle home directory dei propri utenti) (D.Anzellotti)

6- L'eventuale presenza di software aggiuntivi "fatti in casa" per la gestione degli utenti richiede che il team di sviluppo sia composto di un congruo numero di dipendenti INFN con contratto a tempo indeterminato che garantiscano il mantenimento e l'aggiornamento di tali software nel lungo periodo. (Stefano Stalio - LNGS)

7-La gestione dei principal deve essere in qualche modo slegata dalla gestione delle utenze AAI, in quanto sono presenti principal collegati ad host e servizi che non hanno corrispondenza nell'albero ldap (Domenico Diacono)

1 - La sede locale agisce sui propri account senza dipendere da risposte di un team di supporto nazionale. Come con il DNS il sistema ha una gerarchia. Le policy vengono decise localmente. (M. Michelotto)

2 - Si facilita la migrazione degli account locali LDAP ad un real K5 nel caso in cui una sede volesse utilizzare K5 anche per servizi forniti da LDAP. (M. Michelotto)

1-Il database K5 è soggetto a poche modifiche nel tempo, causate principalmente da modifica delle password e aggiunta di nuovi utenti. Le macchine sono soggette a scarso traffico, non impegnano risorse, e tipicamente non pongono problemi di sorta nel funzionamento quotidiano. Questo vuol dire che, al contrario di quanto accade ad esempio per i sistemi di posta elettronica, è possibile che un server K5 funzioni per anni senza problemi e senza necessità di aggiornamenti. Nel momento in cui però è necessario aggiornarlo l'operazione può essere complicata o impossibile per il servizio calcolo, che nel frattempo può avere del tutto o in parte perso le competenze necessarie. Lo stesso discorso vale per AFS. (Domenico Diacono)

2- Spesso all'interno del Servizio Calcolo e Reti manca il tempo per mantenere i server kerberos aggiornati, ben configurati ed in sicurezza. (Stefano Stalio - LNGS)