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…)