LDAP

Il Lightweight Directory Access Protocol (LDAP) è, come suggerisce il nome stesso, un protocollo standard documentato nell’RFC 2251 per accedere a servizi di directory. Una directory è un database specializzato ottimizzato per la lettura e per la ricerca dei dati attraverso filtri sofisticati, in cui il dato è formato da un attributo e relativa descrizione (ad esempio “email=rossi@azienda.it”). Le directory, intese come database, non supportano transazioni complicate o azioni di rollback che si trovano nei classici RDBMS, di solito ottimizzati per le transazioni e gli aggiornamenti complessi. Gli aggiornamenti riguardanti i repository LDAP sono tipicamente rari, in quanto i dati sono semi-statici, semplici e non richiedono transazioni; invece il database è ottimizzato per dare risposte veloci a molte ricerche contemporanee. Molti dei directory server in commercio sono in grado di replicare il loro database per aumentarne l’affidabilità, la disponibilità quindi ridurre il tempo di risposta scalando orizzontalmente.

Il tipo di informazioni inserite in LDAP è basato sul modello di entry. Una entry è l’insieme di una serie di attributi relativi ad una chiave univoca detta Distinguish Name (DN). Ogni entry ha un tipo ed uno o più valori. I tipi sono generalmente stringhe mnemoniche come “cn” per Common Name o “mail” per indirizzi e-mail. La sintassi del valore dipende dal tipo di attributo dichiarato, per esempio cn può contenere il valore Mario Rossi, mentre il tipo jpegPhoto conterrà una fotografia in formato JPEG (binario).

Le informazioni sono organizzate secondo un modello gerarchico, in una maniera simile al DNS. Tipicamente hanno sotto di loro delle alberature di tipo organizational units, ovvero organizzazioni aziendali, People che contengono le persone oppure Groups che contengono i gruppi. L’organizzazione di una alberatura LDAP è molto flessibile e può essere gestita secondo esigenze specifiche, ad esempio applicative, ma in ogni caso deve essere ben pianificata. Tutti gli oggetti però devono avere uno o più attributi di tipologia objectClass. I valori di objectClass sono relativi a degli schemi (schema appunto) a cui la entry deve obbedire: ad esempio una entry con un objectClass di valore person ha come obbligatorio il tipo sn (Surname), pertanto deve avere un attributo di tipo sn.

Abbiamo accennato precedentemente al Distinguish Name (DN): esso rappresenta il modo per fare riferimento univocamente ad una entry nel database LDAP (anche chiamata RDN). Tipicamente il DN è formato da Common Name (CN), Organizational Unit (OU) e Base DN (la base dell’alberatura LDAP); non è detto che per semplicità o per evitare univocità si possano scegliere come DN altri parametri, l’importante è che questi parametri appaiano sempre all’interno della entry e che contengano le informazioni relative alle entry da cui discendono (nel nostro esempio DEVE esistere una entry di tipo Base DN e una entry OU che derivi dalla Base DN).

LDAP definisce delle operazioni per interrogare e aggiornare il suo database. Le operazioni definite sono: aggiunta, cancellazione, modifica e ridenominazione di una entry. Molte delle volte, come abbiamo detto, LDAP viene usato per ricercare: la ricerca viene effettuata su parte dell’alberatura del database con dei criteri chiamati filtri. Ogni entry che corrisponde ai filtri determinati verrà restituita. Ad esempio, nell’alberatura dc=azienda,dc=it si possono cercare le entry relative a tutte le persone con cognome Rossi, per estrarne gli indirizzi e-mail.

LDAP è un protocollo di tipo client/server. Uno o più LDAP server contengono i dati che formano il Directory Information Tree (DIT). I client si connettono al server e sottopongono una query. Il server risponde con le informazioni e/o con un puntatore a dove il client può richiedere informazioni ulteriori, tipicamente ad un altro LDAP. Quest’ultimo processo è detto di referral. In un modello simile, non importa a quale LDAP server il client sia collegato, in quanto tutti i server vengono collegati tra di loro similmente a quanto avviene nel sistema DNS. Questo è una feature per il concatenamento di più server LDAP, ad esempio tra organizzazioni dello stessa azienda oppure tra aziende diverse che cooperano tra di loro. Per quanto riguarda la sicurezza delle informazioni contenute in una directory, LDAP contempla un meccanismo di autenticazione tra un client e un server LDAP, inoltre permette anche la crittografia attraverso SSL. L’autenticazione di un client non significa però l’autorizzazione ad accedere ai dati: un consulente non deve poter vedere il numero del telefono di casa dell’amministratore delegato! LDAP non specifica come questo deve avvenire: molti degli LDAP server sono dotati al loro interno di un sistema di Access Control Lists (ACL) per autorizzare classi di utenti a determinati attributi delle entry del database (nel nostro esempio, il consulente potrà leggere solo gli indirizzi e-mail aziendali, mentre il commerciale avrà accesso anche ai numeri dei cellulari aziendali). Tuttavia queste ACL non sono standard ed ogni implementatore ha adottato una sua metodologia.

LDAP e Kerberos

Alcuni server LDAP, spesso attraverso plugin, sono in grado di usare un password back-end differente, ovvero offrono la possibilità di accedere alla password associata ad un utente LDAP tramite altri meccanismi, ad esempio facendo il check sul file delle password di sistema (/etc/passwd), su un database RDBMS, oppure tremite Kerberos. Durante l’implementazione della soluzione, andremo a sfruttare questa caratteristica di un LDAP server per poter effettuare il controllo della password sul repository di Kerberos. Vedremo in seguito che useremo LDAP solamente come repository delle caratteristiche dell’utente (es: home directory, gid/uid, ecc.), ma non ci autenticheremo mai direttamente con LDAP. Anche se l’uso di un back-end Kerberos per la verifica delle password dell’utente sembra superfluo, non lo è per quelle legacy application che non riescono ad interfacciarsi direttamente con Kerberos, ma comunque riescono ad accedere ad un repository LDAP.

Ammettiamo ad esempio di aver acquistato un gestionale client/server che provvede all’autenticazione/autorizzazione dell’utente attraverso LDAP: usando come back-end Kerberos, l’utente potrà sempre mantenere allineata la sua password. Un caso più concreto è il file server OpenSource Samba, che alla release 3 riesce solo a sfruttare Kerberos come Active Directory client: nel nostro caso si potrebbe usare Samba con un back-end LDAP.