Lightweight Directory Access Protocol (LDAP)
Modèles de données
- Concept de stockage hiérarchique
- Orientation objet
- Distinguished Names
- Schéma d'un annuaire
- Les entrées et les attributs
- Comparatif SGBDR / Annuaires
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 :
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 :
- Tous les attributs ont un ou plusieurs noms uniques (m-name), qui sont communs à toutes les classes qui les utilisent. Leur type est donc définit indépendamment des classes dans lesquelles ils sont utilisés.
- Tous les attributs peuvent être monovalués (m-singleValue TRUE) ou multi-valués (m-singleValue FALSE).
- Chaque attribut possède un numéro d'objet unique (OID) qui le définit, et qui précise également la classe d'attribut à laquelle il appartient (core attributes, attributs pour comptes UNIX, ...).
- Une classe contient des attributs, qui sont optionnels (m-may) ou obligatoires (m-must)
- Par conséquent, si une entrée hérite de deux classes référençant un même attribut, on est assuré que le type de l'attribut est le même dans les deux classes, et si au moins une des deux le déclare obligatoire (m-must) alors il est obligatoire, sinon il est optionnel.
Une illustration de ce procédé d'héritage multiple est présentée ci-dessous, en UML :
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 :
- les attributs (type de données, multi-valuation, noms, ... - metaAttributeType)
- les classes d'objets (héritage, attributs requis, obligatoires... - metaObjectClass)
- les règles de recherche, de comparaisons (sensibilité à la casse...)
- les vérificateurs de syntaxe (conversion texte vers valeur booléenne ou entrée de liste)
- les règles d'accès à la structure/au contenu (ACL
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 :
- Chaîne de caractères
- Entier
- Numéro de téléphone
- Code postal
- ...
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 |