Lightweight Directory Access Protocol

Da Wikipedia, l'enciclopedia libera.

In informatica LDAP (Lightweight Directory Access Protocol) è un protocollo standard per l'interrogazione e la modifica dei servizi di directory.

Indice

1 Storia
2 Directory LDAP
- 2.1 Struttura
3 Aziende che supportano LDAP
4 RFC
5 Bibliografia
6 Voci correlate
7 Collegamenti esterni

[modifica] Storia

[modifica] Primi standard

Negli anni settanta l'integrazione tra il mondo della comunicazione e le tecnologie informatiche tracciava la strada verso lo sviluppo di nuove tecnologie di comunicazione. Molti tra i sistemi sviluppati erano incompatibili tra di loro: divenne evidente che occorrevano standard che permettessero ad apparecchiature e sistemi differenti di cooperare. Vennero sviluppati indipendentemente due principali standard. Uno venne ideato dal CCITT (Comite Consultatif International Telephonique et Telegraphique, o International Consultative Committee on Telephony and Telegraphy), e dall’ISO. Il CCITT divenne poi ITU-T. Il lavoro produsse l’ OSI Reference Model (ISO 7498), che individuò sette strati nella comunicazione di dati con il trasporto fisico al livello più basso, e i protocolli dell’applicazione ai livelli più alti. Gli altri standard si svilupparono insieme con Internet e con la ricerca portata avanti dalla DARPA negli USA. L’Internet Architecture Board (IAB) e l’Internet Engineering Task Force (IETF), sviluppano standard per Internet con una serie di documenti chiamati Request for Comments (RFC), che dopo essere approvati, implementati e usati per un certo periodo, possono diventare standard (STD). Prima che una proposta diventi una RFC, è chiamata Internet Draft.

Questi due processi di standardizzazione affrontano il problema da due differenti prospettive. L’approccio OSI incomincia da zero e definisce standard usando un modello formale senza richiedere implementazioni. Internet usa un approccio meno formale, dove chiunque può proporre e commentare RFC che vengono poi implementati per verificarne la fattibilità. I protocolli OSI si sono sviluppati lentamente, specialmente nel mercato dei personal computer. Al contrario TCP/IP e Internet hanno avuto un’applicazione maggiore e si sono sviluppati rapidamente. Alcune compagnie svilupparono così i propri protocolli e prodotti per il network. In ogni caso i protocolli OSI ebbero importanza nei grossi sistemi distribuiti che si stavano sviluppando in maniera particolare. Un’area importante era quella dei servizi di directory. Il CCITT creò lo standard X.500 nel 1988, che divenne ISO 9594 Data Communications Network Directory Recommendations X.500-X.521 nel 1990.

Secondo questo standard, la comunicazione tra directory client e server usa il directory access protocol (DAP). Ma per essere operativo, il DAP richiede l’intera pila OSI, poiché è un protocollo del livello applicazioni.

[modifica] LDAP

Si voleva però un'interfaccia ad una directory server X.500 che usasse meno risorse o un protocollo leggero. Per questo motivo venne sviluppato LDAP, come alternativa snella al DAP. LDAP richiede il più leggero e popolare protocollo TCP/IP invece della pila OSI. Inoltre LDAP semplifica certe operazioni di X.500 e omette certi aspetti intricati. Il protocollo è stato ideato da Tim Howes di Netscape, Steve Kille di ISODE e Mark Angle di Critical Angle Inc..

Due precursori di LDAP sono rappresentati dagli RFC rilasciati da IETF, Directory Assistance Service (RFC 1202) e DIXIE Protocol Specification (RFC 1249). Sono entrambi RFC informativi e non vennero proposti come standard. Il directory assistance service (DAS) definì un metodo per il quale un directory client può comunicare con un proxy su un host OSI che rilasciava richieste X.500 a nome del client. DIXIE è simile a DAS, ma offre una conversione più diretta del DAP. La prima versione di LDAP venne definita in X.500 Lightweight Access Protocol (RFC 1487), sostituito da Lightweight Directory Access Protocol (RFC 1777).

Più avanti LDAP raffinò le idee e i protocolli di DAS e DIXIE. Ha un’implementazione più neutrale e riduce la complessità del client. La maggior parte dei lavori in DIXIE e LDAP proviene dall’Università del Michigan, che offre una documentazione delle implementazioni di LDAP e mantiene pagine Web e mailing list su LDAP. RFC 1777 definisce il protocollo LDAP stesso, insieme con: “La rappresentazione in Stringhe e Sintassi degli Attributi Standard” (RFC 1778), “Rappresentazione in Stringa dei Distinguished Name” (RFC 1779), “Formato per l’URL LDAP” (RFC 1959), “Rappresentazione in stringa dei filtri di ricerca LDAP” (RFC 1960) La versione 2 di LDAP ha ottenuto lo stato di standard bozza nel processo di standardizzazione IETF, un passo dall’essere uno standard. Oggi, tutte le implementazione dei directory server sono basati su LDAP versione 3.

