INFN wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
----

^ Versione      ^ Data      ^ Autore                 ^     Note                     ^ 
| [[cn:ccr:aai:k5:k5-d09|DRAFT-0.9]] | 4-2-2012  | Enrico M.V. Fasanelli  | Prima versione per la CCR    | 
| DRAFT-0.91     | 4-2-2012  | Enrico M.V. Fasanelli  | Aggiunto paragrafo "Aspetti in comune"    | 

----


====== K5 @ INFN ======

===== Executive summary =====

==== Il contesto ====
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.

Gli strumenti software scelti per la realizzazione dell'architettura INFN-AAI sono Kerberos (autenticazione) e LDAP (autorizzazione) che sono soluzioni architetturali standard, utilizzate in numerosi contesti, anche per infrastrutture più grandi e complesse del nostro ente.

La particolarissima conformazione dell'INFN, caratterizzato da necessità sia di tipo centralizzato che di tipo fortemente localizzato su sede, ha richiesto un disegno non tradizionale nel panorama delle implementazioni di infrastrutture AA.

In particolare, riguardo il sistema di autenticazione, nonostante fosse evidente dall'inizio che un unico sistema centrale avrebbe costituito una base certamente solida per le richieste del momento e per gli sviluppi futuri, alcune considerazioni relative ai sistemi in produzione (come ad esempio lo strettissimo legame che il sistema Kerberos nazionale in produzione ha con il servizio nazionale AFS, la mancanza di un sistema di gestione adeguato alle necessità di partizionamento e distribuzione dell'amministrazione del REALM e l'autonomia gestionale dei REALM Kerberos e celle AFS locali) hanno portato alla proposta di architettura Kerberos per l'INFN formulata nel Documento di Disegno Concettuale (CDR) di INFN-AAI: l'implementazione di un REALM Kerberos per ogni sede e la loro federazione attraverso una rete di relazioni di fiducia con il REALM nazionale INFN.IT.

==== Un nuovo scenario ====
Dall'approvazione del CDR ad oggi, lo scenario é sensibilmente  modificato grazie ad un certo numero di novità:

  * Il lavoro di Sandro Angius, presentato al WS europeo di OpenAFS del 2009  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 
  * La bonifica delle omonimie relative alle “username” iniziata con la messa in produzione di INFN-AAI
  * La disponibilità di un software di gestione (WARC) capace di garantire il partizionamento dell'amministrazione di un REALM 

In questo nuovo scenario non sono più validi i vincoli che hanno portato alla definizione del CDR di INFN-AAI e quindi è possibile pensare ad una differente architettura del sistema di autenticazione di INFN-AAI.

In particolare, è oggi possibile una architettura che preveda un unico REALM Kerberos INFN.IT, utilizzabile a pieno da tutte le strutture e da tutti i servizi, sia nazionali che locali.

Il fatto che sia possibile ora pensare ad un REALM unico INFN.IT non vuol dire che tale implementazione sia immediatamente realizzabile. Esistono infatti ad oggi una decina di REALM kerberos locali differenti dispiegati in varie sedi nelle quali sarà necessaria  una discreta mole di lavoro da svolgere --anche in virtù della stretta relazione esistente tra autenticazione kerberos e AFS-- per migrare l'autenticazione da REALM locale a REALM nazionale.

Ciononostante, è necessario definire al più presto il modello definitivo in modo da permettere a tutte le sedi, specialmente a quelle  nelle quali non è ancora implementata l'autenticazione Kerberos, di iniziare la pianificazione delle operazioni necessarie per dispiegare il nuovo sistema di autenticazione.


==== Altre possibili soluzioni ====

