 |
 |
 |
|
LDAP
|
|
|
LDAP: Principes
|
|
|
|
|
META ANNUAIRE
|
|
|
|
|
|
|
|
|
 |
|
 |
|
|
|
|
|
|
|
 |
|
LDAP/X.500 : Les principes
|
|
 |
| Cette présentation résume la plupart des principes du modèle d'annuaire LDAP/X500, afin d'aider le lecteur n'ayant aucune connaissance de ses concepts. |
|
Les normes X.500
|
Les normes X500 officielles définies par le CCITT (CCITT Recommandations of the X500 series : The Directory) sont actuellement au nombre de deux : - La norme X500 1988 qui présente les concepts de base du modèle, de la sécurité, et n'offre que des recommandations et lignes de conduites, en ce qui concerne le modèle complet de sécurité, les protocoles de réplication de données, la gestion du schéma d'un arbre, etc ...
- La norme X500 1993 qui, en plus des concepts initiaux, normalise totalement les concepts de sécurité (droits d'accès, authentification, ...), de réplication de données, et la gestion du schéma d'annuaire.
La norme 1988 est pour l'instant la plus utilisée, mais ne normalise pas de façon fiable les outils indispensable au fonctionnemnt correct d'un Annuaire X500 ...
Cela explique qu'il existe de nombreux types de souches X500 différentes, dans lesquelles les concepts manquants sont implémentés, plus ou moins librement, à l'aide de solutions propriétaires. En découlent des problèmes d'inter-opérabilité entre les différents annuaires .... Le problème devrait se résoudre avec la nouvelle norme de 1993, avec l'adaptation des annuaires existants.
Aussi, pour permettre au lecteur de situer l'état de normalisation des divers concepts présentés, des commentaires de la forme :
(Recommandation 88, Normalisation 93)
ont été insérés en certains points clés de cette annexe. |
|
Le standard LDAP
|
LDAP (Lightweight Directory Access Protocol) est une suite de protocoles Internet, qui constitue une simplification de la norme X.500.
LDAP se base sur le modèle de service de X.500, il lui ressemble donc dans les aspects fondamentaux.
Les travaux sur LDAP sont aujourd'hui menés au sein d'IETF (Internet Engineering Task Force), on en est déjà à la troisième version du protocole (LDAPv3).
Dans la suite du document, si un aspect technique est commun à LDAP et à X.500, nous utiliserons le terme "LDAP/X.500".
|
|
Modèle d'information LDAP / X.500
|
Ce chapitre décrit le modèle des données d'un annuaire LDAP/X.500, à savoir la structure d'arbre, la forme des entrées LDAP/X.500, et la notion de schéma d'annuaire.
La DIB (Directory Information Base) LDAP / X.500
(Normalisation X.500 88 et 93 et LDAP)
Un annuaire LDAP/X.500 est une collection d'information de toutes catégories. Ces informations sont stockées dans la "Directory Information Base" ou DIB. La DIB est composées d'entrées, dont le contenu est régit par les notions d'objet et de classes.
La notion d'objets et de classes LDAP / X.500
La notion d'objet permet de représenter abstraitement tout type d'information ou d'entité existante. Une classe d'objet est une famille d'objets ayant certaines caractéristiques communes.
Une classe LDAP/X.500 permet de définir les particularités d'une famille d'objets, en spécifiant des attributs obligatoires, et/ou des attributs optionnels possibles. Il y a possiblité d'héritage entre classes, multiple ou non, pour les objets LDAP/X.500 (Pour une sous-classe, obtention automatique des attributs définis dans les classes supérieure dont elle hérite). Toutes les classes héritent de la classe Top, qui est la classe du sommet de la hiérarchie des classes (un seul attribut : objectClass). |
 |
Chaque entrée LDAP/X.500 est considérée comme étant la représentation d'un objet particulier, appartenant à une ou plusieurs classes.
Structure des entrées LDAP/X.500
Les entrées LDAP/X.500 sont une collection d'attributs. Chaque attribut décrit un type bien particulier d'information, et peut contenir une ou plusieurs valeurs (On dit qu'un attribut peut être multi-valué). A chaque type d'attribut est lié une syntaxe spécifique donnant le format possible de ses valeurs. |
 |
Un AVA (Attribute Value Assertion) est une expression dont le résultat est Vrai, Faux, ou Indéfini, exprimant un test entre un attribut et une de ses valeurs possibles. la forme est : attribut = valeur.
Ex : organizationName = Sysium
Les AVAs sont essentiellement utilisés pour construire les noms distinctifs des entrées (voir plus loin, structure de l'arbre et nommage des entrées).
Les OIDs (Object Identifiers) LDAP / X.500
Les Object Identifiers sont des suites uniques de nombres, qui servent à identifier de façon sûre un type de donnée. Des OIDs sont utilisés pour désigner l'identité des classes, des types d'attributs, et des syntaxes possibles de ces attributs. Les OIDs sont formés à partir de la hiérarchie spécifiée par l'OSI, au niveau mondial ( de la même façon que les objets décrits dans les MIBs...)
.Le DIT (Directory Information Tree) LDAP / X.500
(Normalisation X.500 88, 93 et LDAP)
Les entrées de la DIB sont organisées hiérarchiquement, sous forme d'un arbre, le DIT ou Directory Information Tree.
La structure de l'arbre et les différents types d'entrées LDAP / X.500
Un arbre LDAP/X.500 est organisé de façon arborescente, à partir d'une racine unique nommée 'root'. Cette racine peut être vue comme une entrée nulle (objet vide).
Globalement, le DIT contient deux types d'entrées : - Les entrées de type "Noeud", qui sont des entrées à part entière, et sont la base d'un sous-arbre du DIT.
- Les entrées de type "Feuille", qui terminent les branches des sous-arbres.
Les entrées de classe "Alias" ne peuvent être que du type "Feuille", et ne contiennent qu'une information permettant de pointer vers une autre entrée de l'arbre. |
 |
Le nommage des entrées LDAP / X.500
Un DIT étant structuré sous forme d'arbre, il convient de nommer chaque entrée par un nom tenant compte du chemin parcouru dans l'arbre pour l'atteindre, depuis la racine.
LDAP/X.500 se propose de donner un nom distinctif relatif (RDN ou Relative Distinguished Name) pour chaque entrée du DIT (noeud ou feuille), et de composer ensuite le nom distinctif de l'entrée (DN ou Distinguished Name) par 'juxtaposition' des différents RDNs du chemin utilisé depuis la racine, pour joindre l'entrée concernée.
Un RDN est composé d'un ou plusieurs AVAs (géneralement un seul pour des questions de clarté) utilisant toujours un attribut obligatoire de l'entrée, la plupart du temps sous sa forme abrègée, et une de ses valeurs.
Exemple de RDN : cn = Alfred Smith (cn : forme abrègée de commonName)
Voici un schéma montrant la construction d'un DN : |
 |
Le "Schéma" d'un annuaire LDAP/X.500
Afin de permettre une gestion restrictive de la structure possible du DIT, du type des classes d'objets, des attributs et de leur syntaxe, LDAP/X.500 offre le concept de "schéma" d'annuaire.
Le schéma d'un annuaire est un ensemble de règles, qui doivent être utilisées par le gestionnaire d'arbre (DIB et DIT), pour limiter les possibilités de création et de structuration des entrées.
Structure du DIT LDAP / X.500
(Normalisation X.500 88, 93 et LDAP)
A priori, les entrées du DIT pourraient être structurées de toutes les façons possibles. Afin de limiter ces possibilités, en vue d'imposer un forme particulière au DIT, LDAP/X.500 spécifie des règles appelées "DIT Structure Rules".
Ces règles décrivent, pour une classe d'entrée particulière, les classes possibles de l'entrée parente dans l'arbre, les classes possibles utilisables pour les entrées filles, ainsi que le ou les attributs obligatoires pouvant lui servir de RDN.
Cela permet de lier étroitement la structure du DIT avec les classes des objets utilisés pour les entrées.
Le schéma suivant donne un exemple de structuration. |
 |
Les classes d'objets LDAP / X.500
(Normalisation X.500 88, 93 et LDAP)
La définition des classes d'objets permet de controler les types des attributs présents dans les entrées, ainsi que les héritages utilisés.
Toutes les entrées d'un arbre doivent être conformes aux spécifications des classes qui lui ont été fournies. Cela évite d'avoir à gérer des objets "inclassables".
Définir une classe d'objets, c'est : - attribuer un OID à la classe
- indiquer les classes dont elle hérite
- spécifier les attributs obligatoires
- spécifier les attributs optionnels
Exemples :
CLASSE : person
CLASSE MERE : top
DOIT CONTENIR : commonName, surname
PEUT CONTENIR : description, seeAlso, telephoneNumber, userPassword
OID : l'OID officiel de la classe person
CLASSE : organizationalPerson
CLASSE MERE : person
DOIT CONTENIR : "vide"
PEUT CONTENIR : localityName, stateOrProvinceName, streetAddress, postalAddress, postalCode, etc ...
OID : l'OID officiel de la classe organizationalPerson
Les règles des classes d'objets sont désignées par "Object Class Rules".
Les attributs et la syntaxe des valeurs LDAP / X.500
(Normalisation X.500 88, 93 et LDAP)
Les attributs doivent être définis indépendamment des classes, dans lesquelles ils sont ensuite utilisés.
Leur définition comprend le ou les noms de l'attribut, un OID, une indication sur le nombre possible de valeurs (une, multi-valué limité ou illimité), un ou plusieurs champs permettant de définir les syntaxes des valeurs (types des syntaxes, séquences de syntaxes, longueurs possibles des champs, etc ...), et optionnelement les règles de comparaison supportées par les valeurs (Matching Rules).
En plus de la description des attributs, il est nécessaire de définir les differents types de syntaxes, simples ou composées d'autres syntaxes (champs à format complexes).
Les règles des attributs sont désignées par "Attribute Type Rules"
Les règles des syntaxes sont désignées par "Attribute Syntax Rules".
Définition, stockage et gestion du schéma LDAP/ X.500
La définition des règles d'un schéma est relativement abstraite, et nécessite, pour être utilisable, un stockage adéquat, et une gestion de la part du système de contrôle de l'arbre (le terme est volontairement peu précis : il peut s'agir d'un logiciel d'administration complexe, d'un simple DUA, d'un processus en relation directe avec le DSA, etc ..).
Dans la norme X500 88, aucune politique de stockage du schéma n'est décrite. Actuellement, la gestion des DIT Structure Rules, des classes, attributs et syntaxes, est réalisé librement par des implémentations propriétaires. La norme 93 définit les moyens de gérer le schéma d'annuaire, ce qui devrait rendre les solutions portables, et permettre l'administration uniforme de parcs entiers d'arbres X.500 d'origines diverses.
Voici un schéma résumant les interactions entre les concepts du schéma d'annuaire : |
 |
|
Modèle fonctionnel LDAP / X.500
|
Ce chapitre décrit l'architecture d'un système LDAP/X.500, ainsi que les différents services possibles.
Modèle clients / serveurs LDAP / X.500
(Normalisation 88, 93 et LDAP)
L'architecture LDAP/X.500 est du type client / serveur, ou les serveurs sont chargés de gérer les données de la DIB.
Les DSAs (Directory System Agents) LDAP / X.500
Un DSA est un serveur de l'architecture LDAP/X.500, chargé de gérer une DIB particulière, c'est-à-dire un morceau bien défini d'un arbre. Il peut connaître l'existence d'autres DSAs de l'environnement et, selon le modèle choisi, communiquer avec eux afin de faire traiter des requêtes sur des données qu'il ne dirige pas (expliqué plus loin).
Dans le modèle X.500, les DSAs communiquent entre eux par le protocole DSP (Directory System Protocol), et chacun peut fournir zéro ou plusieurs points d'accès à divers clients, les DUAs ...
La notion de DSP n'existe pas dans LDAP.
Les DUAs (Directory User Agents) LDAP / X.500
Les Directory User Agents sont les clients des DSAs. Par leur intermédiaire que l'utilisateur peut formuler des requêtes vers les DSAs qui lui sont accessibles.
Dans le modèle X.500, un DUA communique avec les DSAs par le protocole DAP (Directory Access Protocol), de son côte, un client LDAP utilise le protocole allégé de DAP : LDAP, bien évidemment.
Le modèle LDAP/X.500 ne prévoit pas de communication entre DUAs.
Un DUA peut être tout type d'application cliente des DSAs, comme un logiciel d'administration LDAP/X.500, par exemple ...
Vue globale du modèle clients / serveurs : Voici un schéma résumant la base du modèle d'architecture X.500 : |
 |
Si on remplace, dans la figure ci-dessus, DAP par LDAP et on supprime les liens DSP, on obtient un schéma qui s'applique à LDAP.
Le modèle LDAP/X.500 n'est pas celui d'une base de données, car il ne supporte pas le modèle transactionnel, ni les opérations atomiques. L'architecture LDAP/X.500 est conçue avant-tout pour privilégier les opérations de lecture de données. En effet, on suppose que ce type d'annuaire est utilisé pour stocker des informations relativement stables, et donc nécessitant peu d'écritures ...
Les services fournis par LDAP / X.500
(Normalisation X.500 88 et 93, LDAP) LDAP/X.500 offre aux DUAs la possibilité d'utiliser les services suivants :
Les connections
Elles permettent d'ouvrir un canal de communication vers un DSA, et éventuellement de s'authentifier (sessions) par un nom d'utilisateur et un mot de passe. L'authentification peut être "simple" ou "forte" (voir plus loin, La sécurité).
Les lectures
Ce sont les services privilégiés de LDAP/X.500. La norme en définit cinq types : - Read :lecture d'une partie ou de la totalité d'une entrée (par filtrage).
- Compare :Comparaison des valeurs d'un attribut d'une entrée avec une valeur donnée.
- List :Listage des entrées filles d'un noeud donné.
- Search :Recherche d'une information (attribut, valeurs, ...) dans une partie ou la totalité d'un sous-arbre, à partir d'un noeud donné.
- Abandon :Abandon d'une requête en cours de traitement.
Les écritures
LDAP/X.500 en définit quatre : - Add Entry Ajout d'une entrée feuille (object ou alias) dans le DIT.
- Remove Entry Destruction d'une entrée feuille du DIT.
- Modify Entry Modification des attributs d'une entrée, excepté la valeur donnant le RDN.
- Modify RDN Modification du RDN d'une entrée.
Distribution d'un arbre LDAP / X.500
(Recommandation 88, Normalisation 93)
X.500 décrit un modèle dans lequel il est possible de distribuer un DIT en plusieurs DIBs.
Modèle DIT LDAP / X.500
Des parties du DIT (sous-arbres ou parties de sous-arbres) peuvent être stockées dans des DIBs différentes, chacune étant gérée par un DSA. Cela implique que chaque DIB ne contient que des morceaux d'arbres X.500, et doit être capable de fournir des informations permettant de joindre des parties non stockées du DIT.
Notons que ce modèle n'existe pas dans LDAP.
Voici un schéma montrant une possibilité de ditribution : |
 |
Le concept de 'Knowledge Information' entre DIB LDAP / X.500
Dans une DIB contenant un morceau du DIT, certaines entrées doivent être liées vers des entrées d'autres bases externes.
Globalement, un DSA gére deux types d'informations : - L'information de l'annuaire, c'est à dire l'ensemble des entrées de sa DIB.
- L'information de connaissance du contexte, ou "Knowledge Information", grâce à laquelle il est capable de connaître le contexte de nommage du DIT depuis la racine, et les liens vers les DSAs detenant les DIBs avec lesquelles il est lié.
Pour modéliser cela, il convient de stocker, dans les entrées feuille utilisées pour la jonction (vers un niveau inférieur ou supérieur de l'arbre), les réferences des DSAs maitrisant les informations à atteindre.
Interactions entre DSAs LDAP / X.500
Divers mécanismes d'intercations entre DSAs peuvent être mis en oeuvre pour automatiser l'accès aux données.
Accès aux informations des DSAs LDAP / X.500
(Normalisation 88 et 93, LDAP)
Globalement, il existe trois types d'accès possibles aux DSAs : - par référence,
- chaînage (X.500 uniquement),
- requête globale.
Dans la plupart des cas, il y a communication par DSP entre les DSAs.
Le scénario pour expliquer le fonctionnement de chaque mode est toujours le même. Un DUA veut accéder à des ressources et envoie sa requête vers un DSA qui ne possède pas les informations requises. Plusieurs scénarii peuvent alors se dérouler : |
.
Referal Mode Accès en mode par référence
|
Dans le mode par référence (Referal), le DSA, retourne au client (le DUA) l'identité du DSA détenant l'information demandée. Puis le DUA envoie sa requête vers le DSA ainsi désigné. Il peut aussi y avoir retour de réferences entre DSAs |
Chaining Mode Accès en mode par chaînage |
Dans le mode par chaînage (Chaining), le DSA s'adresse directement au DSA détenteur de l'information. Quand le second DSA a fini sont traitement, il renvoie la réponse au premier DSA qui, a son tour, la renvoie au DUA demandeur. Il n'existe pas de chaînage dans LDAP |
Multi-Casting Mode Accès en mode par requête globale |
Dans le mode par requête globale (multi-casting), le DSA émet des requêtes vers tous les DSA qu'il connaît, et attend leur réponse. Puis, il construit une réponse unique qu'il retourne alors au DUA. LDAP ne prévoit pas de multi-casting, bien que certains annuaires LDAP implémentent un mécanisme équivalent (backend meta dans OpenLDAP par exemple). |
Ces modes basiques de traîtement de requêtes peuvent inter-opérer entre eux, selon les besoins et la complexité de l'architecture (Ex : chaining vers un DSA, qui à son tour fait du multi-casting vers trois autres DSAs, etc ...).
Réplications d'informations entre DSAs LDAP / X.500
(Recommandation 88, Normalisation 93, LDAP)
Les données LDAP/X.500 sont à priori assez stables, et nécessitent peu de mises à jour. La recherche d'information distribuée sur plusieurs DSAs peut fortement diminuer les performances du système, car elle demande une utilisation intense d'interactions entre DSAs, ce qui est coûteux en temps ....
Pour éviter cela, la norme X.500 (norme 93 uniquement) et LDAPv3 décrit des mécanismes et protocoles utilisés pour répliquer des entrées entre arbres distants. Ce concept introduit la notion d'entrées de type "Maître", et d'entrées de type "Esclave".
Les entrées "Maître" sont celles qui detiennent l'information originelle, les entrées "Esclave" sont des copies d'entrées "Maître".
L'utilisation de la réplication de données demande le stockage de données supplémentaires au niveau des entrées (Identité du DSA maître indiquée dans l'entrée), ainsi que l'uitilisation de mécanismes de mise à jour régulière des données entre les arbres.
La sécurité dans un annuaire LDAP / X.500
Le modèle LDAP/X.500 décrit un modèle de sécurité, permettant de contrôler l'accès aux informations stockées dans les entrées, ainsi que l'accès général à l'annuaire.
Les droits d'accès (Authorization Policy)
(Recommandation 88, Normalisation 93, LDAP)
Ils permettent de protéger les données des entrées en spécifiant, pour chaque information (entrées, attributs, valeurs), les possibilités de chaque utilisateur (lectures, écritures, comparaison ou test, etc...).
Les droits sont décrits dans les entrées sous forme d'un attribut Access Control List (ACL). La description des droits utilise l'identité d'utilisateurs de l'annuaire, décrits dans des entrées de l'arbre.
L'utilisation des ACLs implique une politique d'administration des droits, ainsi que la présence de mécanismes d'authentification des utilisateurs lors de leur connection.
L'authentification (Authentication Policy) dans un annuaire LDAP / X.500
(Recommandation 88, Normalisation 93, LDAP)
La vérification des droits des utilisateurs passe par la vérification de leur identité, au moment de la connection à l'annuaire.
LDAP/X.500 décrit deux types de mécanismes d'authentification, lors de la création de session : - L'authentification simple, qui vérifie simplement le mot de passe de l'utilisateur (le mot de passe est stocké dans l'entrée décrivant l'utilisateur, avec l'attribut userPassword).
- L'authentification forte, qui en plus du mot de passe, utilise des mécanismes de tickets d'authentification et de cryptage.
Tout type d'entrée LDAP/X.500 peut désigner un compte utilisateur, ou un groupe d'utilisateur, du moment que ses classes permettent le stockage de l'attribut userPassword. Le mécanisme des droits permet aussi bien de protéger une partie d'une entrée, qu'un sous-arbre entier. Un entrée peut être protégee à l'aide de sa propre identité "utilisateur", si un mot de passe est présent.
En ce qui concerne l'intégrité des données (cryptage pour éviter le passage en clair sur le réseau, vérification de la cohérence par checksum et codes de correction d'erreur), le problème est abordé, mais pose des problèmes "politiques", le cryptage faisant l'objet d'une autorisation militaire ou gouvernementale, plus ou moins stricte selon le pays. |
|
A voir:
Notre démarche de mise en place des annuaires LDAP
Les offres logicielles LDAP
|
|
|
|
