INFN-AAI scelte tecniche Dael Maselli INFN - Laboratori Nazionali di Frascati Riunione comitato di revisione progetto AAI Firenze maggio 2008

Firenze Maggio 2008Riunione comitato di revisione progetto AAI AAI-WG - Dael Maselli - INFN-LNF 2 Fedora Directory Server Server LDAP Open-source, ma discendente da software commerciali Repliche "Multi-Master" Sincronizzazione con Active Directory Autenticazione e trasporto sicuri (SSLv315, TLSv116 and SASL17) Autenticazione Kerberos5 attraverso SASL e GSS-API Aggiornamento "a caldo" di schema, configurazione ed ACI (Access Control Information) Gruppi dinamici o nidificati (roles) Espandibilita’ tramite plug-in

Firenze Maggio 2008Riunione comitato di revisione progetto AAI AAI-WG - Dael Maselli - INFN-LNF 3 Fedora Directory Server (storia) Codice sviluppato da 10 anni FDS discende direttamente da RedHat DS, che a sua volta viene da Netscape DS, il quale e’ stato sviluppato insieme Sun One DS (iPlanet) Ne esiste una versione commerciale supportata di RedHat Documentazione molto completa E’ possibile fare riferimento a RedHat DS 8:

Firenze Maggio 2008Riunione comitato di revisione progetto AAI AAI-WG - Dael Maselli - INFN-LNF 4 Fedora Directory Server (Roles) La gestione dei Gruppi in FDS può essere implementata tramite i Ruoli La differenza sostanziale con i gruppi “classici” e che i Roles vengono gestiti dal server anziche’ dal client LDAP E’ possibile definire gruppi statici, gruppi dinamici e gruppi nidificati.

Firenze Maggio 2008Riunione comitato di revisione progetto AAI AAI-WG - Dael Maselli - INFN-LNF 5 Fedora Directory Server (Roles) Ruoli Statici – Managed Roles Le entry realtive agli utenti vengono associate puntualmente ad un Ruolo

Firenze Maggio 2008Riunione comitato di revisione progetto AAI AAI-WG - Dael Maselli - INFN-LNF 6 Fedora Directory Server (Roles) Ruoli Dinamici – Filtered Roles Nella definizione del Ruolo viene inserita una search string che rappresenta l’insieme delle entry che verranno associate al ruolo in oggetto

Firenze Maggio 2008Riunione comitato di revisione progetto AAI AAI-WG - Dael Maselli - INFN-LNF 7 Fedora Directory Server (Roles) Ruoli Nidificati – Nested Roles Nella definizione del Ruolo sono definiti altri Ruoli i cui membri verranno associati al ruolo in oggetto

Firenze Maggio 2008Riunione comitato di revisione progetto AAI AAI-WG - Dael Maselli - INFN-LNF 8 Fedora Directory Server (ACI) Access Control Information Definiscono i permessi di accesso all’albero del Directory Possono essere definite in qualsiali punto dell’albero Vengono sempre ereditate dalle entry sottostanti Sono definite da Target, Subject e Permission

