Lightweight Directory Access Protocol (LDAP) este inițial unprotocolpentru interogarea și modificarea serviciilor dedirector(este o evoluție a protocolului DAP). Acest protocol se bazează peTCP / IP. Cu toate acestea, a evoluat într-unstandardpentru sistemele de directoare, incluzând unmodel dedate, un model de denumire, un model funcțional bazat pe LDAP, un model de securitate și un model de replicare. Este o structură de copac în care fiecare dintre noduri este alcătuit din atribute asociate valorilor lor. LDAP este mai puțin complex decât modelul X.500 decretat deITU-T.
Denumirea elementelor care constituie arborele (rădăcină, ramuri, frunze) reflectă adesea modelul politic, geografic sau organizațional al structurii reprezentate. Tendința actuală este de a folosi denumirea DNS pentru elementele de bază ale directorului (rădăcină și primele ramuri, componente ale domeniului sau dc =… ). Ramurile mai profunde ale directorului pot reprezenta unități sau grupuri organizaționale ( unități organizaționale sau ou = ... ), persoane ( nume comun sau cn = ... sau chiar identificator utilizator uid = ... ). Ansamblul tuturor componentelor (de la cele mai precise la cele mai generale) ale unui nume formează numele său distinct , următorul exemplu prezintă două:
Cea mai recentă versiune a protocolului este LDAPv3. Această versiune este definită de IETF în mai multe RFC-uri începând cu RFC 4510.
LDAP a fost inițial conceput pentru acces ușor la directoarele X.500. Aceste directoare au fost interogate în mod tradițional folosind XAP00 Directory Access Protocol (DAP), care a necesitat utilizarea stivei de protocol model OSI . Utilizarea unui gateway LDAP / DAP a permis accesul la un server DAP pe o rețea TCP / IP. Acest model de director este derivat din DIXIE și Directory Assistance Service .
Apariția directoarelor LDAP native a urmat rapid, la fel și apariția serverelor care susțin atât DAP, cât și LDAP. Directoarele au devenit populare în afaceri, deoarece nu mai era necesară implementarea unei rețele OSI. În prezent, protocoalele de acces la directorul X.500 (inclusiv DAP) pot fi utilizate direct pe TCP / IP.
Protocolul a fost creat de Tim Howes de la Universitatea din Michigan , Steve Kille de la ISODE și Wengyik Yeong de la Performance Systems International în 1993 . Dezvoltările care au urmat au fost conduse de Internet Engineering Task Force (IETF).
Inițial protocolul a fost denumit Lightweight Directory Browsing Protocol ( LDBP ), deoarece permite doar căutarea datelor. A fost redenumit la adăugarea de noi posibilități (adăugare, modificare).
LDAP a influențat o serie de protocoale Internet, inclusiv cele mai recente versiuni ale X.500 : XML Enabled Directory (XED), Directory Services Markup Language (DSML), Service Provisioning Markup Language (SPML) și Service Location Protocol (SLP)).
Un client începe o sesiune LDAP prin conectarea la portul TCP 389 al serverului. Clientul trimite apoi cereri de operare către server. Serverul trimite răspunsurile înapoi. Cu câteva excepții, clientul nu trebuie să aștepte un răspuns de la server pentru a trimite noi solicitări, iar serverul își poate trimite răspunsurile în orice ordine.
După stabilirea conexiunii la server, operațiile tipice sunt:
În plus, serverul poate trimite notificări nesolicitate care nu sunt răspunsuri la solicitări, de exemplu înainte de a închide o conexiune inactivă.
O metodă de securizare a comunicațiilor LDAP este utilizarea unui tunel TLS / SSL . Când utilizați URL-uri, această utilizare este tradusă prin numele protocolului ldaps pentru a înlocui ldap . Portul TCP standard pentru ldaps este 636.
Protocolul LDAP utilizează notația ASN.1 și mesajele sunt codificate cu formatul binar BER . Cu toate acestea, folosește reprezentarea textuală pentru o serie de atribute și tipuri de ASN.1.
Directoarele LDAP urmează modelul X.500 și arhitectura nativă multi-chiriaș :
Faptul că atributele pot fi multivalorate este o diferență majoră între directoarele LDAP și RDBMS . În plus, dacă un atribut nu are valoare, acesta lipsește pur și simplu din intrare.
Fiecare intrare are un identificator unic, Numele Distins (DN). Acesta este alcătuit din numele său distinctiv relativ (RDN) urmat de DN-ul părintelui său. Este o definiție recursivă. Putem face analogia cu o altă structură de arbore, sistemele de fișiere; DN fiind calea absolută și RDN calea relativă la un director. De obicei, RDN-ul unei intrări care reprezintă o persoană este atributul uid :
dc=org | dc=example / \ ou=people ou=groups | uid=totoRDN-ul lui foo este rdn: uid = foo , DN-ul său este dn: uid = foo, ou = oameni, dc = exemplu, dc = org .
O intrare poate arăta ca următoarea reprezentare atunci când este formatată ca LDIF :
dn: cn=John Doe, dc=example, dc=org cn: John Doe givenName: John sn: Doe telephoneNumber: +1 555 6789 telephoneNumber: +1 555 1234 mail: [email protected] manager: cn=Barbara Doe, dc=exemple, dc=com objectClass: inetOrgPerson objectClass: organizationalPerson objectClass: person objectClass: topdn este numele intrării, nu este un atribut al intrării. „cn = John Doe” este RDN-ul intrării și „dc = exemplu, dc = org” este DN-ul părintelui său. Celelalte linii arată atributele intrării. Numele atributelor sunt uneori abrevieri pentru cele mai frecvente: "cn" pentru numele comun , "dc" pentru componenta domeniului , "sn" pentru numele de familie .
Un server conține un subarborel a cărui rădăcină este o intrare specifică și toți copiii săi, de exemplu: "dc = exemplu, dc = org". Serverele pot conține, de asemenea, referințe la alte servere, astfel încât accesarea unei intrări („ou = un serviciu, dc = exemplu, dc = org”) poate returna o recomandare către un alt server care conține subarborele dorit. Clientul poate contacta apoi (automat sau nu) celălalt server. Unele servere acceptă înlănțuirea, ceea ce permite serverului să interogeze alte servere pentru a trimite înapoi informațiile dorite către client.
Rezultatele returnate de server nu sunt sortate, fie pentru intrări, pentru atributele intrărilor sau pentru valorile atributelor.
Clientul oferă fiecărei cereri un ID de mesaj , serverul răspunde la cerere cu același identificator. Răspunsul include un cod de rezultat numeric care indică starea cererii (succes, eșec, ...). Răspunsul include, de asemenea, orice date care pot rezulta dintr-o căutare. De asemenea, include un cod de identificare.
Operațiunea de legare autentifică clientul în cadrul serverului. Simplu se leagă trimite DN utilizatorului și parola în clar, care este motivul pentru care conexiunea trebuie să fie asigurată prin TLS . Serverul verifică parola comparând-o cu atributul userPassword (de obicei) al intrării corespunzătoare. Valoarea atributului care conține parola începe cu numele în paranteze a algoritmului utilizat pentru codificarea parolei (de exemplu: userPassword: {md5} aGZh5 ...).
Anonim se leagă , adică fără a oferi un nume de utilizator sau parola, pune conexiunea într - o stare anonimă. Prin urmare, clientul nu va mai putea efectua anumite operațiuni pe tot sau pe parte din director, în funcție de ACL - urile puse în aplicare.
SASL bind permite utilizarea altor mecanisme de autentificare: Kerberos , certificat de client, etc.
Pasul de legare permite, de asemenea, clientului și serverului să cadă de acord asupra versiunii protocolului de utilizat. De obicei se folosește versiunea 3. Este chiar posibil ca serverul să refuze să comunice cu clienții într-un protocol mai mic decât al său.
Operațiunea StartTLS stabilește o conexiune sigură între client și server utilizând tehnica TLS , moștenită de la SSL . Această securitate funcționează pe două puncte: confidențialitatea (o terță parte nu poate înțelege schimbul) și integritatea datelor (datele sunt validate printr-o semnătură). În timpul negocierii TLS, serverul trimite certificatul X.509 către client pentru a-și dovedi identitatea. Clientul poate răspunde prin trimiterea certificatului său, dar identificarea clientului este opțională. De obicei, este posibil să configurați clienții și serverele pentru a ști dacă certificatele sunt opționale sau esențiale.
Serverele acceptă, în general, protocolul non-standard „LDAPS” ( LDAP peste SSL ). Acest protocol folosește portul 636 spre deosebire de TLS care folosește portul 389 (la fel ca LDAP nesecurizat). Protocolul LDAPS diferă de LDAP în două moduri:
Operația de căutare este utilizată atât pentru a căuta, cât și pentru a prelua intrări. Parametrii săi sunt:
Serverul returnează intrările care se potrivesc, urmate de codul de returnare al comenzii (cod de returnare).
Operația Comparare ia ca argument un DN, un nume de atribut și o valoare de atribut, apoi verifică dacă intrarea corespunzătoare conține într-adevăr un atribut cu această valoare.
Notă : Nu există nicio operație de tip Citire . Operația de căutare este utilizată pentru accesul direct la o intrare. În acest caz, parametrul baseObject este DN-ul intrării de citit, iar parametrul scop este utilizat cu valoarea de bază .
Add , Delete , Modificare operații de actualizare ia ca argument DN de intrare care urmează să fie actualizate.
Modificarea are nevoie în plus față de lista de atribute de modificat, precum și modificarea care trebuie făcută: ștergerea atributului sau a anumitor valori ale atributului (atributele pot fi cu mai multe valori), adăugarea unei valori, înlocuirea o valoare de.
Adăugarea unei intrări poate conține, de asemenea, o listă de atribute și valori de asociat cu intrarea.
Modificarea DN (mutare / redenumire) ia ca argument RDN-ul intrării și, opțional, DN-ul noului părinte, precum și un marker care indică dacă ștergeți sau nu vechiul RDN. Suportul pentru redenumirea unui întreg arbore secundar depinde de server.
O operațiune de actualizare este atomică, adică alte operații vor vedea fie intrarea nouă, fie cea veche. Cu toate acestea, LDAP nu definește un principiu de tranzacție, care permite mai multor clienți să modifice o intrare în același timp. Cu toate acestea, serverele pot utiliza extensii pentru a o suporta.
Operațiile extinse sunt operații generice care vă permit să definiți operațiuni noi. De exemplu , operațiile Anulare , Modificare parolă și StartTLS .
AbandonOperațiunea Abandon trimite o cerere către server pentru a-i spune să anuleze o operațiune oferindu-i identificatorul. Serverul nu are nicio obligație să onoreze cererea. Din păcate, atât operațiunea de abandon , cât și abandonul efectiv al unei operațiuni nu returnează un răspuns. Prin urmare, operațiunea de anulare extinsă a fost definită pentru a returna un răspuns, dar nu toate serverele îl acceptă.
Operația Unbind anulează orice operațiune curentă și închide conexiunea. Nu există răspuns. Numele său are motive istorice, nu este operațiunea contrară Bind .
Clienții pot încheia o sesiune închizând conexiunea, dar este mai curat să folosiți Unbind . Acest lucru permite serverului să diferențieze erorile de rețea de clienții descurajați.
Există un format URI LDAP, dar nu toți clienții îl acceptă. Serverele îl folosesc pentru a informa clienții despre trimiterile către alte servere. Formatul este după cum urmează:
ldap://hôte:port/DN?attributs?profondeur?filtre?extensioncu:
La fel ca în toate URI-urile, caracterele speciale trebuie evitate urmând algoritmul furnizat de RFC 3986 .
Puteți întâlni, de asemenea, URI-uri folosind modelul nestandard " ldaps ".
De exemplu :
ldap://ldap.example.com/cn=John%20Doe,dc=example,dc=comreturnează toate atributele intrării „John Doe”,
ldap:///dc=example,dc=com??sub?(givenName=John)caută intrarea cu prenumele „John” în director începând de la rădăcină.
Conținutul intrărilor într-un director LDAP este guvernat de scheme .
Schemele definesc tipurile de atribute pe care intrările de director le pot conține. Definiția unui atribut include sintaxă, majoritatea atributelor non-binare din LDAPv3 folosesc sintaxa șirului UTF-8 . De exemplu, atributul mail poate conține „ [email protected] ”, atributul jpegPhoto poate conține o fotografie în format binar JPEG , atributul membru poate conține DN-ul unei intrări de director.
Definiția unui atribut indică, de asemenea, dacă atributul este monovalorat sau multivalorizat, în funcție de care reguli vor fi efectuate căutările / comparațiile (sensibile la caz sau nu, căutarea de șiruri de caractere sau nu).
Schemele definesc clase de obiecte. Fiecare intrare de director trebuie să aibă cel puțin o valoare pentru atributul objectClass , care este o clasă de obiect definită în scheme. De obicei, atributul objectClass are mai multe valori și conține clasa de top , precum și un număr de alte clase.
La fel ca în programarea orientată pe obiecte , clasele vă permit să descrieți un obiect prin asocierea atributelor cu acesta. Clasele LDAP reprezintă oameni, organizații ... Faptul că o intrare aparține unei clase (deci atributul objectClass conține numele clasei) îi permite să utilizeze atributele acestei clase. Unele atribute sunt obligatorii, iar altele sunt opționale. De exemplu, dacă intrarea utilizează clasa de persoană , trebuie să aibă o valoare pentru atributele sn și cn și poate avea opțional o valoare pentru atributele userPassword și telephoneNumber . Deoarece intrările au de obicei mai multe clase, diferențierea între atributele necesare și cele opționale poate fi destul de complexă.
Elementele unei scheme au un nume și un identificator unic numit Identificator de obiect ( OID ).
Multe servere expun schemele de directoare ca intrări LDAP accesibile din schema DN cn =. Administratorii pot defini propria schemă în plus față de schemele standard.
Unele posibile operațiuni sunt lăsate la latitudinea dezvoltatorului sau administratorului. De exemplu, stocarea datelor nu este specificată de protocol. Serverul poate utiliza fișiere plate sau un RDBMS sau poate fi pur și simplu o poartă către un alt server. Controalele de acces ( ACL ) nu sunt, de asemenea, standardizate, deși apare o utilizare obișnuită.
LDAP este un protocol extensibil, care face ca operațiuni noi să apară pe unele servere și nu pe altele. De exemplu, sortarea rezultatelor.
Principalul interes al LDAP este standardizarea autentificării. Este foarte ușor să programați un modul de autentificare utilizând LDAP dintr-o limbă care are un API LDAP. Operațiunea de legare permite autentificarea unui utilizator. Tot mai multe aplicații web au un modul de autentificare care acceptă LDAP.
În sistemele GNU / Linux recente, există o adoptare din ce în ce mai mare a unei baze de date care utilizează LDAP în loc de fișiere plate passwd și shadow . Datele pot fi accesate de modulele PAM și NSS .
LDAP este definit de o serie de Cereri de comentarii :
Următoarele RFC detaliază cele mai bune practici de adoptat cu privire la LDAP:
Următoarea este o listă care conține RFC-uri care definesc extensiile LDAPv3:
LDAPv2 a fost definit de următoarele RFC-uri:
LDAPv2 a fost mutat la Stare istorică de către următorul RFC:
Alte RFC-uri: