Lightweight Directory Access Protocol (LDAP) er opprinnelig enprotokollfor spørring og endring avkatalogtjenester(det er en utvikling av DAP-protokollen). Denne protokollen er basert påTCP / IP. Imidlertid har det utviklet seg til å representere enstandardfor katalogsystemer, inkludert endatamodell, en navne modell, en LDAP-basert funksjonell modell, en sikkerhetsmodell, og et replikasjonsmodell. Det er en trestruktur der hver av nodene består av attributter knyttet til deres verdier. LDAP er mindre komplisert enn X.500- modellen som er bestemt avITU-T.
Navngivningen av elementene som utgjør treet (rot, grener, blader) gjenspeiler ofte den politiske, geografiske eller organisatoriske modellen til den representerte strukturen. Den nåværende trenden er å bruke DNS- navngiving for de grunnleggende elementene i katalogen (rot- og første grener, domenekomponenter eller dc =… ). De dypere grenene av katalogen kan representere organisasjonsenheter eller grupper ( organisasjonsenheter eller ou = ... ), personer ( vanlig navn eller cn = ... eller til og med brukeridentifikator uid = ... ). Samlingen av alle komponentene (fra den mest presise til den mest generelle) av et navn danner sitt fremtredende navn , følgende eksempel presenterer to:
Den siste versjonen av protokollen er LDAPv3. Denne versjonen er definert av IETF i flere RFCer som starter med RFC 4510.
LDAP ble opprinnelig designet for lett tilgang til X.500 kataloger. Disse katalogene ble tradisjonelt spurt med X.500 Directory Access Protocol (DAP) som krevde bruk av OSI-modellprotokollstakken . Ved å bruke en LDAP / DAP-gateway fikk du tilgang til en DAP-server mens du er i et TCP / IP-nettverk. Denne katalogmodellen er hentet fra DIXIE og Directory Assistance Service .
Fremveksten av innfødte LDAP-kataloger fulgte raskt, og det samme gjorde fremveksten av servere som støtter både DAP og LDAP. Kataloger ble populære i bedrifter fordi det ikke lenger var behov for å distribuere et OSI-nettverk. I dag kan X.500 katalogadgangsprotokoller (inkludert DAP) brukes direkte over TCP / IP.
Protokollen ble opprettet av Tim Howes fra University of Michigan , Steve Kille fra ISODE, og Wengyik Yeong fra Performance Systems International i 1993 . Utviklingen som fulgte ble ledet av Internet Engineering Task Force (IETF).
Opprinnelig ble protokollen kalt Lightweight Directory Browsing Protocol ( LDBP ), fordi den bare tillot søk etter data. Det ble omdøpt når du la til nye muligheter (tillegg, modifikasjon).
LDAP har påvirket en rekke internettprotokoller, inkludert de nyeste versjonene av X.500 : XML Enabled Directory (XED), Directory Services Markup Language (DSML), Service Provisioning Markup Language (SPML) og Service Location Protocol (SLP)).
En klient starter en LDAP-økt ved å koble til serverens TCP-port 389. Klienten sender deretter operasjonsforespørsler til serveren. Serveren sender svar tilbake. Med noen få unntak trenger ikke klienten å vente på svar fra serveren for å sende nye forespørsler, og serveren kan sende svarene i hvilken som helst rekkefølge.
Når forbindelsen til serveren er opprettet, er de typiske operasjonene:
I tillegg kan serveren sende uønskede uønskede varsler som ikke er svar på forespørsler, for eksempel før en inaktiv forbindelse lukkes.
En metode for å sikre LDAP-kommunikasjon er å bruke en TLS / SSL- tunnel . Når du bruker URL-er, blir denne bruken oversatt med navnet på ldaps- protokollen for å erstatte ldap . Standard TCP-port for ldaps er 636.
LDAP-protokollen benytter ASN.1- notasjonen, og meldingene er kodet med binært BER- format . Imidlertid bruker den tekstrepresentasjon for en rekke attributter og typer ASN.1.
LDAP-kataloger følger X.500-modellen og dens opprinnelige arkitektur for flere leietakere :
Det faktum at attributter kan verdsettes flere, er en stor forskjell mellom LDAP-kataloger og RDBMS . I tillegg, hvis et attributt ikke har noen verdi, mangler det ganske enkelt i oppføringen.
Hver oppføring har en unik identifikator, Distinguished Name (DN). Den består av sitt relative relative navn (RDN) etterfulgt av DN for foreldrene. Det er en rekursiv definisjon. Vi kan gjøre analogien med en annen trestruktur, filsystemer; DN er den absolutte banen og RDN banen i forhold til en katalog. Vanligvis er RDN for en oppføring som representerer en person uid- attributtet :
dc=org | dc=example / \ ou=people ou=groups | uid=totoRDN for foo er rdn: uid = foo , hans DN er dn: uid = foo, ou = folk, dc = eksempel, dc = org .
En oppføring kan se ut som følgende representasjon når den er formatert som 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 er navnet på oppføringen, det er ikke et attributt for oppføringen. "cn = John Doe" er RDN for oppføringen, og "dc = eksempel, dc = org" er DN for foreldrene. De andre linjene viser attributtene til oppføringen. Navnene på attributtene er noen ganger forkortelser for de vanligste: "cn" for vanlig navn , "dc" for domenekomponent , "sn" for etternavn .
En server inneholder et undertre hvis rot er en bestemt oppføring og alle barna, for eksempel: "dc = eksempel, dc = org". Servere kan også inneholde referanser til andre servere, så tilgang til en oppføring ("ou = en tjeneste, dc = eksempel, dc = org") kan returnere en henvisning til en annen server som inneholder det ønskede undertreet. Klienten kan da kontakte (automatisk eller ikke) den andre serveren. Noen servere støtter kjetting, som gjør at serveren kan spørre andre servere for å sende ønsket informasjon tilbake til klienten.
Resultatene som serveren returnerer, blir ikke sortert, enten for oppføringene, for attributtene til oppføringene eller for verdiene til attributtene.
Klienten gir hver forespørsel en meldings-ID , serveren svarer på forespørselen med samme identifikator. Svaret inkluderer en numerisk resultatkode som indikerer forespørselens status (suksess, fiasko, ...). Svaret inkluderer også data som kan oppstå fra et søk. Den inneholder også en ID-kode.
Den bind operasjon godkjenner klienten selve serveren. Den enkle bindingen sender brukerens DN og passord i tydelig, og derfor må forbindelsen være sikret av TLS . Serveren verifiserer passordet ved å sammenligne det med brukerpassordattributtet (vanligvis) for den tilsvarende oppføringen. Verdien av attributtet som inneholder passordet begynner med navnet i parentes av algoritmen som brukes til å kode passordet (for eksempel: userPassword: {md5} aGZh5…).
Den anonyme bindingen , det vil si uten å oppgi et brukernavn eller passord, setter forbindelsen i en anonym tilstand. Kunden vil derfor ikke lenger kunne utføre visse operasjoner på hele eller deler av katalogen, avhengig av ACL-er som er på plass.
Den SASL- bind tillater bruk av andre autentiseringsmekanismer: Kerberos , klientsertifikat, etc.
Den bind trinnet gjør det også mulig klienten og serveren for å bli enige om hvilken versjon av protokollen til bruk. Vanligvis brukes versjon 3. Det er til og med mulig for serveren å nekte å kommunisere med klienter i en lavere protokoll enn sin egen.
StartTLS- operasjonen oppretter en sikker forbindelse mellom klienten og serveren ved hjelp av TLS- teknikken , arvet fra SSL . Denne sikkerheten fungerer på to punkter: konfidensialitet (en tredjepart kan ikke forstå utvekslingen) og dataintegritet (dataene valideres av en signatur). Under TLS-forhandlinger sender serveren sitt X.509- sertifikat til klienten for å bevise identiteten. Klienten kan svare ved å sende sertifikatet, men klientidentifikasjon er valgfritt. Det er vanligvis mulig å konfigurere klienter og servere for å vite om sertifikater er valgfrie eller essensielle.
Servere støtter vanligvis ikke-standard “LDAPS” ( LDAP over SSL ) protokoll . Denne protokollen bruker port 636 i motsetning til TLS som bruker port 389 (det samme som usikret LDAP). LDAPS-protokollen skiller seg fra LDAP på to måter:
Den Søk drift brukes både til å søke og hente oppføringer. Parametrene er:
Serveren returnerer oppføringene som samsvarer, etterfulgt av kommandoens returkode (returkode).
Den sammenligning operasjon tar DN, et attributt navn og en attributtverdi som argument, så sjekker om den tilsvarende oppføringen inneholder faktisk et attributt med denne verdien.
Merk : Det er ingen operasjoner av typen Les . Den Søk drift brukes for direkte tilgang til en oppføring. I dette tilfellet er baseObject parameteren er DN for adgang til å bli lest, og at omfanget parameter brukes med basisverdien .
Den Add , Slett , Endre oppdateringsoperasjoner tar som argument DN for oppføringen som skal oppdateres.
Modifiseringen trenger i tillegg til listen over attributter som skal modifiseres, samt modifikasjonen som skal gjøres: sletting av attributtet eller av visse verdier av attributtet (attributtene kan være flere verdsatt), tillegg av en verdi, erstatning en verdi av.
Tillegget til en oppføring kan også inneholde en liste over attributter og verdier som skal knyttes til oppføringen.
Endringen av DN (flytt / endre navn) tar som argument RDN for oppføringen og eventuelt DN for den nye overordnede, samt en markør som indikerer om den gamle RDN skal slettes eller ikke. Støtte for å gi nytt navn til et helt undertre er serveravhengig.
En oppdateringsoperasjon er atomisk, det vil si at andre operasjoner vil se enten den nye oppføringen eller den gamle. LDAP definerer imidlertid ikke et transaksjonsprinsipp som gjør at flere klienter kan endre en oppføring samtidig. Imidlertid kan servere bruke utvidelser for å støtte det.
Utvidede operasjoner er generiske operasjoner som lar deg definere nye operasjoner. For eksempel operasjonene Avbryt , Passordendring og StartTLS .
ForlatelseAbandon- operasjonen sender en forespørsel til serveren om å be den om å avbryte en operasjon ved å gi den identifikatoren. Serveren er ikke forpliktet til å imøtekomme forespørselen. Dessverre gir ikke oppgaveaksjonen så vel som den faktiske oppgivelsen av en operasjon svar. Derfor er den utvidede Avbryt- operasjonen definert for å returnere et svar, men ikke alle servere støtter det.
Unbind- operasjonen avbryter enhver gjeldende operasjon og lukker forbindelsen. Det er ikke noe svar. Navnet har historiske grunner, det er ikke operasjonen i strid med Bind .
Klienter kan avslutte en økt ved å lukke forbindelsen, men det er renere å bruke Unbind . Dette gjør at serveren kan skille nettverksfeil fra ubehagelige klienter.
Det er et LDAP URI- format , men ikke alle klienter støtter det. Servere bruker den til å fortelle klienter om henvisninger til andre servere. Formatet er som følger:
ldap://hôte:port/DN?attributs?profondeur?filtre?extensionmed:
Som i alle URI-er, må spesialtegn unngås ved å følge algoritmen gitt av RFC 3986 .
Du kan også støte på URI ved å bruke det ikke-standard mønsteret " ldaps ".
For eksempel :
ldap://ldap.example.com/cn=John%20Doe,dc=example,dc=comreturnerer alle attributtene til "John Doe" -oppføringen,
ldap:///dc=example,dc=com??sub?(givenName=John)søker etter oppføringen med fornavnet "John" i katalogen fra roten.
Innholdet i oppføringene i en LDAP-katalog styres av skjemaer .
Skjemaer definerer typene attributter som katalogoppføringer kan inneholde. Definisjonen av et attributt inkluderer syntaks. De fleste ikke-binære attributter i LDAPv3 bruker UTF-8 streng-syntaks . For eksempel post -attributtet kan inneholde " [email protected] ", den jpegPhoto attributt kan inneholde fotografi i binært JPEG -format , er medlem attributt kan inneholde DN for en katalogoppføring.
Definisjonen av et attributt indikerer også om attributtet er monovurdert eller multivurdert, i henhold til hvilke regler som vil bli gjort til søk / sammenligninger (følsomme for saken eller ikke, søk etter underlag eller ikke).
Skjemaer definerer klasser av objekter. Hver katalogoppføring må ha minst én verdi for objektClass- attributtet , som er en objektklasse definert i skjemaene. Vanligvis object attributt er multi-verdsatt og inneholder toppklassen , samt en rekke andre klasser.
Akkurat som i objektorientert programmering , lar klasser deg beskrive et objekt ved å knytte attributter til det. LDAP-klasser representerer mennesker, organisasjoner ... Det faktum at en oppføring tilhører en klasse (derfor at objektClass-attributtet inneholder navnet på klassen) lar den bruke attributtene til denne klassen. Noen attributter er obligatoriske, og noen er valgfrie. For eksempel, hvis oppføringen benytter den person klasse , må den ha en verdi for den sn og cn attributter , og kan eventuelt ha en verdi for den user og telephone attributter . Siden oppføringer vanligvis har flere klasser, kan det være ganske komplisert å skille mellom nødvendige og valgfrie attributter.
Elementene i et skjema har et navn og en unik identifikator kalt Object identifier ( OID ).
Mange servere avslører katalogskjemaer som LDAP-oppføringer som er tilgjengelige fra DN cn = -skjemaet. Det er mulig for administratorer å definere sitt eget skjema i tillegg til standardskjemaene.
Noen mulige operasjoner overlates til utvikleren eller administratoren. Datalagring er for eksempel ikke spesifisert av protokollen. Serveren kan bruke flate filer eller en RDBMS, eller den kan rett og slett være en gateway til en annen server. Tilgangskontroll ( ACL ) er heller ikke standardisert, selv om vanlig bruk dukker opp.
LDAP er en utvidbar protokoll som får nye operasjoner til å vises på noen servere og ikke på andre. For eksempel sortering av resultatene.
Hovedinteressen til LDAP er standardisering av autentisering. Det er veldig enkelt å programmere en godkjenningsmodul ved bruk av LDAP fra et språk som har en LDAP API . Det er Bind- operasjonen som lar brukeren bli autentisert. Flere og flere webapplikasjoner har en autentiseringsmodul som støtter LDAP.
På nylige GNU / Linux- systemer er det en økende adopsjon av en database som bruker LDAP i stedet for passwd og skyggeflate filer . Dataene er tilgjengelige via PAM- og NSS- modulene .
LDAP er definert av en serie med forespørsel om kommentarer :
Følgende RFC-er beskriver de beste metodene for LDAP:
Følgende er en liste som inneholder RFCer som definerer LDAPv3-utvidelser:
LDAPv2 er definert av følgende RFCer:
LDAPv2 er flyttet til historisk status av følgende RFC:
Andre RFCer: