aai locale

CCR Roma – 12/12/2006

AAI

Proposta per un modello comunein ambito locale

E. M. V. Fasanelli

F. M. Taurino

G. Tortone

Agenda

� L’AAI dal punto di vista dei servizidi 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 gestirela 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 emailhanno bisogno di

� Lista degli utenti

� Eventuali autorizzazioni di accesso a foldercondivisi

� Possono essere collegati a server di autenticazioni centralizzati oppure avereun 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 elenchidi 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 folderimpostati 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 almenodue “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


� 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


� 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

� Calza “a pennello” sulla struttura INFN…

� Sicuro (db user/pass – traffico)

� Standard aperti e multipiattaforma

� Compatibile con le AI sicure esistenti� K5 è opzionale (ma raccomandato)

� PKI e certificati X.509

� Il DS per i servizi comuni

AAI per l’INFN

C=IT, O=INFN, L=LecceC=IT, O=INFN, L=Napoli

DS

C=IT, O=INFN

DSDS

Vantaggi

� Singole istanze dei “dati”� Consolidamento delle informazioni presenti

in diversi database di sistemi e applicazioni

� Gestione centralizzata (anche su architettura distribuita), uniforme e sicura

� Sincronizzazione efficiente

� Riduzione dei costi� 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 successiviDS

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 archiviatein un Directory Information Base (entita’ con relativi attributi)

� Le informazioni nel DIB sonoorganizzate 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 userdbe delle mailing lists

� Client di posta per l'addressbook

� Apache + Modulo di autenticazione LDAP

� Windows 2000 Active Directory (BackendLDAP per l’ autenticazione degli utenti)

� Sistema di autenticazione al momento su alcune piattaforme Unix (PAM per Solaris e Linux)

Struttura delle informazionidn:cn=Francesco Maria Taurino, ou=NA, o=INFN, c=ITcn: Francesco Maria Taurinosn: Taurinoobjectclass: personinterests: computinginterests: phpactivity: calcolo mailacceptinggeneralid:Francesco.Taurinomailacceptinggeneralid:Taurinomaildrop:[email protected]:[email protected]:[email protected]:+39+081+676290postalAddress:Via Cintia, Comp. Univ. M. S. Angelousername:taurinoexpires:NEVERfullUsername:[email protected]:501gid:501

Primary Key

Mailing Lists

Mailing Info

Account Info

Personal Info

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

aai locale

Documents