Protocol schematic de acces la registru

De la Wikipedia, enciclopedia liberă.
Salt la navigare Salt la căutare

În informatică LDAP ( Lightweight Directory Access Protocol ) este un protocol standard pentru interogarea și modificarea serviciilor de directoare , cum ar fi o listă de e-mail corporativă sau o agendă telefonică sau, în general, orice grupare de informații care poate fi exprimată ca o înregistrare de date și organizată ierarhic. Acesta este specificat într-o serie de cereri de urmărire standard pentru comentarii (RFC) ale tehnologiei Internet Engineering (IETF). Descrierea sa în ASN.1 este publicată în prezent în RFC 4511 .

Istorie

Primele standarde

În anii șaptezeci , integrarea dintre lumea comunicațiilor și a tehnologiilor informaționale a pregătit calea dezvoltării noilor tehnologii de comunicare. Multe dintre sistemele dezvoltate erau incompatibile între ele: a devenit evident că sunt necesare noi standarde pentru a permite echipamentelor și sistemelor diferite să coopereze.

Două standarde principale au fost elaborate independent: unul a fost conceput de CCITT (Comité Consultatif International Telephonique et Telegraphique, sau Comitetul consultativ internațional pentru telefonie și telegrafie) și de către ISO . CCITT a devenit ulterior ITU-T . Lucrarea a produs Modelul de referință OSI ( ISO 7498 ), care a identificat șapte straturi în comunicarea datelor cu transport fizic la cel mai scăzut nivel și protocoale de aplicație la cele mai înalte niveluri.

Celelalte standarde s-au dezvoltat împreună cu Internetul și cercetarea DARPA în SUA . Internet Architecture Board (IAB) și Internet Engineering Task Force (IETF) dezvoltă standarde pentru Internet cu o serie de documente numite Request for Comments (RFC), care după ce au fost aprobate, implementate și utilizate pentru o anumită perioadă, pot deveni standarde (STD). Înainte ca o propunere să devină RFC, aceasta se numește Internet Draft .

Aceste două procese de standardizare abordează problema din două perspective diferite. Abordarea OSI începe de la zero și stabilește standarde folosind un model formal fără a necesita implementări. Internetul folosește o abordare mai puțin formală, în care oricine poate propune și comenta RFC-uri, care sunt apoi implementate pentru a-și verifica fezabilitatea. Protocoalele OSI s-au dezvoltat lent, în special pe piața computerelor personale. În schimb, TCP / IP și Internet au avut o aplicație mai mare și s-au dezvoltat rapid.

Unele companii și-au dezvoltat astfel propriile protocoale și produse pentru rețea. În orice caz, protocoalele OSI au avut importanță în marile sisteme distribuite care se dezvoltau într-un mod special. Un domeniu important a fost cel al serviciilor de directoare . CCITT a creat standardul X.500 în 1988 , care a devenit Recomandările X.500-X.521 din Directorul rețelei de comunicații de date ISO 9594 în 1990 .

Conform acestui standard, comunicarea dintre directoarele client și server utilizează protocolul de acces la director (DAP). Dar pentru a fi operațional, DAP necesită întreaga stivă OSI, deoarece este un protocol de strat de aplicație .

LDAP

Cu toate acestea, am dorit o interfață cu un server de director X.500 care să utilizeze mai puține resurse sau un protocol ușor. Din acest motiv, LDAP a fost dezvoltat ca o alternativă slabă la DAP. LDAP necesită protocolul TCP / IP mai ușor și mai popular în locul stivei OSI. În plus, LDAP simplifică anumite operații X.500 și omite anumite aspecte complicate. Protocolul original a fost conceput în 1993 [1] de Tim Howes de la Universitatea din Michigan , Steve Kille de la Isode Limited , Colin Robbins de la Nexor și Wengyik Yeong de la Performance Systems International . Mark Wahl de la Critical Angle Inc., Tim Howes și Steve Kille au început să lucreze în 1996 la o nouă versiune a LDAP, LDAPv3 sub auspiciile Internet Engineering Task Force (IETF). LDAPv3, publicat pentru prima dată în 1997, a înlocuit LDAPv2 și, printre principalele inovații, a adăugat suport pentru extensibilitate și autentificare simplă integrată și strat de securitate pentru stratul de autentificare sigură. Dezvoltări ulterioare ale specificației LDAPv3 și numeroase extensii au fost adăugate ulterior de IETF în RFC-uri ulterioare.

