Groupe de travail Réseau K. Zeilenga
Demande de commentaires : 4512 OpenLDAP Foundation
Rend obsolètes : 2251, 2252, 2256, 3674 Juin 2006
Catégorie : En cours de normalisation
Protocole léger d'accès à un annuaire (LDAP) : modèles d'information d'annuaire
Statut du présent mémoire
Le présent document spécifie, pour la communauté Internet, un
protocole en cours de normalisation et sollicite des discussions et
des suggestions d'amélioration. Il convient de se reporter à l'édition
en vigueur des « Internet Official Protocol Standards » (STD 1) pour
connaître l'état et le statut de normalisation de ce protocole. La
diffusion du présent mémoire n'est soumise à aucune restriction.
Avis de droit d'auteur
Copyright (C) The Internet Society (2006).
Résumé
Le protocole léger d'accès à un annuaire (Lightweight Directory Access
Protocol, LDAP) est un protocole Internet permettant d'accéder à des
services d'annuaire distribués qui fonctionnent conformément aux
modèles de données et de services X.500. Le présent document décrit
les modèles d'information d'annuaire X.500 tels qu'ils sont utilisés
dans LDAP.
Table des matières
Introduction ....................................................3
1.1. Relation avec les autres spécifications LDAP ...............3
1.2. Relation avec X.501 ........................................4
1.3. Conventions ................................................4
1.4. Productions ABNF communes ..................................4
Modèle des informations utilisateur de l'annuaire ...............6
2.1. Arbre des informations d'annuaire ..............................7
2.2. Structure d'une entrée ......................................7
2.3. Nommage des entrées .........................................8
2.4. Classes d'objet .............................................9
2.5. Descriptions d'attribut ....................................12
2.6. Entrées alias ..............................................16
Schéma d'annuaire ...............................................22
4.1. Définitions de schéma ......................................23
4.2. Sous-entrées de sous-schéma ................................32
4.3. Classe d'objet 'extensibleObject' ..........................35
4.4. Découverte du sous-schéma ..................................35
Modèle informationnel de DSA (serveur) ..........................36
5.1. Exigences de données propres au serveur ....................36
Autres considérations ...........................................40
6.1. Préservation des informations utilisateur ..................40
6.2. Noms courts ................................................41
6.3. Mise en cache et mise en miroir ..............................41
Lignes directrices d'implémentation .............................42
7.1. Lignes directrices pour les serveurs .......................42
7.2. Lignes directrices pour les clients ........................42
Considérations de sécurité ......................................43
Considérations relatives à l'IANA ...............................43
Références normatives ..........................................45
Annexe A. Modifications ............................................47
A.1. Modifications par rapport à la RFC 2251 ....................47
A.2. Modifications par rapport à la RFC 2252 ....................49
A.3. Modifications par rapport à la RFC 2256 ....................50
A.4. Modifications par rapport à la RFC 3674 ....................51
Introduction
Le présent document traite des modèles d'information d'annuaire X.500
[X.501] tels qu'ils sont utilisés par le protocole léger d'accès à un
annuaire (LDAP) [RFC4510].
L'annuaire est « un ensemble de systèmes ouverts qui coopèrent afin de
fournir des services d'annuaire » [X.500]. Les informations détenues
dans l'annuaire sont collectivement appelées base d'informations
d'annuaire (Directory Information Base, DIB). Un utilisateur de
l'annuaire, qui peut être une personne ou une autre entité, accède à
l'annuaire par l'intermédiaire d'un client (ou agent utilisateur
d'annuaire (Directory User Agent, DUA)). Pour le compte de
l'utilisateur de l'annuaire, le client interagit avec un ou plusieurs
serveurs (ou agents système d'annuaire (Directory System Agents,
DSA)). Un serveur détient un fragment de la DIB.
La DIB contient deux catégories d'informations :
1) les informations utilisateur (par exemple, les informations fournies et administrées par les utilisateurs). La section 2 décrit le modèle des informations utilisateur ; 2) les informations administratives et opérationnelles (par exemple, les informations utilisées pour administrer et/ou exploiter l'annuaire). La section 3 décrit le modèle des informations administratives et opérationnelles de l'annuaire.
Ces deux modèles, appelés modèles génériques d'information d'annuaire,
décrivent la manière dont les informations sont représentées dans
l'annuaire. Ils fournissent un cadre à d'autres modèles d'information.
La section 4 traite du modèle d'information de sous-schéma et de la
découverte du sous-schéma. La section 5 traite du modèle informationnel
de DSA (serveur).
D'autres modèles d'information X.500 (tels que les modèles
d'information relatifs au contrôle d'accès, aux connaissances de
distribution et aux connaissances de réplication) peuvent être adaptés
pour être utilisés dans LDAP. La spécification de la manière dont ces
modèles s'appliquent à LDAP est laissée à de futurs documents.
1.1. Relation avec les autres spécifications LDAP
Le présent document fait partie intégrante de la spécification
technique LDAP [RFC4510], qui rend entièrement obsolète la précédente
spécification technique LDAP définie par la RFC 3377.
Le présent document rend obsolètes les sections 3.2 et 3.4 de la
RFC 2251, ainsi que certaines parties des sections 4 et 6. L'annexe A.1
récapitule les modifications apportées à ces sections. Le reste de la
RFC 2251 est rendu obsolète par les documents [RFC4511], [RFC4513] et
[RFC4510].
Le présent document rend obsolètes les sections 4, 5 et 7 de la
RFC 2252. L'annexe A.2 récapitule les modifications apportées à ces
sections. Le reste de la RFC 2252 est rendu obsolète par [RFC4517].
Le présent document rend obsolètes les sections 5.1, 5.2, 7.1 et 7.2
de la RFC 2256. L'annexe A.3 récapitule les modifications apportées à
ces sections. Le reste de la RFC 2256 est rendu obsolète par [RFC4519]
et [RFC4517].
Le présent document rend entièrement obsolète la RFC 3674. L'annexe
A.4 récapitule les modifications intervenues depuis la RFC 3674.
1.2. Relation avec X.501
Le présent document reprend des éléments de [X.501], avec ou sans
adaptation, dans la mesure nécessaire à la description de ce
protocole. Ces adaptations (ainsi que toute autre différence présente
dans ce document) s'appliquent à ce protocole, et uniquement à celui-ci.
1.3. Conventions
Les mots clés "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" et "OPTIONAL" employés
dans le présent document doivent être interprétés comme indiqué dans
le BCP 14 [RFC2119].
Les définitions de schéma sont fournies au moyen des formats de
description LDAP (tels que définis à la section 4.1). Les définitions
présentées ici sont mises en forme (avec retour à la ligne) pour en
faciliter la lecture. Les règles de correspondance et les syntaxes LDAP
référencées dans ces définitions sont spécifiées dans [RFC4517].
1.4. Productions ABNF communes
Plusieurs syntaxes du présent document sont décrites à l'aide de la
forme Backus-Naur augmentée (Augmented Backus-Naur Form, ABNF)
[RFC4234]. Ces syntaxes (ainsi qu'un certain nombre de syntaxes définies
dans d'autres documents) reposent sur les productions communes
suivantes :
Les identifiants d'objet (OID) [X.680] sont représentés dans LDAP au
moyen d'un format décimal pointé conforme à l'ABNF suivant :
numericoid = number 1*( DOT number )
Les noms courts, également appelés descripteurs, servent d'alias plus
lisibles pour les identifiants d'objet. Ils sont insensibles à la casse
et respectent l'ABNF suivant :
descr = keystring
Lorsqu'il est possible de spécifier soit un identifiant d'objet, soit
un nom court, la production suivante est utilisée :
oid = descr / numericoid
Bien que la forme soit généralement préférable lorsque
l'utilisation est limitée à des noms courts qui désignent des
identifiants d'objet identifiant des objets de même nature (par exemple,
des descriptions de type d'attribut, de règle de correspondance ou de
classe d'objet), la forme devrait être utilisée lorsque les
identifiants d'objet peuvent identifier plusieurs natures d'objets ou
lorsqu'aucun nom court (descripteur) non ambigu n'est disponible.
Les implémentations SHOULD traiter comme non reconnus les noms courts
(descripteurs) employés de manière ambiguë (comme indiqué ci-dessus).
Les noms courts (descripteurs) sont examinés plus en détail à la
section 6.2.
Modèle des informations utilisateur de l’annuaire
Comme l’indique [X.501] :
L’annuaire a pour objet de conserver les informations relatives à des objets présentant un intérêt (les objets) dans un certain « monde », et de permettre l’accès à ces informations. Un objet peut être tout élément identifiable (auquel on peut attribuer un nom). Une classe d’objet (object class) est une famille identifiée d’objets, réels ou concevables, qui partagent certaines caractéristiques. Tout objet appartient à au moins une classe. Une classe d’objet peut être une sous-classe d’autres classes d’objet ; les membres de la première classe, la sous-classe, sont alors également considérés comme membres des secondes, les superclasses. Les sous-classes peuvent elles-mêmes avoir des sous-classes, et ainsi de suite à une profondeur quelconque.
Une entrée d’annuaire (directory entry), c’est-à-dire un ensemble nommé
d’informations, est l’unité d’information fondamentale conservée dans
l’annuaire. Il existe plusieurs types d’entrées d’annuaire.
Une entrée d’objet (object entry) représente un objet particulier. Une
entrée d’alias (alias entry) fournit un autre nom. Une sous-entrée
(subentry) contient des informations administratives et/ou opérationnelles.
L’ensemble des entrées représentant la base d’informations d’annuaire
(Directory Information Base, DIB) est organisé hiérarchiquement selon une
structure arborescente appelée arbre des informations d’annuaire
(Directory Information Tree, DIT).
La section 2.1 décrit l’arbre des informations d’annuaire.
La section 2.2 traite de la structure des entrées.
La section 2.3 traite de la dénomination des entrées.
La section 2.4 traite des classes d’objet.
La section 2.5 traite des descriptions d’attribut.
La section 2.6 traite des entrées d’alias.
2.1. Arbre des informations d’annuaire
Comme indiqué précédemment, la DIB se compose d’un ensemble d’entrées
organisées hiérarchiquement selon une structure arborescente appelée arbre
des informations d’annuaire (DIT) ; il s’agit précisément d’un arbre dont
les sommets sont les entrées.
Les arêtes entre les sommets définissent des relations entre les entrées.
S’il existe une arête de X vers Y, l’entrée en X est le supérieur immédiat
de Y et Y est le subordonné immédiat de X. Les supérieurs d’une entrée sont
son supérieur immédiat et les supérieurs de celui-ci. Les subordonnés d’une
entrée sont tous ses subordonnés immédiats et leurs propres subordonnés.
De même, la relation supérieur/subordonné entre les entrées d’objet permet
de déduire une relation entre les objets qu’elles représentent. Des règles
de structure du DIT peuvent régir les relations entre les objets.
Remarque : le supérieur immédiat d’une entrée est également appelé son
parent, et le subordonné immédiat d’une entrée est également
appelé son enfant. Les entrées qui ont le même parent sont
appelées entrées sœurs.
2.2. Structure d’une entrée
Une entrée se compose d’un ensemble d’attributs qui contiennent des
informations sur l’objet représenté par cette entrée. Certains attributs
représentent des informations utilisateur et sont appelés attributs
utilisateur (user attributes). D’autres représentent des informations
opérationnelles et/ou administratives et sont appelés attributs
opérationnels (operational attributes).
Un attribut est constitué d’une description d’attribut (un type et zéro ou
plusieurs options) et d’une ou plusieurs valeurs associées. Un attribut est
souvent désigné par sa description d’attribut. Par exemple, l’attribut
'givenName' est celui qui se compose de la description d’attribut
'givenName' (le type d’attribut 'givenName' [RFC4519] et zéro option) et
d’une ou plusieurs valeurs associées.
Le type d’attribut détermine si l’attribut peut avoir plusieurs valeurs,
la syntaxe et les règles de correspondance utilisées pour construire et
comparer ses valeurs, ainsi que d’autres fonctions. Les options indiquent
des sous-types et d’autres fonctions.
Les valeurs d’attribut sont conformes à la syntaxe définie pour le type
d’attribut.
Deux valeurs d’un même attribut ne peuvent pas être équivalentes. Deux
valeurs sont considérées comme équivalentes si et seulement si elles
correspondent selon la règle de correspondance d’égalité du type
d’attribut. Si le type d’attribut ne définit aucune règle de correspondance
d’égalité, deux valeurs sont équivalentes si et seulement si elles sont
identiques. (Voir la section 2.5.1 pour les autres restrictions.)
Par exemple, un attribut 'givenName' peut avoir plusieurs valeurs ; celles-ci
doivent être des chaînes d’annuaire (Directory Strings) et ne sont pas
sensibles à la casse. Un attribut 'givenName' ne peut pas contenir à la fois
"John" et "JOHN", car il s’agit de valeurs équivalentes selon la règle de
correspondance d’égalité du type d’attribut.
En outre, aucun attribut ne doit avoir une valeur qui ne soit pas équivalente
à elle-même. Par exemple, l’attribut 'givenName' ne peut pas avoir comme
valeur une chaîne d’annuaire comprenant le point de code REPLACEMENT
CHARACTER (U+FFFD), car une correspondance faisant intervenir cette chaîne
d’annuaire a pour résultat Undefined selon la règle de correspondance
d’égalité de cet attribut.
Lorsqu’un attribut sert à nommer l’entrée, une et une seule de ses valeurs
est utilisée pour former le nom distinctif relatif (Relative Distinguished
Name). Cette valeur est appelée valeur distinctive (distinguished value).
2.3. Dénomination des entrées
2.3.1. Noms distinctifs relatifs
Chaque entrée est nommée relativement à son supérieur immédiat. Ce nom
relatif, appelé nom distinctif relatif (Relative Distinguished Name, RDN)
[X.501], se compose d’un ensemble non ordonné d’une ou plusieurs assertions
de valeur d’attribut (attribute value assertions, AVA), chacune constituée
d’une description d’attribut sans option et d’une valeur d’attribut. Ces AVA
sont choisies pour correspondre à des valeurs d’attribut de l’entrée
(chacune étant une valeur distinctive).
Le nom distinctif relatif d’une entrée doit être unique parmi tous les
subordonnés immédiats du supérieur immédiat de l’entrée (c’est-à-dire parmi
toutes les entrées sœurs).
Voici des exemples de représentations sous forme de chaîne de RDN
[RFC4514] :
Le dernier est un exemple de RDN multivalué, c’est-à-dire un RDN composé de
plusieurs AVA.
2.3.2. Noms distinctifs
Le nom pleinement qualifié d’une entrée, appelé nom distinctif
(Distinguished Name, DN) [X.501], est la concaténation de son RDN et du DN de
son supérieur immédiat. Un nom distinctif désigne sans ambiguïté une entrée
de l’arbre. Voici des exemples de représentations sous forme de chaîne de DN
[RFC4514] :
Un alias, ou nom d’alias, est « un nom d’objet fourni par l’utilisation
d’entrées d’alias » [X.501]. Les entrées d’alias sont décrites à la
section 2.6.
2.4. Classes d’objet
Une classe d’objet est « une famille identifiée d’objets (ou d’objets
concevables) qui partagent certaines caractéristiques » [X.501].
Selon la définition donnée dans [X.501] :
Les classes d’objet sont utilisées dans l’annuaire à plusieurs fins : - décrire et classer les objets et les entrées qui correspondent à ces objets ; - le cas échéant, contrôler le fonctionnement de l’annuaire ; - réglementer, conjointement avec les spécifications des règles de structure du DIT, la position des entrées dans le DIT ; - réglementer, conjointement avec les spécifications des règles de contenu du DIT, les attributs contenus dans les entrées ; - identifier les classes d’entrée que l’autorité administrative compétente doit associer à une politique donnée. Une classe d’objet (une sous-classe) peut être dérivée d’une classe d’objet (sa superclasse directe), elle-même dérivée d’une classe d’objet encore plus générique. Pour les classes d’objet structurelles, ce processus s’arrête à la classe d’objet la plus générique, 'top' (définie à la section 2.4.1). L’ensemble ordonné des superclasses allant jusqu’à la classe d’objet la plus élevée d’une classe d’objet constitue sa chaîne de superclasses (superclass chain). Une classe d’objet peut être dérivée de deux superclasses directes ou plus (des superclasses qui ne font pas partie de la même chaîne de superclasses). Cette faculté de la relation de sous-classe est appelée héritage multiple (multiple inheritance).
Chaque classe d’objet identifie l’ensemble des attributs dont la présence
est obligatoire dans les entrées appartenant à la classe, ainsi que
l’ensemble des attributs dont la présence y est autorisée. Une entrée d’une
classe devant satisfaire aux exigences de chaque classe à laquelle elle
appartient, on peut dire qu’une classe d’objet hérite de ses superclasses
les ensembles d’attributs autorisés et obligatoires. Une sous-classe peut
déclarer obligatoire un attribut que sa superclasse autorise. Si un
attribut appartient aux deux ensembles, sa présence est obligatoire.
Chaque classe d’objet est définie comme appartenant à l’un des trois types
suivants : abstraite (Abstract), structurelle (Structural) ou auxiliaire
(Auxiliary).
Chaque classe d’objet est identifiée par un identifiant d’objet (object
identifier, OID) et, facultativement, par un ou plusieurs noms courts
(descripteurs).
2.4.1. Classes d’objet abstraites
Comme son nom l’indique, une classe d’objet abstraite fournit un socle de
caractéristiques dont d’autres classes d’objet peuvent être définies comme
héritant. Une entrée ne peut pas appartenir à une classe d’objet abstraite,
sauf si elle appartient à une classe structurelle ou auxiliaire qui hérite
de cette classe abstraite.
Les classes d’objet abstraites ne peuvent pas dériver de classes d’objet
structurelles ou auxiliaires.
Toutes les classes d’objet structurelles dérivent, directement ou
indirectement, de la classe d’objet abstraite 'top'. Les classes d’objet
auxiliaires ne dérivent pas nécessairement de 'top'.
Voici la définition de classe d’objet (voir la section 4.1.1) de la classe
d’objet 'top' :
( 2.5.6.0 NAME 'top' ABSTRACT MUST objectClass )
Toutes les entrées appartiennent à la classe d’objet abstraite 'top'.
2.4.2. Classes d’objet structurelles
Comme l’indique [X.501] :
Une classe d’objet définie pour être utilisée dans la spécification structurelle du DIT est appelée classe d’objet structurelle. Les classes d’objet structurelles servent à définir la structure des noms des objets pour les entrées conformes. Une entrée d’objet ou d’alias est caractérisée par une et une seule chaîne de superclasses de classes d’objet structurelles, dont la classe d’objet la plus subordonnée est une unique classe d’objet structurelle. Cette classe d’objet structurelle est appelée la classe d’objet structurelle de l’entrée. Les classes d’objet structurelles sont liées aux entrées associées : - une entrée conforme à une classe d’objet structurelle doit représenter l’objet du monde réel contraint par cette classe d’objet ; - les règles de structure du DIT ne font référence qu’aux classes d’objet structurelles ; la classe d’objet structurelle d’une entrée sert à préciser la position de cette entrée dans le DIT ; - la classe d’objet structurelle d’une entrée est utilisée, avec une règle de contenu du DIT associée, pour contrôler le contenu de l’entrée. La classe d’objet structurelle d’une entrée ne doit pas être modifiée.
Chaque classe d’objet structurelle est une sous-classe, directe ou
indirecte, de la classe d’objet abstraite 'top'.
Les classes d’objet structurelles ne peuvent pas avoir pour superclasse une
classe d’objet auxiliaire.
Chaque entrée est considérée comme appartenant à sa classe d’objet
structurelle ainsi qu’à toutes les classes de la chaîne de superclasses de
celle-ci.
2.4.3. Classes d’objet auxiliaires
Les classes d’objet auxiliaires servent à enrichir les caractéristiques des
entrées. Elles sont couramment utilisées pour étendre les ensembles
d’attributs dont la présence est obligatoire ou autorisée dans une entrée.
Elles peuvent servir à décrire des entrées ou des classes d’entrées.
Les classes d’objet auxiliaires ne peuvent pas avoir pour superclasse une
classe d’objet structurelle.
Une entrée peut appartenir à n’importe quel sous-ensemble de l’ensemble des
classes d’objet auxiliaires autorisées par la règle de contenu du DIT
associée à la classe d’objet structurelle de l’entrée. Si aucune règle de
contenu du DIT n’est associée à la classe d’objet structurelle de l’entrée,
celle-ci ne peut appartenir à aucune classe d’objet auxiliaire.
L’ensemble des classes d’objet auxiliaires auxquelles appartient une entrée
peut évoluer au fil du temps.
2.5. Descriptions d'attribut
Une description d'attribut se compose d'un type d'attribut (voir la
Section 2.5.1) et d'un ensemble de zéro ou plusieurs options d'attribut
(voir la Section 2.5.2).
Une description d'attribut est représentée par l'ABNF suivante :