(LDAP) est à l'origine un protocole permettant l'interrogation et la modification des services d'annuaire (il est une évolution du protocole DAP). Ce protocole repose sur TCP/IP. Il a cependant évolué pour représenter une norme pour les systèmes d'annuaires, incluant un modè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èle é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 nommage DNS pour les éléments de base de l'annuaire (racine et premières branches, ou dc=…). Les branches plus profondes de l'annuaire peuvent représenter des unités d'organisation ou des groupes ( ou ou=…), des personnes ( ou cn=… voire uid=…). L'assemblage de tous les composants (du plus précis au plus général) d'un nom forme son , l'exemple suivant en présente deux : cn=ordinateur, ou=machines, dc=EXEMPLE, dc=FR cn=Jean, ou=personnes, dc=EXEMPLE, dc=FR

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 plusieurs RFC en commençant par la .

Origine et influences

LDAP a été initialement conçu pour accéder de manière légère aux annuaires X.500. Ces annuaires étaient traditionnellement interrogés à travers le protocole (DAP) qui nécessitait l'utilisation de la pile de protocoles du modè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 de .

L'apparition d'annuaires LDAP natifs () 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 annuaires (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 de en 1993. Les développements qui suivirent, furent menés par l’ (IETF).

Initialement le protocole avait pour nom (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 de : (DSML), (SPML), et (SLP).

Vue d'ensemble 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 :

: utilisation de la couche Transport Layer Security (TLS) pour sécuriser la connexion ; : indique la version du protocole utilisée, et authentifie l'utilisateur. Il est possible de faire un anonyme en ne fournissant ni nom d'utilisateur ni mot de passe ; : recherche dans l'annuaire et rapatriement des données ; : test qui détermine si une entrée contient un attribut avec une valeur donnée ; : ajout d'une nouvelle entrée ; : suppression d'une entrée ; : modification d'une entrée ; : déplacement ou renommage d'une entrée ; : annulation d'une requête précédente ; : opération qui permet de définir d'autres opérations ; : clôt la connexion.

De plus, le serveur peut envoyer des notifications non sollicitées 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 tunnel TLS/SSL. Lors de l'emploi d'URL cet usage est traduit par le nom du protocole ldaps en remplacement de ldap. Le port TCP standard pour ldaps est 636.

Le protocole LDAP employant la notation ASN.1 et les messages sont codés avec le format binaire BER. Cependant il utilise une représentation textuelle pour un certain nombre d'attributs et de types d'ASN.1.

Structure de l'annuaire Les annuaires LDAP suivent le modèle X.500 et son architecture nativement multi-tenant :

Un annuaire est un arbre d'entrées. Une entrée est constituée d'un ensemble d'attributs. Un attribut possède un nom, un type et une ou plusieurs valeurs. Les attributs sont définis dans des schémas.

Le fait que les attributs puissent être multi-valués est une différence majeure entre les annuaires LDAP et les SGBDR. De plus, si un attribut n'a pas de valeur, il est purement et simplement absent de l'entrée.

Chaque entrée a un identifiant unique, le (DN). Il est constitué à partir de son (RDN) suivi du DN de son parent. C'est une définition récursive. On peut faire l'analogie avec une autre structure arborescente, les systè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'attribut uid :

dc=org

dc=example / \ ou=people ou=groups

uid=toto

Le RDN de toto est rdn:uid=toto, son DN est dn:uid=toto,ou=people,dc=example,dc=org.

Une entrée peut ressembler à la représentation suivante lorsqu'elle est formatée en 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: 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" pour , "dc" pour , "sn" pour .

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 () à 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 () 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.

Opérations Le client donne à chaque requête un identifiant , 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.

(authentification) L'opération authentifie le client au sein du serveur. Le simple envoie le DN de l'utilisateur et son mot de passe en clair, c'est pourquoi la connexion doit être sécurisée par TLS. 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…).

Le 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 des ACL mises en place.

Le SASL permet d'utiliser d'autres mécanismes d'authentification : Kerberos, certificat client, etc.

L'étape de 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ération établit une connexion sécurisée entre le client et le serveur en utilisant la technique TLS, héritière de SSL. 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 certificat X.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 » (). 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 : à la connexion, le client et le serveur établissent une connexion TLS avant que n'importe quelle autre commande LDAP ne soit envoyée (sans envoyer d'opération ), la connexion LDAPS doit être fermée lors de la clôture de TLS (alors qu'avec , il est possible de passer d'une connexion sécurisée à une connexion non sécurisée, et inversement).

et L'opération est utilisée à la fois pour faire une recherche et rapatrier des entrées. Ses paramètres sont :

baseObject : le DN () de l'entrée à partir de laquelle effectuer la recherche ; : pour l'entrée baseObject elle-même, pour effectuer une recherche au niveau des entrées immédiatement rattachées au baseObject, pour une recherche dans le sous-arbre de l'entrée ; : les critères qui déterminent si une entrée fait partie des résultats ou non, par exemple (&(objectClass=person)(|(givenName=John)(mail=john*))) - recherche les personnes qui ont pour prénom John ou dont le courriel commence par john ; derefAliases : indique si la recherche doit suivre les alias dans les entrées (entrée qui font référence à d'autres entrées) ; : liste des attributs à ramener à l'issue de la recherche ; : limitation du nombre d'entrées ramenées à l'issue de la recherche ; : limitation du délai de recherche, exprimé en secondes ; : ne renvoie que les types d'attribut et non les valeurs.

Le serveur renvoie les entrées qui correspondent, suivies par le code retour de la commande (code de retour).

L'opération 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 type . C'est l'opération qui est utilisée pour l'accès direct à une entrée. Dans ce cas, le paramètre baseObject est le DN de l'entrée que l'on veut lire, et le paramètre est utilisé avec la valeur .

Mise à jour Les opérations de mise à jour (ajout), (suppression), (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.