[modifica] DSML

Recentemente, il bisogno di unire le operazioni LDAP con XML nell’uso dei Web Services ha dato alla luce un nuovo linguaggio chiamato Directory Services Markup Language (DSML). La più recente versione è DSMLv2. DSML è un generico formato per importare/esportare tali informazioni. In DSML i dati della directory possono essere condivisi tra applicazioni che supportano tale formato senza esporre il protocollo 17 LDAP. XML offre un metodo effettivo per presentare e trasferire i dati; i servizi di directory permettono di condividere e gestire i dati e sono così un prerequisito necessario per effettuare operazioni online. DSML è progettato per rendere il servizio di directory più dinamico impiegando XML. DSML è uno schema in XML per lavorare con le directory, ed è definito con un Document Content Description (DCD). Così DSML permette ai programmatori di XML di accedere alle directory LDAP senza avere a che fare con l'interfaccia LDAP o API per l’accesso alle directory, offrendo un modo consistente per lavorare con directory multiple e differenti.

Ldap ha influenzato lo sviluppo di altri protocolli di rete, come il Service Provisioning Markup Language (SPML) e il Service Location Protocol.

[modifica] Directory LDAP

Il termine di uso comune "directory LDAP" può essere fuorviante. Nessun tipo specifico di directory è una "directory LDAP". Si potrebbe ragionevolmente usare il termine per descrivere qualsiasi directory accessibile tramite LDAP e che possa identificare gli oggetti contenuti tramite nomi X.500, ma Directory come OpenLDAP e i suoi predecessori sviluppati presso l'Università del Michigan, anche se progettati espressamente per l'accesso tramite LDAP piuttosto che come ponte verso X.500, come avveniva per i prodotti forniti da ISODE, non sono directory LDAP più di qualsiasi altra directory accessibile tramite protocollo LDAP.

[modifica] Struttura

L'informazione all'interno di una directory è organizzata in elementi chiamati entry.

Gli elementi di una directory LDAP presentano una struttura gerarchica che riflette confini politici, geografici o organizzativi. Nel modello X.500 originale, gli elementi che rappresentano gli stati appaiono in cima all'albero, con sotto di essi gli elementi per gli stati federali o le organizzazioni nazionali (normalmente nelle installazioni di LDAP vengono usati i nomi del DNS per strutturare i livelli più alti della gerarchia). Più in basso potrebbero apparire elementi per rappresentare le divisioni all'interno di una singola organizzazione, singole persone, documenti, stampanti o qualsiasi altra cosa.

Nella struttura ad albero, ad ogni livello esiste un Relative distinguished name (RDN) che lo identifica (ad esempio ou=people). L'unione di tutti i RDN, presi in successione dal nodo foglia fino alla radice, costituisce il distinguished name (DN), una stringa che rappresenta univocamente una entry nella directory. Un dn può essere ad esempio:

"cn=John Doe,ou=people,dc=wikipedia,dc=org"

Ciascuna entry ha una serie di attributi, costituiti dall'associazione attributo-valore; per ogni attributo possono esserci più valori. Ognuno degli attributi dell'elemento è definito come membro di una classe di oggetti, raggruppati in uno schema. Ogni elemento nella directory è associato a una o più classi di oggetti, che definiscono se un attributo sia opzionale o meno, e che tipo di informazioni questo contenga. I nomi degli attributi solitamente sono scelti per essere facilmente memorizzabili, per esempio "cn" per common name, o "mail" per un indirizzo e-mail. I valori degli attributi dipendono dal tipo, e la maggioranza dei valori non binari sono memorizzati in LDAPv3 (LDAP versione 3) come stringhe UTF-8. Per esempio, un attributo di tipo mail potrebbe contenere il valore "user@example.com", mentre un attributo "jpegPhoto" potrebbe contenere una fotografia nel formato (binario) JPEG.

[modifica] Aziende che supportano LDAP

LDAP ha ottenuto un ampio supporto da aziende quali:

Apache (attraverso Apache Directory Server)
Apple (attraverso Open Directory/OpenLDAP)
AT&T
Banyan
HP
IBM/Lotus
ISODE (attraverso M-Vault server)
Microsoft (attraverso Active Directory)
Netscape (oggi nei prodotti Sun Microsystems e Red Hat)
Novell (attraverso eDirectory)
OctetString (attraverso VDE server)
Oracle (attraverso Oracle Internet Directory)
Radiant Logic (attraverso RadiantOne Virtual Directory Server)
Red Hat (attraverso Red Hat Directory Server)
SiemensAG (attraverso DirX server)
SGI
Sun (attraverso i directory server iPlanet e Sun ONE)
Symlabs (attraverso Directory Extender)

oltre che in implementazioni open source/free software quali OpenLDAP e Fedora Directory Server. Anche l'Apache HTTP Server usato come proxy (dal modulo mod_proxy) supporta LDAP.