Slides - Agenda INFN
Transcript
Slides - Agenda INFN
AAI Proposta per un modello comune in ambito locale E. M. V. Fasanelli F. M. Taurino G. Tortone CCR Roma – 12/12/2006 Agenda L’AAI dal punto di vista dei servizi di base Un sguardo d’insieme sulla situazione attuale Il modello proposto Conclusioni I servizi di base Posta elettronica Stampa Accesso remoto e per ospiti Mailing List Applicazioni e siti Web Windows Posta elettronica (SMTP) I mail exchanger hanno bisogno di Lista delle reti autorizzate al relay Elenco dei domini per cui possono gestire la posta Lista degli alias e dei maildrop degli utenti Tipicamente sono almeno due ed e’ necessario tenere sincronizzati i loro “database” Posta elettronica (IMAP) I server di accesso alle caselle email hanno bisogno di Lista degli utenti Eventuali autorizzazioni di accesso a folder condivisi Possono essere collegati a server di autenticazioni centralizzati oppure avere un elenco di utenti e password locale (es. Cyrus) Stampa (CUPS) Possibilità di avere code private e/o di gruppo e di richiedere l’autenticazione degli utenti che inviano le stampe Browsing delle stampanti via IPP e/o Samba Possibilita’ di “pubblicare” le stampanti (es: configurazione, tipi di formati disponibili, location) su un “directory server” Accesso remoto La gestione dell’accesso in modalità interattiva può essere complessa Nel caso più semplice (Server Linux con accesso via ssh) sono necessari Elenco username/password Tcp-wrapper per autorizzazione di ip/domini Opt: limits.conf, time.conf (limiti e orari) Tipicamente e’ necessario modificare altri file per gli accessi in grafica Accesso per ospiti o VPN Questi sistemi possono operare utilizzando server centrali di autenticazione oppure avere elenchi di utenti locali alle macchine La gestione degli ospiti può essere complessa (creazione account, scadenze) Mailing list Diversi indirizzi (a volte migliaia) per ogni lista Permessi di accesso e utilizzo Gestione archivi via web Tipicamente svincolati dai sistemi di autenticazione centrali (oppure non integrabili – es: Majordomo) La creazione di un utente sui server comporta l’aggiunta di una entry sul server di gestione delle liste Applicazioni e siti web Autenticazione utenti con file in formato specifico per il server web - htpasswd Autorizzazione all’accesso a folder impostati con il meccanismo “htaccess” Non integrabile con sistemi standard Proliferazione di file htpasswd e htaccess su siti complessi Windows Autenticazione e autorizzazioni vengono gestiti da Active Directory Non integrabili –direttamente– con sistemi Linux/Unix Tipicamente in ambienti multipiattaforma avremo almeno due “database” degli utenti Identity management - 1 La gestione delle informazioni relative agli individui (e a macchine e servizi) Account sui sistemi Account per le applicazioni Indirizzi (email, telefono, indirizzo fisico) Iscrizione a “servizi” Identity management - 2 Queste informazioni sono contenute in diversi “database”, in formati differenti e di solito con sistemi NON compatibili fra loro E’ difficile tenere sincronizzate le informazioni relative a una persona su tutti questi sistemi Es: trasferimento di una persona Quanti e quali “database” vanno modificati? Cosa succede se tralascio uno degli archivi? La situazione odierna - 1 La situazione odierna - 2 E se le sedi sono due… Soluzioni parziali - 1 NIS (Yellow Pages) Non gerarchico “database” semplice (tabelle di due colonne) Server di tipo Master/Slave Criptazione delle sole password Utilizzo non efficiente su WAN Intrinsecamente non sicuro SOLO per Linux/Unix Alcuni problemi risolti con NIS+ Non vengono sviluppati attivamente Soluzioni parziali - 2 Kerberos Non gerarchico – multi realm Database criptato Server di tipo Master/Slave Criptazione anche del traffico Utilizzabile su WAN Indipendente dalla piattaforma SOLO per autenticazione e autorizzazione Soluzioni parziali - 3 LDAP Gerarchico Database “liberamente” modificabili Server di tipo Multi-Master/Slave/Replica Criptazione anche del traffico Utilizzabile su WAN Indipendente dalla piattaforma Anche per autenticazione e autorizzazione Il modello AAI proposto LDAP + backend Kerberos5 Intrinsecamente gerarchico Sicuro (db user/pass – traffico) Standard aperti e multipiattaforma Compatibile con le AI sicure esistenti Calza “a pennello” sulla struttura INFN… K5 è opzionale (ma raccomandato) PKI e certificati X.509 Il DS per i servizi comuni AAI per l’INFN C=IT, O=INFN C=IT, O=INFN, L=Napoli C=IT, O=INFN, L=Lecce DS DS DS Vantaggi Singole istanze dei “dati” Gestione centralizzata (anche su architettura distribuita), uniforme e sicura Sincronizzazione efficiente Riduzione dei costi Consolidamento delle informazioni presenti in diversi database di sistemi e applicazioni E dei tempi… Possibilità di modificare lo schema per applicazioni particolari NOTE SUI DS Cosa e’ un Directory Service Un Directory Service è un servizio informativo che consente un accesso uniforme ai dati, organizzati secondo un preciso schema. I DS costituiscono fonte di informazione non solo per le persone ma anche per le applicazioni. Esistono DS specializzati come il DNS e di utilizzo piu’ generale come LDAP. DS e Database Un DS e’ un DB ottimizzato per la lettura e per la ricerca delle informazioni su dati con aggiornamenti rari, con un protocollo che permette l’accesso via rete. Sono inoltre previsti meccanismi di replicazione e distribuzione dei dati tra vari Dircetory Server X.500 DS standard del CCITT Revisioni importanti nel 1993 e nel 1997 (altre negli anni successivi) Directory Access Protocol per l’accesso via rete (opera su tutta la pila OSI) Introduce le linee guida per i successivi DS LDAP Lightweight Directory Access Protocol Nato per sopperire alla “pesantezza” di X.500 Opera su TCP/IP Vasta diffusione Modello informativo basato sulle entita’ Entita’ composte da attributi che hanno uno o più valori Gli attributi hanno una sintassi che determina il tipo (ASCII, binario) e il loro comportamento Entità e ACL Entita’ organizzate in struttura gerarchica secondo il modello di X.500 Entita’ univocamente individuate da un Distinguished Name (DN) e, fissata una base, da un Relative Distinguished Name (RDN) LDAP fornisce metodi di accesso alle informazioni (ACLs), di autenticazione, di replicazione e di distribuzione dei dati DIB e DIT Le informazioni in un DS sono archiviate in un Directory Information Base (entita’ con relativi attributi) Le informazioni nel DIB sono organizzate in una stuttura ad albero : Directory Information Tree Indirizzamento La foglia di questo albero e’ cosi’ indirizzata: DN : “CN=Bslug, OU=UCSC, OU=Santa Cruz, O=CA, C=US” RDN : “CN=Bslug” Accesso via rete Il protocollo di accesso è basato su TCP/IP (X.500 è basato su OSI) Definisce le operazioni di: ricerca, modifica, inserimento, autenticazione ecc.. Operazione principale : ricerca Es Quali sono le OU in California? Quali OU hanno un fax? Esiste un indirizzo di posta per l’utente “Rossi” nelle O con sede in CAN ? Utilizzi reali di LDAP Sendmail + LDAP per la gestione dello userdb e delle mailing lists Client di posta per l'addressbook Apache + Modulo di autenticazione LDAP Windows 2000 Active Directory (Backend LDAP per l’ autenticazione degli utenti) Sistema di autenticazione al momento su alcune piattaforme Unix (PAM per Solaris e Linux) Struttura delle informazioni Primary Key Mailing Lists Mailing Info Personal Info Account Info dn:cn=Francesco Maria Taurino, ou=NA, o=INFN, c=IT cn: Francesco Maria Taurino sn: Taurino objectclass: person interests: computing interests: php activity: calcolo mailacceptinggeneralid:Francesco.Taurino mailacceptinggeneralid:Taurino maildrop:[email protected] mailname:[email protected] mail:[email protected] telephoneNumber:+39+081+676290 postalAddress:Via Cintia, Comp. Univ. M. S. Angelo username:taurino expires:NEVER fullUsername:[email protected] uid:501 gid:501 Sicurezza Le varie implementazioni dei server prevedono diversi meccanismi di accesso ai dati e di autenticazione. L’autenticazione in genere è basata su ACLs e permette diversi livelli e modalità di accesso ai dati del DIT. Per la lettura e la modifica alle informazioni si può usare Kerberos o SSL. Vantaggi dei DS Singola istanza dei dati relativi agli utenti Gestione centralizzata (anche su architettura distribuita) e uniforme Applicazioni commerciali e pubbliche in continuo aumento Possibilità di modificare lo schema per applicazioni particolari …e svantaggi Relativa lentezza degli update e dell’accesso tramite wrappers (Finger, whois) I DS in genere non sono transaction based, l’accesso concorrente in scrittura, può essere un problema (ma lo e’ sempre meno…) Gestione inizialmente complicata: necessita dell’acquisizione di conoscenze aggiuntive (ma e’ sempre piu’ semplice…)