Vai al contenuto

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, 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.

Storia

[modifica | modifica wikitesto]

Primi standard

[modifica | modifica wikitesto]

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

[modifica | modifica wikitesto]

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

[modifica | modifica wikitesto]

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.

Panoramica del protocollo

[modifica | modifica wikitesto]

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.

Directory LDAP

[modifica | modifica wikitesto]

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

[modifica | modifica wikitesto]

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.

URL LDAP

[modifica | modifica wikitesto]

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://.

Aziende che supportano LDAP

[modifica | modifica wikitesto]

LDAP ha ottenuto un ampio supporto da aziende quali:

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.

RFC

[modifica | modifica wikitesto]

LDAP è definito da una serie di Request for Comments:

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:

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

Note

[modifica | modifica wikitesto]
  1. ^ Tim Howes, The Lightweight Directory Access Protocol: X.500 Lite (PDF), su openldap.org. URL consultato il 26 dicembre 2012.
  2. ^ (EN) RFC 3494 — Lightweight Directory Access Protocol version 2 (LDAPv2) to Historic Status, su datatracker.ietf.org, Internet Engineering Task Force.

Bibliografia

[modifica | modifica wikitesto]

Voci correlate

[modifica | modifica wikitesto]

Collegamenti esterni

[modifica | modifica wikitesto]
Controllo di autoritàLCCN (EN) sh2001008354 · GND (DE) 4537748-0 · BNF (FR) cb13612263r (data) · J9U (EN, HE) 987007551837305171
  Portale Telematica: accedi alle voci di Wikipedia che parlano di reti, telecomunicazioni e protocolli di rete
Estratto da "https://it.wikipedia.org/w/index.php?title=Lightweight_Directory_Access_Protocol&oldid=140681444"