L'arborescence d'informations (DIT)
LDAP présente les informations sous forme d'une arborescence d'informations hiérarchique appelée DIT (Directory Information Tree).
L'entrée est l'unité de base d'un annuaire (DSE, Directory Service Entry). Elle correspond à une branche de l'arborescence.
Chaque entrée correspond à un objet appelé objectClass, par exemple une personne, un objet matériel, des paramètres, …
Cet objectClass est constituée d'un ensemble de paires clés/valeurs appelées attributs obligatoires ou facultatifs.
Les types d'attributs sont des règles de codage et de correspondance, qui détermine les types données et les comparaisons à appliquer lors d'une recherche.
Le schéma c'est l'ensemble des définitions d'objets et d'attributs qu'un serveur LDAP peut gérer. Cela permet de définir si un attribut peut avoir une ou plusieurs valeurs et/ou de les regrouper par objet (objectclass) pour définir s'ils sont obligatoires ou pas.
DN et RDN
Une entrée est indexée par un nom distinct (DN, distinguished name) permettant d'identifier de manière unique un élément. Un DN se construit en prenant le nom de l'élément, appelé Relative Distinguished Name (RDN, c'est-à-dire le chemin de l'entrée par rapport à un de ses parents), et en lui ajoutant l'ensemble des nom des entrées parentes.
Le DN et le RDN est comparable au chemin d'un fichier dans un répertoire. Le DN, c'est le chemin complet. Il est unique mais n'est pas figé. Il permet de déterminer la place dans l'arbre de l'entrée, car il concatène les RDN au-dessus de lui, mais l'entrée peut être déplacée, et le DN donc redéterminé.
Dans l'exemple d'arborescence ci-dessus :
DN (Distinguished Name) : uid=Jean-Christian Ranu,ou=users,dc=cogip,dc=fr
RDN (Relative Distinguished Name) : uid=Jean-Christian Ranu
Le RDN peut avoir plusieurs valeurs, comme un clé primaire composite (faite de plusieurs champs) dans un SGBD.
Imaginons qu'il y ait à la COGIP des personnes ayant le même nom (Jean Martin), placé sous le même parent (ou=users). Ni le cn (common name), ni l'ou (organisational unit) ne serait unique. La combinaison des deux en revanche donne un RDN unique. Il faut dans ce cas séparer les valeurs par "+".
# 1ere personne dn: cn:Jean Martin+ou:ventes,ou=users,dc=cogip,dc=fr cn: Jean Matin ou:ventes [...] . # 2eme personne dn cn:Jean Martin+ou:compta,ou=users,dc=cogip,dc=fr cn: Jean Martin ou: compta [...]
Les attributs
Une entrée peut avoir un ou plusieurs attributs. Il est séparé de sa valeur par ":" et peut avoir plusieurs valeurs. Il est alors sur plusieurs lignes avec des valeurs différentes.
dn: cn:Jean Martin+ou:ventes,ou=users,dc=cogip,dc=fr objectClass: person cn: Jean Matin ou:ventes [...] telephoneNumber: +33 1 02 03 04 05 telephoneNumber: +33 9 08 07 06 05 [...]
Chaque entrée est constituée d'un ensemble d'attributs. Il existe deux types d'attributs :
Les attributs normaux : ceux-ci sont les attributs habituels (nom, prénom, ...) caractérisant l'objet
Les attributs opérationnels : ceux-ci sont des attributs auxquels seul le serveur peut accéder afin de manipuler les données de l'annuaire (dates de modification, ...)
Les classes d'objets
L'objectClass est un regroupement d'attributs qui définit une entrée, comme une classe en POO a des propriétés qui représentent l'objet. Ces attributs sont obligatoires ou facultatifs.
objectClass est lui-même un attribut obligatoire d'une entrée, qui peut avoir un ou plusieurs objectClass. Ces classes d'objet définissent la présence de tous les attributs d'une entrée.
dn: cn:Jean-christian Ranu,ou=users,dc=cogip,dc=fr objectClass: person objectClass: posixAccount
Le caractère obligatoire ou facultatif des attributs, ainsi que le type de classe, sont définis dans les schémas.
Il existe 3 types de classe d'objet.
Structurelle : représente un objet réel, tel que personne, domaine ou entité... Chaque entrée doit avoir au moins 1 classe d'objet structurelle dans l'attribut objectClass.
Auxiliaire : sert à compléter les informations d'une classe structurelle. Elle ne peut pas être employé seule.
Abstraite : comme en POO, elle ne peut être qu'étendue par une autre classe d'objet, et ne peut pas être utilisée directement.
Les schémas
De le même façon que les objectClass regroupe les attributs, les schéma listent tous les objectClass disponibles. Un annuaire peut avoir plusieurs schémas (chargés au démarrage de LDAP).
Les schémas définissent aussi la correspondance, la syntaxe et les types d'attributs. Il est également possible d'ajouter son propre schéma, et donc de nouveaux objets.
Type d'attribut
Chaque type d'attribut doit être identifié par un OID. Chaque type d'attribut doit avoir au moins un attribut SUP, si aucune syntaxe (SYNTAX) n'est spécifiée, on prend alors celle du supertype
attributetype ( 2.5.4.20 NAME 'telephoneNumber' DESC 'An integer uniquely identifying a user in a domain' EQUALITY telephoneNumberMatch SUBSTR telephoneNumberSubstringMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )
L'OID de telephoneNumber est 2.5.4.20. La valeur est évaluée avec telephoneNumberMatch, et doit contenir ce que spécifié dans telephoneNumberSubstringMatch. 1.3.6.1.4.1.1466.115.121.1.50 correspond à la syntaxe du n° de téléphone, exemple: +1 234 567 8901.
Liste des propriétés utilisées pour définir un type d'attribut
NAME | Nom du type d'attribut |
DESC | Description |
OBSOLETE | indique si le type d'attribut est actif |
SUP | définit le supertype |
EQUALITY | Type d'égalité à mettre en œuvre lors d'une recherche |
ORDERING | Correspondance de tri |
SUBSTR | Correspondance de subtring |
SYNTAX | OID de la syntaxe, et nombre maxi de caractère entre accolade {} |
SINGLE-VALUE | restreint à une seule valeur |
COLLECTIVE | si type d'attribut est collectif |
NO-USER-MODIFICATION | l'utilisateur ne peut pas le modifier |
USAGE | indique l'application |
objectClass
Comme les attributs, l'objectClass est toujours identifié par un OID.
( 2.5.6.6 NAME 'person' SUP top STRUCTURAL MUST ( sn $ cn ) MAY ( userPassword $ telephoneNumber $ seeAlso $ description ) )
La classe person étend la classe top et est une classe structurelle, c'est-à-dire qu'elle représente un objet réel. Les attributs sn et cn sont obligatoires; Les autres userPassword, telephoneNumber, seeAlso, description sont facultatifs.
Liste des propriétés utilisées pour définir un objectClass
NAME | Nom de la classe |
Type d'objet | STRUCTURAL, ABSTRACT, AUXILIARY (cf. Les classes d'objet) |
DESC | Description de la classe |
OBSOLETE | spécifie que cette classe ne doit plus être utilisée |
AUX | Liste les classes auxquelles cet objet peut appartenir |
MUST | regroupe les attributs d'un objectClass qui doivent être présent, ou au moins une valeur. |
MAY | liste les attributs facultatifs. |
NOT | Liste les attributs qui ne doivent pas être utilisés |
SUP | Classe parent étendue. (toutes les entrées héritent directement ou indirectement de la class top). |
Le format LDIF
Pour importer/exporter les données ainsi que la configuration du serveur, un format a été défini (RFC 2849) : LDIF (LDAP Data Interchange Format).
les commentaires commencent par "#", et s'étendent sur une seule ligne
Une entrée forme un paragraphe, et un fichier LDIF ne s'affranchit pas des schémas, qui valident une entrée.
Chaque ligne constitue un attribut.
Comme vu auparavant, les attributs sont constitués d'une clé et d'une valeur séparée par ":".
Prenons l'exemple de Jean-Christian Ranu pour faire une entrée dans un fichier LDIF pour import.
dn: cn=Jean-Christian Ranu,ou=ventes,dc=cogip,dc=fr objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson cn: Jean-Christian Ranu cn: JC Ranu displayName: Jean-Christian Ranu sn: Ranu givenName: Jean-Christian initials: JCR title: manager, product development uid: jcranu mail: jc.ranu@cogip.fr telephoneNumber: +33 1 02 03 04 05 mobile: +33 6 78 90 01 02 o: COGIP ou: ventes departmentNumber: 2604 employeeNumber: 42 employeeType: full time preferredLanguage: fr, en-gb;q=0.8, en;q=0.7 labeledURI: http://www.cogip.fr/users/jcranu