Doi precursori ai LDAP sunt RFC-urile emise de IETF, Directory Assistance Service ( RFC 1202 ) și DIXIE Protocol Specification ( RFC 1249 ). Ambele sunt RFC-uri informaționale și nu au fost propuse ca standard. Directory Assistance Service (DAS) a definit o metodă prin care un director client poate comunica cu un proxy pe o gazdă OSI care a emis cereri X.500 în numele clientului. DIXIE este similar cu DAS, dar oferă o conversie mai directă decât DAP. Prima versiune a LDAP a fost definită în X.500 Lightweight Access Protocol ( RFC 1487 ), care a fost ulterior înlocuit cu Lightweight Directory Access Protocol ( RFC 1777 ).

Ulterior LDAP a rafinat ideile și protocoalele DAS și DIXIE. Are o implementare mai neutră și reduce complexitatea clientului. Cea mai mare parte a activității în DIXIE și LDAP provine de la Universitatea din Michigan , care furnizează documentația implementărilor LDAP și menține paginile web și listele de corespondență pe LDAP. RFC 1777 definește protocolul LDAP în sine, împreună cu: „Reprezentarea șirului și sintaxa atributelor standard” ( RFC 1778 ), „Reprezentarea șirului numelui distinct” ( RFC 1779 ), „Format pentru LDAP URL” ( RFC 1959 ), „Șirul Reprezentarea filtrelor de căutare LDAP "( RFC 1960 ) Versiunea 2 a LDAP a atins proiectul de statut standard în procesul de standardizare IETF, la un pas de a fi un standard. Astăzi, toate implementările serverului de directoare se bazează pe versiunea LDAP 3 specificată în RFC 4511 .

DSML

Recent, nevoia de a combina operațiunile LDAP cu XML în utilizarea serviciilor web a dat naștere unui nou limbaj numit Directory Services Markup Language ( DSML ). Cea mai recentă versiune este DSMLv2. DSML este un format generic pentru importul / exportul acestor informații. În DSML, datele din director pot fi partajate între aplicațiile care acceptă acest format fără a expune protocolul LDAP. XML oferă un mod eficient de prezentare și transfer de date; Serviciile de director vă permit să partajați și să gestionați date și sunt astfel o condiție prealabilă necesară pentru tranzacțiile online. DSML este conceput pentru a face serviciul director mai dinamic prin utilizarea XML. DSML este o schemă XML pentru lucrul cu directoare și este definită cu o descriere a conținutului documentului (DCD). Astfel DSML permite programatorilor XML să acceseze directoare LDAP fără a fi nevoie să se ocupe de interfața LDAP sau API pentru acces la directoare, oferind o modalitate uniformă de a lucra cu directoare multiple și diferite.

LDAP a influențat dezvoltarea altor protocoale de rețea , cum ar fi Limbajul de marcare a furnizorului de servicii ( SPML ) și Protocolul de localizare a serviciului .

Prezentare generală a protocolului

Clientul inițiază o sesiune LDAP conectându-se la un server LDAP (numit și DSA, Directory System Agent ). Două porturi TCP sunt definite în mod obișnuit pentru conexiunea cu text simplu (portul 389) și conexiunea criptată (portul 636). Comunicațiile sunt întotdeauna inițiate de către client care trimite o cerere la care serverul trebuie să răspundă (există câteva excepții de la acest model de comunicare, definit în RFC-uri). Toate informațiile sunt codificate și transmise utilizând regulile de codificare de bază (BER).

Clientul poate solicita următoarele:

  • Bind - autentifică
  • Căutare - efectuează o căutare
  • Comparați - efectuează un test de comparație între o valoare și valoarea atribuită unui atribut
  • Adăugare - adaugă un obiect nou
  • Șterge - șterge un obiect
  • Modificare - modifică atributele unui obiect
  • Modify Distinguished Name (DN) - mutați sau redenumiți un obiect
  • Abandonează - anulează o solicitare trimisă anterior
  • Operațiune extinsă - cerere pentru operațiuni extinse (definită în alte RFC-uri)
  • Unbind - spune serverului să închidă conexiunea (nu exact inversul Bind)
  • StartTLS - extensie pentru a utiliza Transport Layer Security (TLS) pentru a efectua Bind

Serverul poate trimite „notificări nesolicitate” care nu sunt răspunsuri la solicitările clientului. RFC 4511 definește un singur tip de „notificări nesolicitate” pe care serverul trebuie să le trimită tuturor conexiunilor deschise atunci când este pe cale să se închidă.

O metodă alternativă de securizare a conexiunii este utilizarea unui tunel SSL . În mod obișnuit, acest lucru este indicat cu „schema” ldaps: // în URL, dar această notație nu este standardizată în niciun RFC, într-adevăr acest comportament este depreciat din 2003 în RFC 3494 [2], care a abandonat oficial LDAPv2.

Director LDAP

