Lightweight Directory Access Protocol (LDAP)

Modèles de données

Concept de stockage hiérarchique

Un annuaire stocke ses informations (appelées entrées) de façon hiérarchique, de sorte qu'elles soient ordonnées selon la méthode la plus semblable à l'organisation du Système d'Information. Par exemple, l'organisation de l'annuaire du MIT est le suivant :

MIT LDAP Hierarchy

Ainsi, dans ce modèle, les entrées concernant les étudiants (students) seront stockées dans l'Unité Organisationnelle (OU) nommée "students", qui elle même est stockée dans l'annuaire identifié par son nom "dc=mit,dc=edu". Il en est de même pour les salariés (unité organisationnelle "employees") et pour les partenaires (unité organisationnelle "affiliates").

On remarque également que, certainement pour des besoins applicatifs, les noms des tablespaces Oracle sont également stockés dans l'annuaire, comme enfant du noeud ayant pour identifiant "cn=OracleContext".

Cette structuration de l'information en hiérarchie, par opposition à une organisation linéaire de l'information, permet de regrouper les entrées de l'annuaire en fonction de leur rôle ou de leur intérêt vis à vis du SI. Par exemple, elle permet de limiter l'accès aux machines des enseignants aux membres des groupes "employees" et "affiliates".

De plus, cette hiérarchie fonctionne de pair avec le principe de Distinguished Names décrit ci-après.

Orientation Objet

Le modèle d'information de LDAP utilise une approche orientée objet pour la définition des classes auxquelles peuvent appartenir des entrées. De plus, ce modèle objet autorise l'héritage multiple, et solutionne les problèmes qui peuvent découler de cette approche comme suit :

Une illustration de ce procédé d'héritage multiple est présentée ci-dessous, en UML :

Multiple inheritance in LDAP

Une entrée LDAP peut être une instance de plusieurs classes, et une classe peut elle même hériter de plusieurs classes. Cependant, certaines restrictions s'appliquent à ce principe d'héritage.

En effet, LDAP définit, tout comme la norme X.501, trois familles de classes, avec chacune un objectif différent :

Nom (en) Nom (fr) Description
Abstract Abstraite Une classe abstraite, comme en programmation orientée objet, est une classe dont une autre classe peut hériter, mais qu'il n'est pas possible d'instancier (une entrée ne peut pas hériter une classe abstraite, sauf si elle hérite d'une classe structurelle ou auxiliaire qui hérite de la classe abstraite concernée).

Il existe une classe abstraite de base, baptisée "top" qui est la mère de toutes les classes abstraites et dont toutes les classes structurelles héritent directement ou indirectement. Les classes auxiliaires ne sont pas obligées d'hériter de top.

Une classe abstraite ne peut hériter que d'une autre classe abstraite.
Structural Structurelle Une classe structurelle est utilisée pour caractériser ce qu'une entrée "est". Chaque entrée LDAP ne peut donc hériter directement que d'une et une seule classe structurelle.

Une classe structurelle peut hériter d'une (ou plusieurs) autres classes structurelles, ou classes abstraites. Elle ne peut pas hériter d'une classe auxiliaire.

Au minimum, toute classe structurelle doit hériter, directement ou indirectement, de "top".
Auxiliary Auxiliaire Les classes auxiliaires sont utilisées pour augmenter les attributs obligatoires et/ou les attributs potentiels qu'une entrée doit/peut contenir. Une entrée LDAP peut donc être associée à zéro, une ou plusieurs classes auxiliaires. De plus, la liste des classes auxiliaires desquelles une entrée hérite peut varier au cours du temps.

Une classe auxiliaire ne peut pas hériter d'une classe structurelle.

Par exemple, en fonction du schéma dans lequel votre annuaire est constitué, une entrée décrivant une personne peut hériter des classes suivantes :

# Classe abstraite, racine de la hiérarchie
objectClass: top
# Classe structurelle, héritant de top
objectClass: person
# Classe structurelle, héritant de person
objectClass: organizationalPerson
# Classe structurelle, héritant de organizationalPerson
objectClass: inetOrgPerson

# Classe auxiliaire, héritant de top
objectClass: uidObject
				

La classe caractérisant cette entrée est donc inetOrgPerson, car c'est elle qui se trouve au plus bas de la hiérarchie des classes structurelles appliquées à l'objet. La classe auxiliaire uidObject permet, quand à elle, de forcer l'existence (m-must) de l'attribut uid de l'entrée.

Cette approche orientée objet du modèle de données permet à LDAP de proposer une architecture modulable, ouvert évolutions de l'annuaire au cours du temps.

Distinguished Names

La notion de Distinguished Name (nom distinct, souvent abrégé en DN) est très similaire à la notion de Primary Key dans les SGBDR. En effet, un nom distinct permet d'identifier de façon unique une entrée de l'annuaire électronique.

Pour illustrer les différentes notions de DN qui existent, nous allons prendre l'exemple d'un salarié du MIT possédant les caractéristiques suivantes (extraites au format LDIF depuis un accès anonyme au LDAP du MIT) :

dn: cn=Amy V Francis+employeeNumber=34f4e35b18979bb6400f3a7b8fa88821,ou=empl
 oyees,dc=mit,dc=edu
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: eduPerson
objectClass: posixAccount
objectClass: apple-user
objectClass: shadowAccount
cn: Amy V Francis
gidNumber: 101
givenName: Amy V
sn: Francis
[...]
				

Il existe plusieurs types de DN :

Distinguished Name

