Remove ads
In informatica LDAP (Lightweight Directory Access Protocol), è un protocollo standard per l'interrogazione e la modifica dei servizi di directory, come ad esempio un elenco aziendale di email o una rubrica telefonica, o più in generale qualsiasi raggruppamento di informazioni che può essere espresso come record di dati e organizzato in modo gerarchico. È specificato in una serie di Standard Track Request for Comments (RFCs) della Internet Engineering Task Force (IETF). La sua descrizione in ASN.1 è attualmente pubblicata nella RFC 4511.
Remove ads
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 occorressero nuovi standard per permettere ad apparecchiature e sistemi differenti di cooperare.
Vennero sviluppati indipendentemente due principali standard: uno venne ideato dal CCITT (Comité 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.
LDAP
Si voleva però un'interfaccia a 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 dello stack ISO/OSI. Inoltre LDAP semplifica certe operazioni di X.500 e omette certi aspetti intricati. Il protocollo originario è stato ideato nel 1993[1] da Tim Howes della University of Michigan, Steve Kille di Isode Limited, Colin Robbins di Nexor e Wengyik Yeong di Performance Systems International. Mark Wahl di Critical Angle Inc., Tim Howes, e Steve Kille iniziarono a lavorare nel 1996 a una nuova versione di LDAP, LDAPv3 sotto l'egida dell'Internet Engineering Task Force (IETF). LDAPv3, pubblicato per la prima volta nel 1997, ha sostituito LDAPv2 e, tra le principali novità, ha aggiunto il supporto per l'estensibilità ed ha integrato Simple Authentication and Security Layer per lo strato di autenticazione sicura. Ulteriori sviluppi alle specifiche di LDAPv3 e numerose estensioni sono state in seguito aggiunte dall'IETF in successive RFC.
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 poi 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 specificato nella RFC 4511.
DSML
Recentemente, il bisogno di unire le operazioni LDAP con XML nell'uso dei Servizi Web 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 LDAP. XML offre un metodo efficace 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 uniforme 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.
Remove ads
Il client inizia una sessione LDAP collegandosi ad un server LDAP (chiamato anche DSA, Directory System Agent). Sono comunemente definite due porte TCP per la connessione in chiaro (porta 389) e la connessione cifrata (porta 636). Le comunicazioni sono sempre iniziate dal client che invia una richiesta alla quale il server deve rispondere (vi sono alcune eccezioni a questo pattern di comunicazione, definite nelle RFC). Tutte le informazioni sono codificate e trasmesse utilizzando Basic Encoding Rules (BER).
Il client può richiedere le seguenti operazioni:
- Bind — esegue l'autenticazione
- Search — esegue una ricerca
- Compare — esegue un test di confronto tra un valore e il valore assegnato ad un attributo
- Add — aggiunge un nuovo oggetto
- Delete — cancella un oggetto
- Modify — modifica gli attributi di un oggetto
- Modify Distinguished Name (DN) — sposta o rinomina un oggetto
- Abandon — annulla una richiesta inviata in precedenza
- Extended Operation — richiesta di operazioni estese (definite in altre RFC)
- Unbind — indica al server di chiudere la connessione (non è esattamente l'inverso della Bind)
- StartTLS — estensione per utilizzare Transport Layer Security (TLS) per eseguire la Bind
Il server può inviare "Unsolicited Notifications" che non sono risposte a richieste del client. La RFC 4511 definisce un unico tipo di "Unsolicited Notifications" che il server deve inviare a tutte le connessioni aperte quando sta per chiudersi.
Un metodo alternativo di rendere sicura la connessione è quello di usare un tunnel SSL. Per consuetudine questo è indicato con lo "scheme" ldaps:// nella URL ma questa notazione non è standardizzata in nessuna RFC, anzi questo comportamento è deprecato fin dal 2003 nella RFC 3494[2] che ha ufficialmente abbandonato LDAPv2.
Remove ads
Il termine di uso comune "directory LDAP" può essere fuorviante, in quanto LDAP definisce un protocollo d'accesso e non una base di dati. 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.
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 identifica l'elemento in relazione ad un altro (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 un'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 (si veda l'esempio appena mostrato). 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. Nella definizione della classe dell'oggetto LDAP alcuni attributi sono obbligatori (MUST) mentre altri sono opzionali (MAY). Per ottenere la creazione dell'oggetto è indispensabile definire contemporaneamente tutti gli attributi obbligatori.
Ogni attributo ha una propria definizione che include anche una specifica del tipo di dato e delle regole di matching. È possibile definire attributi e classi di oggetti personalizzati.
È necessario effettuare un Check dopo ogni configurazione.
Remove ads
Esiste un formato per una URL che identifica un'operazione LDAP e che solitamente viene utilizzato per effettuare ricerche o per consentire al server di restituire dei "referrals" cioè riferimenti ad un altro server che contiene le informazioni richieste dal client:
ldap://host:port/DN?attributes?scope?filter?extensions
Non tutte le parti della URL sono obbligatorie.
- ldap:// indica lo scheme della URL e identifica il protocollo LDAP
- host è il FQDN o l'indirizzo IP del server LDAP.
- port è la porta sulla quale contattare l'host
- DN è il nome completo ("distinguished name") utilizzato per identificare la base (il punto di partenza) della ricerca.
- attributes è la lista (con gli elementi separati da virgole) di attributi da recuperare.
- scope specifico l'ambito d'azione della ricerca (può essere "base", "one" oppure "sub").
- filter è il filtro di ricerca (come definito nella RFC 4515).
- extensions sono estensioni alla richiesta LDAP
È comunemente utilizzato uno scheme di tipo "ldaps://" che, sebbene deprecato nella RFC 3494, indica una connessione LDAP con SSL. Questo è completamente differente dall'utilizzo dell'operazione StartTLS che invece utilizza lo scheme standard ldap://.
Remove ads
LDAP ha ottenuto un ampio supporto da aziende quali:
- Android (rubrica telefonica)
- Apache (attraverso Apache Directory Server)
- Apple (attraverso Open Directory/OpenLDAP)
- AT&T
- Banyan Systems
- HP
- IBM/Lotus
- ISODE (attraverso M-Vault server)
- Mandriva (attraverso Mandriva Directory 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)
- Orange
- 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)
- ESTOS (attraverso MetaDirectory 2.0)
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.
Remove ads
LDAP è definito da una serie di Request for Comments:
- RFC 4510 - LDAP: Technical Specification Road Map (rende obsolete: RFC 2251, RFC 2252, RFC 2253, RFC 2254, RFC 2255, RFC 2256, RFC 2829, RFC 2830, RFC 3377, RFC 3771)
- RFC 4511 - LDAP: The Protocol (rende obsolete: RFC 2251, RFC 2830 & RFC 3771)
- RFC 4512 - LDAP: Directory Information Models (rende obsolete: RFC 2251, RFC 2252, RFC 2256 & RFC 3674)
- RFC 4513 - LDAP: Authentication Methods and Security Mechanisms (rende obsolete: RFC 2251, RFC 2829 & RFC 2830)
- RFC 4514 - LDAP: String Representation of Distinguished Names (rende obsoleta: RFC 2253)
- RFC 4515 - LDAP: String Representation of Search Filters (rende obsoleta: RFC 2254)
- RFC 4516 - LDAP: Uniform Resource Locator (rende obsoleta: RFC 2255)
- RFC 4517 - LDAP: Syntaxes and Matching Rules (rende obsolete: RFC 2252 & RFC 2256, aggiorna: RFC 3698)
- RFC 4518 - LDAP: Internationalized String Preparation
- RFC 4519 - LDAP: Schema for User Applications (rende obsoleta: RFC 2256, aggiorna: RFC 2247, RFC 2798 & RFC 2377)
Le seguenti RFC dettagliano alcune "Best Current Practices" specifiche per LDAP:
- RFC 4520 (also BCP 64) - Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP) (sostituisce: RFC 3383)
- RFC 4521 (also BCP 118) - Considerations for Lightweight Directory Access Protocol (LDAP) Extensions
Le seguenti RFC trattano alcune estensioni specifiche di LDAPv3:
- RFC 2247 - Use of DNS domains in distinguished names (aggiornata dalle RFC 4519 & RFC 4524)
- RFC 2307 - Using LDAP as a Network Information Service
- RFC 2589 - LDAPv3: Dynamic Directory Services Extensions
- RFC 2649 - LDAPv3 Operational Signatures
- RFC 2696 - LDAP Simple Paged Result Control
- RFC 2798 - inetOrgPerson LDAP Object Class (aggiornata dalle RFC 3698, RFC 4519 & RFC 4524)
- RFC 2830 - LDAPv3: Extension for Transport Layer Security
- RFC 2849 - The LDAP Data Interchange Format (LDIF)
- RFC 2891 - Server Side Sorting of Search Results
- RFC 3045 - Storing Vendor Information in the LDAP root DSE
- RFC 3062 - LDAP Password Modify Extended Operation
- RFC 3296 - Named Subordinate References in LDAP Directories
- RFC 3671 - Collective Attributes in LDAP
- RFC 3672 - Subentries in LDAP
- RFC 3673 - LDAPv3: All Operational Attributes
- RFC 3687 - LDAP Component Matching Rules
- RFC 3698 - LDAP: Additional Matching Rules
- RFC 3829 - LDAP Authorization Identity Controls
- RFC 3866 - Language Tags and Ranges in LDAP
- RFC 3909 - LDAP Cancel Operation
- RFC 3928 - LDAP Client Update Protocol
- RFC 4370 - LDAP Proxied Authorization Control
- RFC 4373 - LBURP
- RFC 4403 - LDAP Schema for UDDI
- RFC 4522 - LDAP: Binary Encoding Option
- RFC 4523 - LDAP: X.509 Certificate Schema
- RFC 4524 - LDAP: COSINE Schema (sostituisce: RFC 1274)
- RFC 4525 - LDAP: Modify-Increment Extension
- RFC 4526 - LDAP: Absolute True and False Filters
- RFC 4527 - LDAP: Read Entry Controls
- RFC 4528 - LDAP: Assertion Control
- RFC 4529 - LDAP: Requesting Attributes by Object Class
- RFC 4530 - LDAP: entryUUID
- RFC 4531 - LDAP Turn Operation
- RFC 4532 - LDAP Who am I? Operation
- RFC 4533 - LDAP Content Sync Operation
- RFC 4876 - Configuration Profile Schema for LDAP-Based Agents
- RFC 5020 - LDAP entryDN Operational Attribute
LDAPv2 era definito nelle seguenti RFC:
- RFC 1777 - Lightweight Directory Access Protocol (sostituisce: RFC 1487)
- RFC 1778 - The String Representation of Standard Attribute Syntaxes (sostituisce: RFC 1488)
- RFC 1779 - A String Representation of Distinguished Names (sostituisce: RFC 1485)
LDAPv2 venne messo in stato "Historic" con la seguente RFC
- RFC 3494 - Lightweight Directory Access Protocol version 2 (LDAPv2) to Historic Status
Remove ads
Wikiwand in your browser!
Seamless Wikipedia browsing. On steroids.
Every time you click a link to Wikipedia, Wiktionary or Wikiquote in your browser's search results, it will show the modern Wikiwand interface.
Wikiwand extension is a five stars, simple, with minimum permission required to keep your browsing private, safe and transparent.
Remove ads