Termenul folosit în mod obișnuit „ director LDAP ” poate fi înșelător, deoarece LDAP definește un protocol de acces și nu o bază de date. Niciun tip specific de director nu este un „ director LDAP ”. Termenul ar putea fi utilizat în mod rezonabil pentru a descrie orice director accesibil prin LDAP și care poate identifica obiectele conținute prin nume X.500, dar Directoare precum OpenLDAP și predecesorii săi s-au dezvoltat la Universitatea din Michigan, deși concepute special pentru acces prin LDAP mai degrabă decât ca o punte către X.500 , așa cum a fost cazul produselor furnizate de ISODE, nu sunt mai multe directoare LDAP decât orice alt director accesibil prin protocolul LDAP.

Structura

Informațiile dintr-un director sunt organizate în elemente numite intrări .

Elementele unui director LDAP au o structură ierarhică care reflectă limitele politice, geografice sau organizaționale. În modelul original X.500, elementele care reprezintă statele apar în partea de sus a arborelui, cu elemente pentru statele federale sau organizațiile naționale sub ele (în mod normal, în instalațiile LDAP, numele DNS sunt utilizate pentru a structura nivelurile superioare în ierarhie). Elementele pot apărea mai jos pentru a reprezenta diviziuni dintr-o singură organizație, persoane, documente, imprimante sau orice altceva.

În structura arborelui, la fiecare nivel există un nume distinct relativ (RDN) care identifică elementul în raport cu altul (de exemplu ou = oameni ). Unirea tuturor RDN-urilor, luate succesiv de la nodul frunză la rădăcină, constituie numele distins (DN), un șir care reprezintă în mod unic o intrare în director. Un DN poate fi, de exemplu:

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

Fiecare intrare are o serie de atribute , constând din asocierea atribut-valoare; pentru fiecare atribut pot exista mai multe valori (vezi exemplul prezentat recent). Fiecare dintre atributele elementului este definit ca un membru al unei clase de obiecte, grupate într-o schemă. Fiecare articol din director este asociat cu una sau mai multe clase de obiecte, care definesc dacă un atribut este opțional sau nu și ce tip de informații conține. Numele atributelor sunt de obicei alese pentru a fi ușor de reținut, de exemplu „ cn ” pentru numele comun sau „mail” pentru o adresă de e- mail . Valorile atributelor depind de tip și majoritatea valorilor non-binare sunt stocate în LDAPv3 (versiunea LDAP 3) ca șiruri UTF-8 . De exemplu, un atribut de tip mail poate conține valoarea „[email protected]”, în timp ce un atribut „jpegPhoto” poate conține o fotografie în format JPEG (binar). În definiția clasei de obiecte LDAP sunt necesare unele atribute (TREBUIE), în timp ce altele sunt opționale (MAI). Pentru a obține crearea obiectului este esențial să se definească toate atributele obligatorii în același timp.

Fiecare atribut are propria sa definiție, care include, de asemenea, o specificație a tipului de date și a regulilor de potrivire. Puteți defini clase și atribute de obiecte personalizate.

Este necesar să efectuați o verificare după fiecare configurație.

URL LDAP

Există un format pentru o adresă URL care identifică o operațiune LDAP și care este de obicei folosit pentru a efectua căutări sau pentru a permite serverului să returneze „recomandări”, adică referințe la alt server care conține informațiile solicitate de client:

 ldap: // host: port / DN? atribute? scope? filter? extensii

Nu sunt necesare toate părțile adresei URL.

  • ldap: // indică schema URL-ului și identifică protocolul LDAP
  • gazdă este adresa FQDN sau IP a serverului LDAP.
  • port este portul pe care să contactați gazda
  • DN este „numele distins” folosit pentru a identifica baza (punctul de plecare) al căutării.
  • atribute este lista (cu elementele separate prin virgule) a atributelor de recuperat.
  • domeniul de aplicare specifică domeniul de căutare (poate fi „de bază”, „unul” sau „sub”).
  • filtru este filtrul de căutare (așa cum este definit în RFC 4515 ).
  • extensiile sunt extensii la cererea LDAP

Se utilizează în mod obișnuit o schemă de tip "ldaps: //" care, deși este depreciată în RFC 3494 , indică o conexiune LDAP cu SSL. Acest lucru este complet diferit de utilizarea operației StartTLS care utilizează în schimb schema standard ldap:// .

Companii care susțin LDAP

LDAP a câștigat un sprijin extins din partea unor companii precum:

precum și în implementări de software open source / gratuit, cum ar fi OpenLDAP și Fedora Directory Server . Serverul HTTP Apache utilizat ca proxy (din modulul mod_proxy) acceptă și LDAP.

RFC