Durante il lavoro preparatorio di questo documento (i cui contributi originali sono visionabili in http://wiki.infn.it/cn/ccr/aai/k5/contrib ) alcune sedi hanno sottolineato i loro dubbi e e le loro perplessità sulla confluenza dell'autenticazione di tutte le sedi --specialmente per quanto riguarda l'autenticazione per i servizi erogati localmente-- verso un unico REALM Kerberos INFN.IT. 

Tale posizione deriva principalmente da due motivi. Uno è legato alla attuale gestione del REALM INFN.IT per la quale --a causa dello stretto legame esistente tra AFS e Kerberos e degli strumenti attualmente a disposizione-- è necessario garantire la possibilità di intervento diretto da parte del personale del CINECA (ex CASPUR) coinvolto --per il contratto che il consorzio ha con l'INFN-- nella gestione della cella nazionale AFS infn.it. 

L'altro è legato  al livello di servizio che si può definire --alle garanzie su tale livello di servizio-- nel contesto dei servizi di calcolo dell'INFN, per un servizio di autenticazione che diventerebbe critico anche per l'accesso ai sistemi informatici locali.

Per tale motivi alcune sedi preferirebbero avere il controllo diretto ed assoluto sul sistema di autenticazione ed essendo questo in contrasto con l'architettura a REALM unico INFN.IT, la proposta avanzata è di tipo "misto". Una parte delle sedi utilizzerebbe il realm INFN.IT, mentre altre definirebbero un REALM Kerberos locale <SEDE>.INFN.IT legato al REALM nazionale da relazioni di fiducia.

In questo documento verranno illustrate le due proposte --REALM unico e soluzione mista-- evidenziandone gli aspetti salienti e le criticità, in modo che la Commissione Calcolo e Reti possa avere il maggior numero di elementi possibili per una decisione collegiale. 
 


Naturalmente, dato che la convergenza verso un unico REALM Kerberos INFN.IT avrà necessariamente un impatto notevole in tutte le sedi nelle quali è attualmente dispiegato un REALM Kerberros locale, e dato gli strumenti di gestione dell'unico REALM INFN.IT necessitano di una serie di aggiornamenti e migliorie, il processo di convergenza non potrà essere immediato e quindi l'architettura dovrà necessariamente prevedere un transiente durante il quale dovranno necessariamente convivere sistemi misti.

 
===== INTRODUZIONE =====



L'utilizzo di Kerberos nelle strutture INFN è stato finora legato principalmente al dispiegamento ed all'utilizzo del filesystem distribuito AFS, che ora --nella sua versione OpenAFS-- dipende fortemente da Kerberos5 (la versione 5 del protocollo di autenticazione Kerberos).

Questo stretto legame è frutto dell'evoluzione che l'ecosistema su cui si basa AFS/OpenAFS ed ha subito nel corso degli anni alcune importanti modifiche dovute ai cambiamenti del sistema AFS. Le condizioni di utilizzo delle prime versioni di AFS erano infatti sensibilmente differenti dalle attuali e questo ha portato a scelte che hanno fortemente condizionato il dispiegamento stesso di Realm Kerberos nelle varie sedi INFN.

In particolare, il proliferare di REALM Kerberos è stato indotto da un paio di motivazioni, la più forte delle quali era data  dalla impossibilità, nelle prime versioni di AFS, di distribuire in modo capillare in tutte le strutture INFN i server di autenticazione. La seconda motivazione (meno forte in quanto non legata all'architettura e quindi facilmente superabile attraverso strumenti software opportuni) era legata all'autonomia degli interventi sui server di Autenticazione da parte degli amministratori di sistema delle sedi (essendo garantita la gestione delle utenze in base alla sede di appartenenza dal software ARC sviluppato al CERN ed implementato nella cella nazionale AFS grazie al supporto del CASPUR).

Dispiegare un REALM Kerberos di sede è stata quindi una scelta obbligata per molte strutture INFN.



==== Utilizzo di Kerberos nelle sedi INFN ====

Praticamente tutte le strutture INFN che hanno dispiegato un REALM Kerberos --utilizzato principalmente come infrastruttura di autenticazione per AFS/OpenAFS-- hanno poi utilizzato tale infrastruttura anche per l'autenticazione relativa agli altri servizi informatici (come la posta elettronica, l'accesso autenticato alla rete wireless, i servizi di stampa, ecc. ecc.) realizzando quindi una infrastruttura di autenticazione di tipo Single-Password (ossia una sola coppia di username/password per accedere a tutti i servizi informatici) ed in alcuni casi --laddove la presenza di client kerberizzati lo ha permesso-- tale infrastruttura fornisce l'autenticazione in modalità di Single Sign-On.

Nella seguente Tabella.1 è riportato lo stato attuale dell'utilizzo di Kerberos nelle strutture INFN in cui è dispiegata l'infrastruttura Kerberos.

|            ^ REALM Kerberos       ^ Cella AFS      ^ Servizi Kerberos ^ Utenti Kerberos ^ Altri sistemi di Autenticazione ^ Single Sign-On ^
^ Roma 1     | INFN.IT              | infn.it        | Tutti            |  Tutti      |  N.D.            |  YES  |
^ Trieste    | INFN.IT              | infn.it        | Login unix/Mail  |  Tutti      |  LDAP            |  NO   |
^ Bologna    | INFN.IT              | infn.it        | Login Unix       |  Parte      |  Passwd/NIS      |  NO   |
^ Pisa       | PI.INFN.IT           | pi.infn.it     | Tutti            |  Tutti      |  N.D.            |  YES  |
^ Lecce      | LE.INFN.IT           | le.infn.it     | Tutti            |  Tutti      |  N.D.            |  YES  |
^ Bari       | BA.INFN.IT           | ba.infn.it     | Login Unix       |  Tutti      |  Cyrus           |  NO   |
^ LNF        | LNF.INFN.IT          | lnf.infn.it    | Tutti            |  Tutti      |  N.D             |  YES  |
^ LNGS       | LNGS.INFN.IT         | lngs.infn.it   | Login Unix       |  Parte      |  Passwd/NIS      |  NO   |
^ MI         | MI.INFN.IT           |  N.D.          | Tutti            |  Tutti      |  N.D             |  YES  |
^ MIB        | MIB.INFN.IT          |  N.D.          | Login Unix       |  Parte      |  LDAP            |  NO   |

Oltre alle sedi riportate  in tabella, singoli utenti di altre sedi hanno account Kerberos nel REALM INFN.IT per poter accedere in modo autenticato a spazi disco AFS della cella nazionale.



==== INFN-AAI & Kerberos ====
Nell'effettuare la scelta del sistema di Autenticazione per INFN-AAI, non si è potuto non considerare il fatto che --anche se non universalmente adottato nell'INFN-- il filesystem distribuito AFS/OpenAFS è **di cruciale importanza ed irrinunciabile** per almeno 6 sedi e 2 laboratori nazionali.

Questo ha portato alla scelta obbligata sull'utilizzo di Kerberos come uno dei possibili sistemi di autenticazione supportati (insieme ai certificati X.509 e password usa e getta). 

Inoltre, per permettere comunque l'accesso ai sistemi che utilizzano INFN-AAI anche da client non kerberizzati (o non kerberizzabili) è stato sviluppato un apposito plug-in per il sistema di Directory Server adottato da INFN-AAI (la versione OpenSource del RedHat Enterprice Directory Server nota come 389DS).

In tale plug-in sono state implementate due funzionalità. La prima permette l'autenticazione Kerberos attraverso l'utilizzo di coppia di username/password, oltre alla canonica autenticazione Keberos basata su GSSAPI. La seconda è permette di creare al volo --in modo automatico e trasparente sia all'utente che all'amministratore della sede-- una nuova utenza Kerberos nel REALM di riferimento della sede, per utenti di sedi che utilizzano altri meccanismi di autenticazione (essenzialmente UNIX passwd/NIS o LDAP). Questa seconda funzionalità permette quindi una "migrazione indolore" a Kerberos per  tutte le sedi nelle quali non è dispiegata una tale infrastruttura di autenticazione.


 
===== DUE PROPOSTE =====

Di tutti i possibili scenari analizzati durante il lavoro preparatorio di questo documento, ne sono sopravvissuti due: REALM unico INFN.IT e modello misto.

==== REALM UNICO INFN.IT ====

Il modello a REALM unico non sarebbe altro che l'estensione a tutte le sedi di di quanto è in produzione nelle sezioni di Roma, di Trieste e --anche se in modo ancora parziale-- Bologna.

In queste sedi infatti, ogni utenza è definita all'interno del REALM Kerberos nazionale INFN.IT ed in particolare, nella sezione di Roma, tutti i servizi informatici sono collegati all'autenticazione Kerberos nel REALM INFN.IT.


=== Architettura di INFN.IT ===

Il REALM Kerberos nazionale INFN.IT nasce come sistema di autenticazione per la cella nazionale AFS infn.it e garantisce oggi l'autenticazione attraverso:
  * un master KDC (Key Distribution Center) collocato fisicamente al CNAF;
  * tre slave KDS di primo livello che sono collocati all'interno dei tre DataBase server della cella AFS nazionale infn.it (collocati al CNAF, Roma e Napoli).

Affiancati a questo nucleo principale, nelle sedi nelle quali le utenze sono state trasformate da utenze Unix ad utenze Kerberos, per garantire continuità del servizio di autenticazione  anche nel caso di problemi di connettività di rete, sono stati ultimamente dispiegati altri slave KDC.In particolare, sono stati installati due slave KDC del REALM INFN.IT nella sezione di Trieste e presso l'Istituto Superiore di Sanità, sede del gruppo collegato ISS della sezione di Roma.

La gestione del master KDC è affidata ad un gruppo di dipendenti INFN (Roberto Gomezel, responsabile nazionale di AFS; Enrico M.V. Fasanelli, responsabile nazionale di INFN-AAI; Massimo Donatelli del CNAF, per la parte riguardanti le operazioni fisiche sui server collocati al CNAF) che sono coadiuvati da personale del CINECA (ex-CASPUR) che sono coinvolti nella gestione della cella nazionale AFS infn.it.

Dato che diverse sedi fanno riferimento al REALM INFN.IT, per la gestione dei principal Kerberos in tale REALM si utilizza l'interfaccia "ARC" --che da alcuni mesi è disponibile anche in formato GUI web (https://warc.infn.it/)-- e che permette di "partizionare" la gestione delle utenze secondo la sede presso la quale è definito l'account AFS all'interno della cella nazionale infn.it.


=== Estensione del modello ===

L'architettura sopra descritta, con uno slave KDC nelle sedi che utilizzano autenticazione Kerberos, garantisce: 
  * continuità di servizio in qualunque condizione di rete geografica. Infatti in caso di irraggiungibilità del master KDC le uniche operazioni non possibili sarebbero quelle che implicano la modifica del DataBase Kerberos (la definizione di nuovi principal ed il cambio della password di principal esistenti);
  * la possibilità, per gli utenti definiti nel REALM INFN.IT, di essere autenticati da qualunque sistema informatico che faccia riferimento a tale REALM;
  * la migrazione a costo zero di una utenza tra varie sedi che fanno riferimento al REALM INFN.IT;
  * unicità delle credenziali per gli utenti nel REALM INFN.IT.

Estendere l'utilizzo del REALM INFN.IT a tutte le sedi fornirebbe quindi la possibilità per gli utenti, di **utilizzare le proprie credenziali** definite nel REALM INFN.IT per essere autenticati da un **qualunque servizio informatico in qualunque sede**.

Un esempio concreto sono i sistemi di calcolo scientifico  di esperimento che potrebbero essere dislocati in una qualunque sede, ma --configurati in modo da far riferimento al REALM INFN.IT-- autenticherebbero utenti di qualunque sede.

Bisogna qui sottolineare che essere autenticati non vuol dire avere automaticamente accesso ai servizi. E' necessario infatti che i servizi siano configurati in modo da verificare, attraverso il controllo degli attributi autorizzativi --forniti dai server LDAP di INFN-AAI-- che l'utente autenticato attraverso l'infrastruttura Kerberos sia autorizzato ad accedere al servizio stesso.


=== Dispiegamento ===

Dispiegare il REALM INFN.IT in tutte le sedi INFN richiede due tipi di intervento:
  * infrastruttura
    * installazione di slave KDC collegato all'infrastruttura nazionale
    * configurazione dei servizi informatici di sede (client Kerberos)
  * migrazione utenze

Il dispiegamento della infrastruttura comprende un intervento decisamente semplice e poco impegnativo (l'installazione in sede di uno slave KDC DEL REALM INFN.IT) oltre ad un intervento più complesso che dipende  dal numero e tipo di servizi informatici gestiti in sede.

E' chiaro che in ogni sede dovranno coesistere il vecchio ed il nuovo sistema per il tempo necessario ad effettuare la migrazione di tutti i servizi.

Riguardo la migrazione delle utenze, bisogna distinguere due casi:
  - sede in cui NON è in uso Kerberos;
  - sede che utilizza Kerberos locale.

Nel primo caso la migrazione delle utenze è semplice ed "indolore" in quanto  esistono procedure che --partendo da un DataBase di utenze Unix-- possono importare nei server LDAP di INFN-AAI il DataBase delle utenze locali. Una volta che le utenze sono nel server LDAP di INFN-AAI, il plus-in krb5 appositamente sviluppato permette di generare in modo automatico il principal Kerberos relativo a tale utenza, assegnandogli la password originale importata in LDAP, nel momento in cui l'utente effettua la prima autenticazione.

Nel caso invece di sedi nelle quali è in produzione un REALM Kerberos locale, la migrazione delle utenze non può avvenire in modo automatico (per una caratteristica di sicurezza di Kerberos che prevede che le chiavi di autenticazione dipendano dal nome del REALM oltre che dal nome del principal e dalla password).

La migrazione delle utenze in questo caso richiederà quindi una considerevole mole di lavoro che potrebbe comunque essere pianificata in un periodo di un anno solare (le dimensioni massime dei REALM locali esistenti sono dell'ordine di 1500 entry che possono essere convertite in 300 giorni ad un rate di 5 entry al giorno).

Ovviamente l migrazione delle varie sedi che si trovano in questo stato potrà avvenire in parallelo.

=== Gestione del REALM INFN.IT ===

L'attuale modello di gestione del REALM INFN.IT è non ha evidenziato criticità (tranne il fatto che alla gestione partecipa personale non INFN) per le sedi che utilizzano tale REALM in produzione per l'accesso ai propri servizi informatici (Roma, Trieste, Bologna). Anzi, la sempre sollecita risposta del personale CINECA (ex CASPUR) è stata una delle motivazioni che ha portato una sede come Trieste a passare tutte le utenze locali nel REALM INFN.IT.

Ciononostante, nell'ottica dell'unificazione dei sistemi di autenticazione di tutte le sedi INFN in una unica infrastruttura, appare più ragionevole che la gestione di tale infrastruttura il cui funzionamento --ora di critica importanza-- diventerà di **vitale** importanza per l'intero INFN, sia affidata interamente a personale INFN con adeguata esperienza nella gestione di sistemi Kerberos.

Dovrebbe essere istituito un "Servizio Nazionale AAI", che oltre alla gestione del REALM Kerberos INFN.IT garantisca il funzionamento di tutto INFN-AAI --altra infrastrutture ormai essenziale per il funzionamento dell'INFN-- formato da personale con adeguata esperienza, anche distribuito nelle varie sedi.  

In mancanza di un tale servizio, la gestione potrebbe essere affidata al gruppo di persone che in questo momento gestisce e garantisce il funzionamento di INFN-AAI, affiancato da colleghi esperti nella gestione di Kerberos nelle varie sedi (Lecce, Pisa, LNF, Milano, Milano Bicocca, Trieste, LNGS). 

In questo contesto di completo "in-sourcing" dovrà anche essere rivisto lo strumento di gestione del REALM INFN.IT. E' già in fase di studio avanzato la possibilità di inserire le attuali funzionalità di ARC/WARC all'interno di GODiVA che --secondo una prima analisi-- potrebbe includere tali funzionalità in un paio di mesi.

==== MODELLO MISTO ====

Il modello misto prevede la possibilità --per le sedi che non vogliono utilizzare il REALM INFN.IT-- di dispiegare un proprio REALM locale e definire relazioni di fiducia con il REALM INFN.IT.

Il REALM INFN.IT, oltre a contenere le relazioni di fiducia con i REALM di sede, continuerebbe ad essere il REALM di riferimento per le sedi che lo vorranno utilizzare, e per queste sedi vale tutto quanto detto nel capitolo precedente. 

Questo modello garantirebbe **completa autonomia di gestione** del sistema di autenticazione locale e permetterebbe agli utenti l'accesso ai servizi WEB nazionali via INFN-AAI (attraverso appunto la relazione di fiducia con il REALM INFN.IT) come avviene adesso per le sedi che hanno un REALM locale.

Come nel caso del REALM unico, gli account Unix possono essere importati nel REALM locale in modo trasparente ed "indolore", ma un tale principal sarebbe differente da quello che --eventualmente-- l'utente ha nel REALM INFN.IT (principal ottenuto perché magari proviene da una sede che usa il REALM INFN.IT). Inoltre, nel caso non raro di utenti che nel tempo si spostano da una sede all'altra, si avrebbe un proliferare di principal Kerberos differenti per lo stesso utente.

A differenza dello scenario con REALM unico, in questo caso, l'autenticazione da parte di sistemi di calcolo scientifico agganciati al REALM INFN.IT potrebbe essere ottenuta --grazie alla relazione di fiducia-- solo partendo da un sistema Kerberos (cioè potrebbe essere necessario un "doppio salto" per poter accedere ad una farm di calcolo scientifico di esperimento).

Il proliferare di principal differenti per lo stesso utente e la maggiore macchinosità necessaria per poter garantire l'accesso a servizi di calcolo interattivi potrebbero essere mitigati se agli utenti delle sedi che dispiegano un REALM Kerberos locale fosse fornito un principal Kerberos nel REALM INFN.IT. In questo caso, l'utente potrebbe accedere a **tutti** i servizi informatici forniti dalle sedi che fanno riferimento al REALM INFN.IT, utilizzando le proprie credenziali nazionali.


=== Gestione del REALM INFN.IT ===

E' chiaro che, dato che il modello misto prevede il mantenimento del REALM INFN.IT per le sedi che lo volessero scegliere, tutto quanto detto precedentemente riguardo la gestione del REALM INFN.IT si applica invariato anche in questo modello.


==== ASPETTI IN COMUNE ====

Da quanto sopra esposto, risulta evidente che per **entrambi i modelli** bisogna trattare due aspetti di cruciale importanza:
  * Gestione del REALM INFN.IT
  * Strumenti di gestione dei principal nel REALM INFN.IT (almeno per le sedi che adotteranno tale REALM nel modello misto)

Il modello misto infatti, se da un lato garantisce **completa autonomia di gestione** del REALM Kerberos locale da parte delle sedi che effettueranno tale scelta, non permette --proprio in quanto il modello consente alle sedi di scegliere il REALM INFN.IT-- di dimenticarsi delle questioni relative alla gestione del REALM nazionale e dei principal degli utenti in tale REALM.