Dans le cas d'Amy V. Francis, le nom distinct qui permet de l'identifier de façon unique dans l'annuaire LDAP du MIT est : cn=Amy V Francis+employeeNumber=34f4e35b18979bb6400f3a7b8fa88821,ou=employees,dc=mit,dc=edu

On retrouve dans cette dénomination le chemin complet d'accès à l'entrée LDAP correspondante, en lecture de droite à gauche :

+ dc=mit,dc=edu
|
+--+ ou=employees
   |
   +-- cn=Amy V Francis+employeeNumber=34f4e35b18979bb6400f3a7b8fa88821

On remarque que le séparateur utilisé pour dissocier les différentes constituantes du chemin d'accès sont la virgule "," et non le "/" comme c'est le cas pour un système de fichier (qui, lui aussi, est hiérarchique). De plus, l'entrée dc=mit,dc=edu est elle même située sous la racine de l'annuaire, appelée Root DSE (entrée système de l'annuaire).

Chaque entrée possède un DN, y compris s'il possède des enfants (s'il est un composant de la hiérarchie permettant d'accéder à d'autres entrées du LDAP).

Relative Distinguished Name (RDN)

Le RDN, ou nom distinct relatif, est la partie du DN qui représente une entrée à part entière, relativement à son parent. Il est généralement constitué d'un ou plusieurs attributs obligatoires décrivant l'entrée.

Par exemple, le RDN du groupe "employees" par rapport à son parent dc=mit,dc=edu est ou=employees. Son DN complet est ou=employees,dc=mit,dc=edu. En effet, l'attribut "ou" est obligatoire pour les objets de type "organisationalUnit" dans l'annuaire LDAP du MIT.

Dans le cas d'Amy V. Francis, son RDN est cn=Amy V Francis+employeeNumber=34f4e35b18979bb6400f3a7b8fa88821, relativement à son parent dont le DN complet est ou=employees,dc=mit,dc=edu.

Le RDN change relativement peu dans le temps. Cependant, en cas par exemple de changement de statut d'un étudiant devenant salarié, l'entrée LDAP correspondante peut changer de parent, ce qui change son DN mais pas son RDN. Aussi, il peut être plus fréquent de changer de parent que de RDN. Aussi, il est souvent affecté un numéro unique d'entrée dans les attributs opérationnels (operationnal attributes) de l'entrée.

Schéma d'un annuaire

Comme pour un SGBDR, un annuaire possède un schéma qui définit :

Ce schéma est lui-même stocké sous forme d'entrées LDAP ayant pour type structurel une des classes héritant de la classe abstraite metaTop. Cependant, le format de stockage du schéma dépend de l'implantation utilisée.

Dans l'implémentation d'Apache Directory Server, le schéma de l'annuaire est stocké dans l'unité organisationnelle ou=schema, qui contient lui même plusieurs entrées de type metaSchema, définissant un sous-ensemble d'informations de schéma (attributs, classes, ...).

Cette approche modulaire permet d'exporter/importer un ensemble d'attributs liés, par exemple, à une application particulière, comme une partie de schéma adaptée pour l'utilisation de Microsoft Exchange, ou pour l'utilisation de Samba (SMB) en conjonction avec LDAP pour simuler un Active Directory Windows sur une machine Unix.

Les entrées et les attributs

Les deux notions clefs concernant les objets stockés dans un annuaire LDAP sont les attributs et les entrées.

Les attributs

Comme nous l'avons vu précédemment dans la section "Orientation Objet", un attribut possède un numéro d'identification unique (OID), un ou plusieurs noms, peut être multi-valué ou mono-valué, et peut être obligatoire ou optionnel en fonction des classes dans lesquelles il est référencé.

De plus, il possède un type. De nombreux types sont intégrés dans la norme LDAP, parmi lesquels :

De plus, pour chaque attribut, il est possible de définir une fonction de comparaison, une fonction de comparaison pour les chaînes partielles, et de nombreux autres types de fonction.

En effet, les filtres de recherche sont écrits sous forme de chaînes de caractères, et pour qu'une recherche sur des nombres ou autre types de données puissent être réalisées, il est nécessaire de définir une fonction de conversion vers le type de données stockées.

Les entrées

Une entrée est une instance d'une classe structurelle, qui peut également hériter de classes auxiliaires. En conséquence, chacun de ces héritages impose (m-must) ou propose (m-may) la présence de certains attributs.

La classe structurelle dont l'entrée hérite directement définit ce qu'elle est et porte le nom, dans la norme LDAP, de "Classe d'objet structurelle de l'entrée".

Lorsqu'un attribut n'est pas présent, il n'est tout simplement pas stocké dans l'entrée, par opposition à un SGBDR où un champs absent vaut NULL et occupe inutilement de la place.

Comparatif SGBDR / Annuaires

La comparaison entre un Système de Gestion de Base de Données Relationnelles n'est pas très équitable par rapport à un annuaire. En effet, les objectifs des deux systèmes ne sont pas les mêmes, comme le montre le tableau ci-après. Toutefois, le parallèle est intéressant pour noter la différence de topologie entre les deux systèmes.

Définition SGBDR LDAP
Ensemble d'information définissant une instance Line/Result Entry
Attribut d'un objet Field Attribute
Clef identifiant une entrée de façon unique Primary Key Distinguished Name
Classe structurelle Table Structural Object Class
Absence d'un attribut Valeur à NULL (occupe de la place) Absence de valeur (pas de place occupée)
Transactions Supporté Supporté par extensions seulement
Jointures entre tables Supporté Non supporté
Opérations optimisées Lecture/Ecriture/Recherche Lecture/Recherche
Types d'informations Tous types Optimisé pour les éléments constitutifs du SI

Suite [URL et Recherches] >>>