LDAP este definit de o serie de Cereri de comentarii :

Următoarele RFC detaliază câteva „Cele mai bune practici actuale” specifice LDAP:

  • RFC 4520 (de asemenea, BCP 64) - Considerații privind Autoritatea Numerelor Alocate pe Internet (IANA) pentru Protocolul de acces ușor la director (LDAP) (înlocuiește: RFC 3383 )
  • RFC 4521 (și BCP 118) - Considerații pentru extensiile LDAP (Lightweight Directory Access Protocol)

Următoarele RFC acoperă unele extensii specifice la LDAPv3:

  • RFC 2247 - Utilizarea domeniilor DNS în nume distincte (actualizat de RFC 4519 și RFC 4524 )
  • RFC 2307 - Utilizarea LDAP ca serviciu de informații de rețea
  • RFC 2589 - LDAPv3: Extensii Dynamic Directory Services
  • RFC 2649 - Semnături operaționale LDAPv3
  • RFC 2696 - Control simplu al rezultatelor paginate LDAP
  • RFC 2798 - inetOrgPerson LDAP Object Class (actualizat de la RFC 3698 , RFC 4519 și RFC 4524 )
  • RFC 2830 - LDAPv3: Extensie pentru securitatea stratului de transport
  • RFC 2849 - LDAP Data Interchange Format ( LDIF )
  • RFC 2891 - Sortarea pe partea de server a rezultatelor căutării
  • RFC 3045 - Stocarea informațiilor despre furnizor în rădăcina LDAP DSE
  • RFC 3062 - LDAP Password Modify Extended Operation
  • RFC 3296 - Referințe subordonate numite în directoare LDAP
  • RFC 3671 - Atribute colective în LDAP
  • RFC 3672 - Subintrări în LDAP
  • RFC 3673 - LDAPv3: Toate atributele operaționale
  • RFC 3687 - Regulile de potrivire a componentelor LDAP
  • RFC 3698 - LDAP: Reguli de potrivire suplimentare
  • RFC 3829 - Controale de identitate de autorizare LDAP
  • RFC 3866 - Etichete și intervale de limbă în LDAP
  • RFC 3909 - Anulați operațiunea LDAP
  • RFC 3928 - Protocol de actualizare client LDAP
  • RFC 4370 - Control autorizare proxy LDAP
  • RFC 4373 - LBURP
  • RFC 4403 - Schema LDAP pentru UDDI
  • RFC 4522 - LDAP: Opțiune de codare binară
  • RFC 4523 - LDAP: Schema certificatului X.509
  • RFC 4524 - LDAP: Schema COSINE (înlocuiește: RFC 1274 )
  • RFC 4525 - LDAP: Extensie de modificare-incrementare
  • RFC 4526 - LDAP: filtre adevărate și false absolute
  • RFC 4527 - LDAP: Citiți comenzile de intrare
  • RFC 4528 - LDAP: Controlul afirmării
  • RFC 4529 - LDAP: Solicitarea atributelor după clasa de obiecte
  • RFC 4530 - LDAP: entryUUID
  • RFC 4531 - LDAP Turn Operation
  • RFC 4532 - LDAP Cine sunt eu? Operațiune
  • RFC 4533 - Operațiunea de sincronizare a conținutului LDAP
  • RFC 4876 - Schema profilului de configurare pentru agenții bazați pe LDAP
  • RFC 5020 - LDAP entryDN Attribute operațional

LDAPv2 a fost definit în următoarele RFC-uri:

  • RFC 1777 - Protocol ușor de acces la director (înlocuiește: RFC 1487 )
  • RFC 1778 - Reprezentarea în șiruri a sintaxelor standard de atribute (înlocuiește: RFC 1488 )
  • RFC 1779 - O reprezentare în șir a numelor distinse (înlocuiește: RFC 1485 )

LDAPv2 a fost pus în starea „istoric” cu următoarea RFC

  • RFC 3494 - Lightweight Directory Access Protocol versiunea 2 (LDAPv2) la Stare istorică

Notă

  1. ^ Tim Howes, The Lightweight Directory Access Protocol: X.500 Lite ( PDF ), la openldap.org . Adus la 26 decembrie 2012 .
  2. ^ RFC3494

Bibliografie

Elemente conexe

linkuri externe

Controlul autorității LCCN (EN) sh2001008354 · GND (DE) 4537748-0 · BNF (FR) cb13612263r (data)
Telematică Portal telematic : accesați intrări Wikipedia care vorbesc despre rețele, telecomunicații și protocoale de rețea
Adus de la „ https://it.wikipedia.org/w/index.php?title=Lightweight_Directory_Access_Protocol&oldid=117364639 ”