Pour les articles homonymes, voirDAP.
Cet articlene cite pas suffisamment ses sources().
Si vous disposez d'ouvrages ou d'articles de référence ou si vous connaissez des sites web de qualité traitant du thème abordé ici, merci de compléter l'article en donnant lesréférences utiles à savérifiabilité et en les liant à la section « Notes et références ».
En pratique :Quelles sources sont attendues ?Comment ajouter mes sources ?LightweightDirectory Access Protocol (LDAP) est à l'origine unprotocole permettant l'interrogation et la modification des services d'annuaire (il est une évolution du protocole DAP). Ce protocole repose surTCP/IP. Il a cependant évolué pour représenter unenorme pour les systèmes d'annuaires, incluant unmodèle de données, un modèle de nommage, un modèle fonctionnel basé sur le protocole LDAP, un modèle de sécurité et un modèle de réplication. C'est une structure arborescente dont chacun des nœuds est constitué d'attributs associés à leurs valeurs. LDAP est moins complexe que le modèleX.500 édicté par l'UIT-T.
Le nommage des éléments constituant l'arbre (racine, branches, feuilles) reflète souvent le modèle politique, géographique ou d'organisation de la structure représentée. La tendance actuelle est d'utiliser le nommageDNS pour les éléments de base de l'annuaire (racine et premières branches,domain components oudc=…). Les branches plus profondes de l'annuaire peuvent représenter des unités d'organisation ou des groupes (organizational units ouou=…), des personnes (common name oucn=… voireuser identifieruid=…). L'assemblage de tous les composants (du plus précis au plus général) d'un nom forme sondistinguished name, l'exemple suivant en présente deux :
dc=FR | dc=EXEMPLE / \ ou=machines ou=personnes / \cn=ordinateur cn=Jean
La dernière version en date du protocole est LDAPv3. Cette version est définie par l'IETF dans plusieursRFC en commençant par laRFC 4510[1].
LDAP a été initialement conçu pour accéder de manière légère aux annuairesX.500. Ces annuaires étaient traditionnellement interrogés à travers le protocoleX.500 Directory Access Protocol (DAP) qui nécessitait l'utilisation de la pile de protocoles dumodèle OSI. L'utilisation d'une passerelle LDAP/DAP permettait d'accéder à un serveur DAP en étant sur un réseau TCP/IP. Ce modèle d'annuaire est dérivé de DIXIE et deDirectory Assistance Service.
L'apparition d'annuaires LDAP natifs (standalone LDAP directory) a suivi rapidement, tout comme celle de serveurs prenant en charge à la fois DAP et LDAP. Les annuaires sont devenus populaires dans les entreprises car il n'était plus nécessaire de déployer un réseau OSI. De nos jours, les protocoles d'accès aux annuairesX.500 (incluant DAP) peuvent être directement utilisés sur TCP/IP.
Le protocole fut créé par Tim Howes de l'Université du Michigan, Steve Kille du ISODE et Wengyik Yeong dePerformance Systems International en1993. Les développements qui suivirent, furent menés par l’Internet Engineering Task Force (IETF).
Initialement le protocole avait pour nomLightweight Directory Browsing Protocol (LDBP), car il ne permettait que la recherche de données. Il fut renommé lors de l'ajout de nouvelles possibilités (ajout, modification).
LDAP a influencé un certain nombre de protocoles d'Internet, incluant les dernières versions deX.500 :XML Enabled Directory (XED), Directory Services Markup Language (DSML),Service Provisioning Markup Language (SPML), etService Location Protocol (SLP).
Un client commence une session LDAP en se connectant sur le port TCP 389 du serveur. Le client envoie ensuite des requêtes d'opération au serveur. Le serveur envoie des réponses en retour. À part quelques exceptions, le client n'a pas besoin d'attendre de réponse du serveur pour envoyer de nouvelles requêtes, et le serveur peut envoyer ses réponses dans n'importe quel ordre.
Une fois la connexion au serveur établie, les opérations classiques sont :
De plus, le serveur peut envoyer des notifications non sollicitéesUnsolicited Notifications qui ne sont pas des réponses à des requêtes, par exemple avant de clore une connexion inactive.
Une méthode pour sécuriser les communications LDAP est d'utiliser un tunnelTLS/SSL. Lors de l'emploi d'URL cet usage est traduit par le nom du protocoleldaps en remplacement deldap. Le port TCP standard pourldaps est 636.
Le protocole LDAP employant la notationASN.1 et les messages sont codés avec le format binaireBER. Cependant il utilise une représentation textuelle pour un certain nombre d'attributs et de types d'ASN.1.
Les annuaires LDAP suivent le modèle X.500 et son architecture nativementmulti-tenant :
Le fait que les attributs puissent être multi-valués est une différence majeure entre les annuaires LDAP et lesSGBDR. De plus, si un attributn'a pas de valeur, il est purement et simplementabsent de l'entrée.
Chaque entrée a un identifiant unique, leDistinguished Name (DN). Il est constitué à partir de sonRelative Distinguished Name (RDN) suivi du DN de son parent. C'est une définition récursive. On peut faire l'analogie avec une autre structure arborescente, lessystèmes de fichiers ; le DN étant le chemin absolu et le RDN le chemin relatif à un répertoire. En règle générale le RDN d'une entrée représentant une personne est l'attributuid :
dc=org | dc=example / \ ou=people ou=groups | uid=toto
Le RDN de toto estrdn:uid=toto, son DN estdn:uid=toto,ou=people,dc=example,dc=org.
Une entrée peut ressembler à la représentation suivante lorsqu'elle est formatée enLDIF :
dn: cn=John Doe, dc=example, dc=org cn: John Doe givenName: John sn: Doe telephoneNumber: +1 555 6789 telephoneNumber: +1 555 1234 mail: john@example.com manager: cn=Barbara Doe, dc=exemple, dc=com objectClass: inetOrgPerson objectClass: organizationalPerson objectClass: person objectClass: top
dn est le nom de l'entrée, ce n'est pas un attribut de l'entrée. "cn=John Doe" est le RDN de l'entrée et "dc=example,dc=org" est le DN de son parent. Les autres lignes montrent les attributs de l'entrée. Les noms des attributs sont parfois des abréviations pour les plus courants : "cn" pourcommon name, "dc" pourdomain component, "sn" poursurname.
Un serveur contient un sous-arbre dont la racine est une entrée spécifique et tous ses enfants, par exemple : "dc=example,dc=org". Les serveurs peuvent également contenir des références vers d'autres serveurs, ainsi l'accès à une entrée ("ou=un service,dc=example,dc=org") peut retourner une référence (referral) à un autre serveur qui contient le sous-arbre voulu. Le client peut alors contacter (automatiquement ou pas) l'autre serveur. Certains serveurs prennent en charge le chaînage (chaining) qui permet au serveur d'interroger d'autres serveurs pour renvoyer l'information voulue au client.
Les résultats renvoyés par le serveur ne sont pas triés, que ce soit pour les entrées, pour les attributs des entrées ou pour les valeurs des attributs.
Le client donne à chaque requête un identifiantMessage ID, le serveur répond à la requête avec le même identifiant. La réponse inclut un code de résultat numérique indiquant l'état de la requête (succès, échec, …). La réponse inclut également les données éventuelles qui peuvent résulter d'une recherche. Il inclut aussi un code ID.
L'opérationbind authentifie le client au sein du serveur. Lesimplebind envoie le DN de l'utilisateur et son mot de passe en clair, c'est pourquoi la connexion doit être sécurisée parTLS. Le serveur vérifie le mot de passe en le comparant avec l'attribut userPassword (en général) de l'entrée correspondante. La valeur de l'attribut contenant le mot de passe commence avec le nom entre accolades de l'algorithme utilisé pour chiffrer le mot de passe (par exemple : userPassword: {md5}aGZh5…).
Lebind anonyme, c'est-à-dire sans fournir d'identifiant ni de mot de passe, met la connexion dans un état anonyme. Dès lors le client ne pourra plus effectuer certaines opérations sur tout ou une partie de l'annuaire, en fonction desACL mises en place.
LeSASLbind permet d'utiliser d'autres mécanismes d'authentification :Kerberos, certificat client, etc.
L'étape debind permet également au client et au serveur de se mettre d'accord sur la version du protocole à utiliser. En général la version 3 est utilisée. Il est même possible au serveur de refuser de communiquer avec des clients dans un protocole inférieur au sien.
L'opérationStartTLS établit une connexion sécurisée entre le client et le serveur en utilisant la techniqueTLS, héritière deSSL. Cette sécurisation opère sur deux points : la confidentialité (un tiers ne peut pas comprendre l'échange) et l'intégrité des données (les données sont validées par une signature). Pendant la négociation TLS, le serveur envoie son certificatX.509 au client pour prouver son identité. Le client peut répondre en envoyant son certificat mais l'identification du client est facultative. Il est généralement possible de configurer clients et serveurs pour savoir si les certificats sont facultatifs ou essentiels.
Les serveurs prennent en charge généralement le protocole non standard « LDAPS » (LDAP over SSL). Ce protocole utilise le port 636 contrairement au TLS qui utilise le port 389 (le même que le LDAP non sécurisé). Le protocole LDAPS diffère du LDAP sur deux points :
L'opérationSearch est utilisée à la fois pour faire une recherche et rapatrier des entrées. Ses paramètres sont :
Le serveur renvoie les entrées qui correspondent, suivies par le code retour de la commande (code de retour).
L'opérationCompare prend en argument un DN, un nom d'attribut et une valeur d'attribut, puis vérifie si l'entrée correspondante contient bien un attribut ayant cette valeur.
Remarque : Il n'existe pas d'opération du typeRead. C'est l'opérationSearch qui est utilisée pour l'accès direct à une entrée. Dans ce cas, le paramètrebaseObject est le DN de l'entrée que l'on veut lire, et le paramètrescope est utilisé avec la valeurbase.
Les opérations de mise à jourAdd (ajout),Delete (suppression),Modify (modification) prennent en argument le DN de l'entrée à mettre à jour.
La modification a besoin en plus de la liste des attributs à modifier ainsi que la modification à apporter : suppression de l'attribut ou de certaines valeurs de l'attribut (les attributs peuvent être multi-valués), ajout d'une valeur, remplacement d'une valeur.
L'ajout d'une entrée peut également contenir une liste d'attributs et de valeurs à associer avec l'entrée.
La modification de DN (déplacement/renommage) prend en argument le RDN de l'entrée et, de façon facultative, le DN du nouveau parent, ainsi qu'un marqueur qui indique s'il faut ou non effacer l'ancien RDN. La prise en charge du renommage d'un sous-arbre en entier dépend des serveurs.
Une opération de mise à jour est atomique, c'est-à-dire que les autres opérations verront soit la nouvelle entrée soit l'ancienne. Toutefois, le protocole LDAP ne définit pas de principe de transaction, ce qui permet à plusieurs clients de modifier une entrée en même temps. Cependant, les serveurs peuvent utiliser des extensions pour le supporter.
Les opérations étendues sont des opérations génériques qui permettent de définir de nouvelles opérations. Par exemple les opérationsCancel,Password Modify etStartTLS.
L'opérationAbandon envoie une requête au serveur pour lui dire d'abandonner une opération en lui fournissant son identifiant. Le serveur n'a pas obligation d'honorer la requête. Malheureusement, l'opérationAbandon ainsi que l'abandon effectif d'une opération ne renvoient pas de réponse. C'est pourquoi l'opération étendueCancel a été définie pour renvoyer une réponse, mais tous les serveurs ne la prennent pas en charge.
L'opérationUnbind abandonne toute opération en cours et ferme la connexion. Il n'y a aucune réponse. Son nom a des raisons historiques, ce n'est pas l'opération contraire àBind.
Les clients peuvent terminer une session en fermant la connexion, mais il est pluspropre d'utiliserUnbind. Le serveur peut ainsi différencier les erreurs réseau des clients discourtois.
Il existe un format d'URI LDAP, mais tous les clients ne le prennent pas en charge. Les serveurs l'utilisent pour indiquer aux clients les références vers d'autres serveurs. Le format est le suivant :
ldap://hôte:port/DN?attributs?profondeur?filtre?extension
avec :
Comme dans tous les URI, les caractères spéciaux doivent être échappés en suivant l'algorithme prévu par laRFC 3986.
On peut aussi rencontrer des URI utilisant le schéma non normalisé « ldaps ».
Par exemple :
ldap://ldap.example.com/cn=John%20Doe,dc=example,dc=com
retourne tous les attributs de l'entrée « John Doe »,
ldap:///dc=example,dc=com??sub?(givenName=John)
recherche l'entrée ayant comme prénom « John » dans l'annuaire à partir de la racine.
Le contenu des entrées d'un annuaire LDAP est régi par desschémas.
Les schémas définissent les types d'attribut que les entrées d'un annuaire peuvent contenir. La définition d'un attribut inclut une syntaxe, la plupart des attributs non binaires dans LDAPv3 utilisent la syntaxe des chaînes de caractèresUTF-8. Par exemple, l'attributmail peut contenir "utilisateur@example.org", l'attributjpegPhoto peut contenir une photographie au format binaireJPEG, l'attributmember peut contenir le DN d'une entrée de l'annuaire.
La définition d'un attribut indique également si l'attribut est mono-valué ou multi-valué, selon quelles règles se feront les recherches/comparaisons (sensible à la casse ou pas, recherche de sous-chaîne ou pas).
Les schémas définissent des classes d'objets. Chaque entrée de l'annuaire doit avoir au moins une valeur pour l'attributobjectClass, qui soit une classe d'objets définie dans les schémas. Généralement, l'attributobjectClass est multi-valué et contient la classetop ainsi qu'un certain nombre d'autres classes.
Tout comme dans laprogrammation orientée objet, les classes permettent de décrire un objet en lui associant des attributs. Les classes LDAP représentent des personnes, des organisations... Le fait qu'une entrée appartienne à une classe (donc que l'attribut objectClass contienne le nom de la classe) lui permet d'utiliser les attributs de cette classe. Certains attributs sont obligatoires et d'autres facultatifs. Par exemple, si l'entrée utilise la classeperson, elle doit avoir obligatoirement une valeur pour les attributssn etcn, et peut avoir facultativement une valeur pour les attributsuserPassword ettelephoneNumber. Les entrées ayant généralement plusieurs classes, la différenciation entre attributs obligatoires et facultatifs peut être assez complexe.
Les éléments d'un schéma ont un nom et un identifiant unique nommé Object identifier (OID).
Beaucoup de serveurs exposent les schémas de l'annuaire comme des entrées LDAP accessibles à partir du DN cn=schema. Il est possible pour les administrateurs de définir leur propre schéma en plus des schémas standard.
Certaines opérations possibles sont laissées à l'appréciation du développeur ou de l'administrateur. Par exemple, le stockage des données n'est pas spécifié par le protocole. Le serveur peut utiliser des fichiers à plat, ou un SGBDR, ou bien être simplement une passerelle vers un autre serveur. Les contrôles d'accès (ACL) ne sont pas non plus normalisés, bien qu'un usage commun émerge.
LDAP est un protocole extensible, ce qui provoque l'apparition de nouvelles opérations sur certains serveurs et pas sur d'autres. Par exemple, le tri des résultats.
L'intérêt principal de LDAP est la normalisation de l'authentification. Il est très facile de programmer un module d'authentification utilisant LDAP à partir d'unlangage possédant uneAPI LDAP. C'est l'opérationBind qui permet d'authentifier un utilisateur. De plus en plus d'applications Web possèdent un module d'authentification prenant en charge LDAP.
Sur les systèmesGNU/Linux récents, on voit de plus en plus l'adoption d'une base de données utilisant LDAP à la place des fichiers à platpasswd etshadow. Les données peuvent être accédées par les modulesPAM etNSS.[citation nécessaire]
LDAP est défini par une série deRequest for comments :
Les RFC suivantes détaillent les bonnes pratiques à adopter concernant LDAP :
Ce qui suit est une liste contenant les RFC définissant des extensions LDAPv3 :
LDAPv2 a été défini par les RFC suivantes :
LDAPv2 a été déplacé dansHistoric Status par la RFC suivante :
Autres RFC :
| Officiel | |
|---|---|
| Non-officiel | |