Firenze Maggio 2008Riunione comitato di revisione progetto AAI AAI-WG - Dael Maselli - INFN-LNF 9 Fedora Directory Server (ACI) Target Rappresenta l’oggetto dell’ACI: entry e/o attributi Subject / Bind Rule Rappresenta il soggetto (chi, da dove, come, quando) che accede al target Type of Access / Permission E’ l’elenco delle azioni permesse o negate al Subject sul Target aci:(target="ldap:///uid=bjensen,dc=example,dc=com “ )(targetattr=loginShell) (version 3.0;acl “ sample"; allow (write,delete) userdn="ldap:///self"; and (dns="*.infn.it") and (dayofweek = "Sun") and (timeofday >= "900 “ and timeofday < "1100"))

Firenze Maggio 2008Riunione comitato di revisione progetto AAI AAI-WG - Dael Maselli - INFN-LNF 10 Fedora Directory Server (ACI) E’ possibile controllare tramite le ACI anche il contenuto del valore che si sta immettendo o rimuovendo Ad esempio si puo autorizzare la definizione di un numero di telefono che inizi con solo da parte dela personale dell’INFN di Frascati

Firenze Maggio 2008Riunione comitato di revisione progetto AAI AAI-WG - Dael Maselli - INFN-LNF 11 Fedora Directory Server (Repliche) FDS supporta 3 tipi di Replica Read Only HUB Multi Master L’oggetto di una replica e’ sempre un database Un database contiene informazioni a partire da un nodo dell’albero LDAP In modo analogo ad un Filesystem montato in un albero di directory unix

Firenze Maggio 2008Riunione comitato di revisione progetto AAI AAI-WG - Dael Maselli - INFN-LNF 12 Fedora Directory Server (RO) Configurazione Read-Only Il server Master (supplier) e’ l’unico che puo’ ricevere update Il Read-Only (consumer) e’ abilitato in sola lettura ogni query di update del DS verso di esso avra’ come risultato un elenco di server (referral) Read-Write

Firenze Maggio 2008Riunione comitato di revisione progetto AAI AAI-WG - Dael Maselli - INFN-LNF 13 Fedora Directory Server (HUB) Un server HUB e’ un nodo Read-Only che e’ in grado di propagare gli update che riceve ad altri server Read-Only Per alleggerire il carico del master

Firenze Maggio 2008Riunione comitato di revisione progetto AAI AAI-WG - Dael Maselli - INFN-LNF 14 Fedora Directory Server (MMR) Nelle repliche Multi-Master ogni nodo e’ autoritativo per gli update Ogni server coinvolto e’ sia supplier che consumer Ogni update ad uno qualsiasi dei nodi verra’ propagato agli altri Master Fino a 4 nodi e’ un limite di certificazione, non architetturale

Firenze Maggio 2008Riunione comitato di revisione progetto AAI AAI-WG - Dael Maselli - INFN-LNF 15 Fedora Directory Server (INFN) Data l'organizzazione dell’INFN, l’albero LDAP sara' strutturato in tale modo: La radice: “dc=infn, dc=it” Conterra’ informazioni valide per tutto l’albero come i Ruoli e alcune ACI Ogni sede avra' il proprio sottoramo identificato con “dc=NOMESEDE, dc=infn, dc=it” Contenente le entry delle persone, gruppi locali e altre informazioni relative ai servizi di sede

Firenze Maggio 2008Riunione comitato di revisione progetto AAI AAI-WG - Dael Maselli - INFN-LNF 16 Fedora Directory Server (INFN) Il ramo “dc=infn,dc=it” sara’ associato ad un proprio database (infn-db) I rami sottostanti riguardanti le sedi saranno contenuti ognuno in un database separato (SEDE-db)

Firenze Maggio 2008Riunione comitato di revisione progetto AAI AAI-WG - Dael Maselli - INFN-LNF 17 Fedora Directory Server (INFN) Repliche - CORE Tutti i database verranno replicati in modalita’ Multi-Master in 4 server, detti CORE Tali sever saranno dunque tutti autoritativi, anche uno solo puo’ lavorare indipendentemente dalla presenza degli altri

Firenze Maggio 2008Riunione comitato di revisione progetto AAI AAI-WG - Dael Maselli - INFN-LNF 18 Fedora Directory Server (INFN) Repliche di Sede Nei server presso le sedi verranno replicati, in modalita’ Read-Only: il database relativo a “dc=infn,dc=it” il database relativo alla sede “dc=SEDE,dc=infn,dc=it” Ogni richiesta di update del Directory verra’ gestita tramite referral informando il client con la lista dei server di CORE, dove potra’ avvenire la modifica a seguito della quale il CORE informera’ i server read- only coinvolti

Firenze Maggio 2008Riunione comitato di revisione progetto AAI AAI-WG - Dael Maselli - INFN-LNF 19 Fedora Directory Server (objectClass) Alcune informazioni utili per i servizi INFN non trovano posto negli attributi standard di FDS Ne consegue la necessita’ di definire degli attributi privati INFN con le relative objectClass Un esempio e’ il Codice Fiscale

Firenze Maggio 2008Riunione comitato di revisione progetto AAI AAI-WG - Dael Maselli - INFN-LNF 20 Fedora Directory Server (auth) FDS supporta nativamente diversi metodi di autenticazione: user/pass tramite hash MD5 o crypt unix Possono essere copiati gli hash da un file passwd user/pass attraveso le librerie PAM unix tramite un certificato x509 presentando un ticket Kerberos5 E’ possibile inoltre scrivere dei plug-in di autenticazione personalizzati

Firenze Maggio 2008Riunione comitato di revisione progetto AAI AAI-WG - Dael Maselli - INFN-LNF 21 Fedora Directory Server (x509) E’ possibile effettuare l’autenticazione verso FDS tramite certificato x509 Tramite due modalita’ Definendo dei mapping tra gli attributi presenti nel Subject del certificato e quelli del DN delle entry del DS Inserendo in un attributo specifico del DS il subject del certificato che gli si vuole associare

Firenze Maggio 2008Riunione comitato di revisione progetto AAI AAI-WG - Dael Maselli - INFN-LNF 22 Fedora Directory Server (plug-in) Una delle particolarita’ di FDS e’ la sua espandibilita’ E’ possibile infatti scrivere dei plug-in per aggiungere funzionalita’ in ogni settore del software E’ stato gia’ scritto da AAI un plug-in per la l’autenticazione tramite username e password verso un server Kerberos5

Firenze Maggio 2008Riunione comitato di revisione progetto AAI AAI-WG - Dael Maselli - INFN-LNF 23 Kerberos 5 Kerberos è un protocollo di autenticazione nato al MIT negli anni 80 come soluzione per l’identificazione degli utenti di una rete aperta e insicura che adotti il modello Client/Server La prima versione pubblica fu Kerberos 4 apparsa sul finire degli anni 80 è tutt’ora utilizzata in alcuni ambienti La versione 5 ha risolto problemi di sicurezza insiti nel protocollo di K4 ed è diventata uno standard (RFC1510 recentemente integrato da RFC4120) Ne esitono 3 versioni: MIT Heimdal Microsoft Active Directory

Firenze Maggio 2008Riunione comitato di revisione progetto AAI AAI-WG - Dael Maselli - INFN-LNF 24 Perché Kerberos 5 E’ progettato per lavorare su reti aperte e insicure avendo la massima cura di non esporre mai le credenziali Garantisce il Single Sign-On se i client e i server sono kerberizzati Garantisce la mutua autenticazione tra client e server kerberizzati Permette la cross-autenticazione tra domini per i quali ci sia una relazione di fiducia

Firenze Maggio 2008Riunione comitato di revisione progetto AAI AAI-WG - Dael Maselli - INFN-LNF 25 MIT Kerberos 5 E’ ben supportato e vede investimenti da parte di grosse realtà come la Nasa, Google, Microsoft, la Sun Microsystem e altre che fanno riferimento al consorzio Kerberos ( Garantisce l’interoperabilità (Documentata da Microsoft) con Active Directory Permette l’autenticazione di celle AFS e OpenAFS (in modalità nativa K5) Dispone del supporto all’autenticazione Windows anche per le Workstation che non appartengono ad un dominio Active Directory

Firenze Maggio 2008Riunione comitato di revisione progetto AAI AAI-WG - Dael Maselli - INFN-LNF 26 Autenticazione Distribuita Kerberos permette di distribuire l’autenticazione tra le varie sedi Ogni sede gestisce l’autenticazione relativa ai suoi utenti e ai suoi servizi Gli utenti di una sede possono cross- autenticarsi sui servizi di un’altra poiché tra i REALM componenti è instaurata una relazione di fiducia

Firenze Maggio 2008Riunione comitato di revisione progetto AAI AAI-WG - Dael Maselli - INFN-LNF 27 I KDC dei REALM di sede Ogni sede deve gestire un KDC Master + eventuali Slave per il REALM locale Nei luoghi dove sono dispiegati i server centrali di FDS (CNAF, LNF) è previsto un KDC slave per ognuno dei REALM di sede Ciò al fine di garantire l’autenticazione sui servizi centrali anche se dovesse mancare il collegamento con le sedi locali

Firenze Maggio 2008Riunione comitato di revisione progetto AAI AAI-WG - Dael Maselli - INFN-LNF 28 KDC del REALM INFN.IT Il KDC master del realm nazionale INFN.IT si trova al CNAF Gli slave sono attualmente: CNAF Napoli Roma Come per i KDC di sede esistera' uno slave di INFN.IT anche nelle sedi del CORE di FDS

Firenze Maggio 2008Riunione comitato di revisione progetto AAI AAI-WG - Dael Maselli - INFN-LNF 29 Relazioni di Fiducia Per rendere possibile la cross-autenticazione di tutte le sedi Relazioni di fiducia dirette e bidirezionali tra i REALM di sede e il REALM centrale INFN.IT Per transitività delle relazioni suddette In caso di intensa cooperazione tra 2 sedi è possibile instaurare, per ragioni di efficienza, relazioni dirette bidirezionali

Firenze Maggio 2008Riunione comitato di revisione progetto AAI AAI-WG - Dael Maselli - INFN-LNF 30 Client e servizi non kerberizzati Effettueranno l'autenticazione tramite username e password presso il servizio a cui si vuole accedere Il servizio potra' verificarne la validita' tramite librerie PAM o attraverso LDAP In questo caso si perde il vantaggio del Single Sign-on e della mutua autenticazione

Firenze Maggio 2008Riunione comitato di revisione progetto AAI AAI-WG - Dael Maselli - INFN-LNF 31 Autenticazione LDAP mediante K5 Per generalizzare ulteriormente e disporre anche della possibilità di autenticare mediante la simple authentication LDAP si è creato un plug-in per FDS che ad una tale richiesta di autenticazione ribalti la verifica delle credenziali verso un KDC Kerberos5

Firenze Maggio 2008Riunione comitato di revisione progetto AAI AAI-WG - Dael Maselli - INFN-LNF 32 Plug-in KRB5 per FDS Il plug-in esegue le seguenti operazioni: Se nella entry LDAP dell’utente che cerca di autenticarsi è presente l’attributo krbPrincipalName lo utilizza per stabilire quale è il principal con cui tentare l’autenticazione In caso non esista, ottiene il principal K5 concatenando i DC in maiuscolo da sinistra a destra del DN della entry, ad es: DN: uid=pippo,ou=People,dc=le,dc=infn,dc=it Se l’autenticazione K5 fallisce si tenta l’autenticazione con l’hash memorizzato nell’attributo userPassword

Firenze Maggio 2008Riunione comitato di revisione progetto AAI AAI-WG - Dael Maselli - INFN-LNF 33 Incompatibilità hash NIS/LDAP e K5 Per le sedi che non usano già K5 si pone il problema di generare gli hash delle password degli utenti Tali hash non possono essere ottenuti da quelli memorizzati in /etc/shadow, NIS o LDAP Si vuole evitare di chiamare tutti gli utenti per inserire la password

Firenze Maggio 2008Riunione comitato di revisione progetto AAI AAI-WG - Dael Maselli - INFN-LNF 34 La soluzione al problema degli hash Si importano nel FDS gli hash provenienti dal preesistente sistema di autenticazione, in maniera automatica mediante i migration tools LDAP La prima autenticazione dell’utente avviene mediante tali hash Il plug-in KRB5, in questa fase, si accorge che il principal K5 non esiste ancora, e poiché dispone delle credenziali verificate tramite l’hash lo crea Le successive autenticazioni avvengono tramite Kerberos

Firenze Maggio 2008Riunione comitato di revisione progetto AAI AAI-WG - Dael Maselli - INFN-LNF 35 Autenticazione verso Active Directory Se la sede autentica gli utenti mediante Active Directory: Non si possono migrare gli hash direttamente nel K5 di MIT Ma poiché AD stesso usa K5, il plug-in può eseguire la prima autenticazione sul dominio Windows e quindi creare la entry Kerberos

FINE

Firenze Maggio 2008Riunione comitato di revisione progetto AAI AAI-WG - Dael Maselli - INFN-LNF 37 Implementazioni di Kerberos 5 valutate MIT Kerberos 5 del Massachusetts Institute of Technology Microsoft Active Directory Heimdal del PDC KTH in Svezia

Firenze Maggio 2008Riunione comitato di revisione progetto AAI AAI-WG - Dael Maselli - INFN-LNF 38 Kerberos Active Directory Deriva dalla versione di Kerberos 5 di MIT Non rispetta totalmente lo standard I principal dei servizi non possono contenere il punto e quindi si deve usare l’hostname breve e non il FQDN Nei ticket vengono inserite informazioni di autorizzazione come l’elenco dei gruppi a cui l’utente appartiene Ciò crea problemi di compatibilità con i client Unix se un utente appartiene a troppi gruppi Si tratta di un implementazione chiusa di cui non si dispone dei sorgenti

Firenze Maggio 2008Riunione comitato di revisione progetto AAI AAI-WG - Dael Maselli - INFN-LNF 39 Heimdal Kerberos 5 E’ equivalente a MIT Kerberos 5 E’ nato e si è diffuso quando il Governo americano limitava l’esportazione di software che implementassero algoritmi crittografici Dispone di un tool per la migrazione da MIT Kerberos 5 a Heimdal

Firenze Maggio 2008Riunione comitato di revisione progetto AAI AAI-WG - Dael Maselli - INFN-LNF 40 MIT K5 è ’implementazione scelta Si è scartato a priori il KDC di Active Directory perché non rispetta lo standard e non supporta pienamente l’autenticazione per OpenAFS Tra l’implementazione di MIT e quella di Heimdal si è scelta la prima perché: Ci dà maggiori garanzie in termini di supporto e sviluppo vista l’esistenza del Consorzio Kerberos di cui MIT ne è uno dei soci fondatori Alcune celle AFS locali e la cella nazionale stessa sono già migrate a Kerberos 5 ed hanno scelto l’implementazione di MIT Esiste la possibilità, in futuro, di migrare il database MIT a Heimdal (per il contrario non esiste un tool)

Firenze Maggio 2008Riunione comitato di revisione progetto AAI AAI-WG - Dael Maselli - INFN-LNF 41 Cross-Autenticazione Tutti i REALM saranno cross-autenticati Ogni sede riconosce a livello di autenticazione gli utenti di tutte le altre sedi L’accesso effettivo ai servizi è regolato da meccanismi autorizzativi basati sulle informazioni contenute nel FDS

Firenze Maggio 2008Riunione comitato di revisione progetto AAI AAI-WG - Dael Maselli - INFN-LNF 42 I nomi dei REALM I nomi dei REALM in cui è distribuita l’autenticazione corrispondono ai domini DNS convertiti in maiuscolo Esempi: INFN.IT, LNF.INFN.IT, LE.INFN.IT

Firenze Maggio 2008Riunione comitato di revisione progetto AAI AAI-WG - Dael Maselli - INFN-LNF 43 Servizi e client Kerberizzati Per servizio Kerberizzato si intende un daemon che fornisce il servizio su presentazione di un ticket che autentichi l’utente Per client Kerberizzato si intende un software in grado di accedere ad un servizio presentando un ticket