Lightweight Directory
Access Protocol (LDAP)
est à l'origine un protocole permettant
l'interrogation et la modification des services d'annuaire. 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 X.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 nommage DNS pour les éléments
de base de l'annuaire (racine et premières branches, domain components ou dc=…).
Les branches plus profondes de l'annuaire peuvent représenter des unités
d'organisation ou des groupes (organizational units ou ou=…),
des personnes (common name ou cn=… voire user
identifier uid=…). L'assemblage de tous les composants (du plus
précis au plus général) d'un nom forme son distinguished name,
l'exemple suivant en présente deux :
- cn=ordinateur,ou=machines,dc=EXEMPLE,dc=FR
- cn=Jean,ou=gens,dc=EXEMPLE,dc=FR
dc=FR
|
dc=EXEMPLE
/ \
ou=machines ou=gens
/ \
cn=ordinateur cn=Jean
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 X.500
Directory Access Protocol (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 Directory 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
annuaires X.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 de Performance Systems
International en 1993. Les développements qui
suivirent, furent menés par l’Internet Engineering Task Force(IETF).
Initialement le
protocole avait pour nom Lightweight 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
de X.500 : XML Enabled Directory (XED), Directory
Services Markup Language (DSML), Service Provisioning Markup
Language (SPML), et Service Location Protocol (SLP).
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 Distinguished Name (DN). Il est
constitué à partir de son Relative 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, 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: john@example.com
manager: cn=Barbara Doe,dc=example,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 common name, "dc" pour domain component,
"sn" pour surname.
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.
