Compréhension des composants du protocole LDAP, de la hiérarchie des données et de l’entrée

Les données elles-mêmes dans un système LDAP sont principalement stockées dans des éléments appelésattributes. Les attributs sont essentiellement des paires clé-valeur. Contrairement à d’autres systèmes, les clés ont des noms prédéfinis qui sont dictés par les objectClasses sélectionnées pour l’entrée (nous en discuterons dans un instant). De plus, les données d’un attribut doivent correspondre au type défini dans la définition initiale de cet attribut.

La définition de la valeur d'un attribut est effectuée avec le nom de l'attribut et la valeur de l'attribut séparés par un signe deux-points et un espace. Un exemple d'attribut appelémail, qui définit une adresse e-mail, ressemblerait à ceci:

Lorsque vous faites référence à un attribut et à ses données (lorsque vous ne le définissez pas), les deux côtés sont reliés par un signe égal:

Les valeurs d'attribut contiennent la plupart des données réelles que vous souhaitez stocker et auxquelles accéder dans un système LDAP. Les autres éléments de LDAP sont utilisés pour la structure, l’organisation, etc.

Les attributs en eux-mêmes ne sont pas très utiles. Pour avoir un sens, ils doivent êtreassociated avec quelque chose. Dans LDAP, vous utilisez des attributs dans unentry. Une entrée est fondamentalement une collection d'attributs sous un nom utilisé pour décrire quelque chose.

Par exemple, vous pouvez avoir une entrée pour un utilisateur de votre système ou pour chaque article d'un inventaire. Ceci est à peu près analogue à une ligne dans un système de base de données relationnelle ou à une page unique dans un carnet d'adresses (les attributs ici représenteraient les différents champs de chacun de ces modèles). Tandis qu'un attribut définit une qualité ou une caractéristique de quelque chose, une entrée décrit l'élément lui-même en rassemblant simplement ces attributs sous un nom.

Un exemple d’entrée tel qu’affiché dans le format LDIF (LDAP Data Interchange Format) ressemblerait à ceci:

L'exemple ci-dessus pourrait être une entrée valide dans un système LDAP.

Lorsque vous commencez à vous familiariser avec LDAP, il est facile de reconnaître que les données définies par des attributs ne représentent qu’une partie des informations disponibles sur un objet. Le reste correspond à l'emplacement de l'entrée dans le système LDAP et aux relations que cela implique.

Par exemple, s'il est possible d'avoir des entrées pour un utilisateur et un article d'inventaire, comment quelqu'un pourrait-il les différencier? Une façon de distinguer les entrées de types différents consiste à établir des relations et des groupes. Cela dépend en grande partie de l'endroit où l'entrée est placée lors de sa création. Les entrées sont toutes ajoutées à un système LDAP sous forme de branches sur des arbres appelésData Information Trees ouDITs.

Un fichier DIT représente une structure organisationnelle similaire à un système de fichiers où chaque entrée (autre que l'entrée de niveau supérieur) a exactement une entrée parent et peut contenir un nombre quelconque d'entrées enfants. Étant donné que les entrées dans une arborescence LDAP peuvent représenter à peu près tout, certaines entrées seront principalement utilisées à des fins d'organisation, similaires aux répertoires d'un système de fichiers.

De cette façon, vous pouvez avoir une entrée pour «personnes» et une entrée pour «articles d'inventaire». Vos entrées de données réelles peuvent être créées en tant qu'enfants de ces dernières pour mieux distinguer leur type. Les entrées de votre organisation peuvent être définies de manière arbitraire pour mieux représenter vos données.

Dans l'exemple d'entrée de la dernière section, nous voyons une indication du DIT dans la lignedn:

Cette ligne est appelée le nom distinctif de l’entrée (vous en saurez plus plus tard) et sert à identifier l’entrée. Cela fonctionne comme un chemin complet vers la racine du DIT. Dans ce cas, nous avons une entrée appeléesn=Ellingwood, que nous créons. Le parent direct est une entrée appeléeou=people qui est probablement utilisée comme conteneur pour les entrées décrivant des personnes. Les parents de cette entrée dérivent du nom de domainedigitalocean.com, qui fonctionne comme la racine de notre DIT.

Les attributs sont définis en utilisant une syntaxe assez impliquée. Ils doivent indiquer le nom d'un attribut, tout autre nom pouvant être utilisé pour faire référence à cet attribut, le type des données pouvant être entrées ainsi qu'une variété d'autres métadonnées. Ces métadonnées peuvent décrire l’attribut, indiquer à LDAP comment trier ou comparer la valeur de cet attribut, ainsi que son lien avec d’autres attributs.

Par exemple, voici la définition de l'attributname:

Le'name' est le nom de l'attribut. Le numéro de la première ligne est un OID globalement unique (ID d'objet) attribué à l'attribut pour le différencier de tous les autres attributs. Le reste de l'entrée définit le mode de comparaison de l'entrée lors des recherches et comporte un pointeur indiquant où trouver des informations sur les exigences de type de données de l'attribut.

Une partie importante de la définition d’un attribut consiste à savoir si l’attribut peut être défini plusieurs fois dans une entrée. Par exemple, la définition peut définir qu'un nom de famille ne peut être défini qu'une fois par entrée, mais un attribut pour «nièce» peut permettre à cet attribut d'être défini plusieurs fois dans une seule entrée. Les attributs sont à valeurs multiples par défaut et doivent contenir l'indicateurSINGLE-VALUE s'ils ne peuvent être définis qu'une seule fois par entrée.

Les définitions d'attributs sont beaucoup plus compliquées que l'utilisation et la définition d'attributs. Heureusement, dans la plupart des cas, vous n'aurez pas à définir vos propres attributs, car la plupart des implémentations sont incluses dans la plupart des implémentations LDAP et d'autres peuvent être importées facilement.

Les attributs sont collectés dans des entités appeléesobjectClasses. Les classes d'objet sont simplement des groupements d'attributs associés qui seraient utiles pour décrire un élément spécifique. Par exemple, «personne» est une classe d'objet.

Les entrées ont la possibilité d’utiliser les attributs d’une classe d’objets en définissant un attribut spécial appeléobjectClass, en nommant l’objetClasse que vous souhaitez utiliser. En fait,objectClass est le seul attribut que vous pouvez définir dans une entrée sans spécifier d'autre objectClass.

Donc, si vous créez une entrée pour décrire une personne, y comprisobjectClass person (ou l'une des objectClasses de personne plus spécifiques dérivée de personne - nous aborderons cela plus tard) vous permet d'utiliser tous les attributs de cette objectClass:

Vous auriez alors la possibilité de définir ces attributs dans l'entrée:

L'attributobjectClass peut être utilisé plusieurs fois si vous avez besoin d'attributs de différentes classes d'objet, mais il existe des règles qui dictent ce qui est acceptable. Les classes d'objet sont définies comme l'un des «types».

Les deux principaux types d'ObjectClasses sontstructural ouauxiliary. Une entréemust a exactement une classe structurelle, mais peut avoir zéro ou plusieurs classes auxiliaires utilisées pour augmenter les attributs disponibles pour la classe. Une classe d'objet structurelle est utilisée pour créer et définir l'entrée, tandis que les classes d'objet auxiliaires ajoutent des fonctionnalités supplémentaires via des attributs supplémentaires.

Les définitions d'ObjectClass déterminent si les attributs qu'elles fournissent sont obligatoires (indiqués par une spécificationMUST) ou facultatifs (indiqués par une spécificationMAY). Plusieurs objectClasses peuvent fournir les mêmes attributs et la catégorisationMAY ouMUST d'un attribut peut varier d'une objectClass à une objectClass.

À titre d'exemple, la classe d'objetperson est définie comme ceci:

Ceci est défini comme un objectClass structural, ce qui signifie qu'il peut être utilisé pour créer une entrée. L'entrée crééemust définit les attributssurname etcommonname, et peut choisir de définir lesuserPassword,telephoneNumber,seeAlso oudescription attributs.

Les définitions d'ObjectClass et les définitions d'attribut sont, à leur tour, regroupées dans une construction connue sous le nom deschema. Contrairement aux bases de données relationnelles traditionnelles, les schémas de LDAP sont simplement des collections d’objectClasses et d’attributs associés. Un même DIT peut avoir de nombreux schémas différents pour pouvoir créer les entrées et les attributs nécessaires.

Les schémas incluent souvent des définitions d'attributs supplémentaires et peuvent nécessiter les attributs définis dans d'autres schémas. Par exemple, la classe d'objetperson dont nous avons discuté ci-dessus nécessite que l'attributsurname ousn soit défini pour toutes les entrées utilisant la classe d'objetperson. Si elles ne sont pas définies dans le serveur LDAP lui-même, un schéma contenant ces définitions peut être utilisé pour ajouter ces définitions au vocabulaire du serveur.

Le format d'un schéma est fondamentalement juste une combinaison des entrées ci-dessus, comme ceci:

Un DIT est simplement la hiérarchie décrivant la relation des entrées existantes. Lors de la création, chaque nouvelle entrée doit «s'accrocher» au DIT existant en se plaçant elle-même en tant qu'enfant d'une entrée existante. Cela crée une structure arborescente utilisée pour définir les relations et attribuer une signification.

Le sommet du DIT est la plus large catégorisation dans laquelle chaque nœud suivant est en quelque sorte descendant. En général, l'entrée la plus haute est simplement utilisée comme une étiquette indiquant l'organisation pour laquelle le DIT est utilisé. Ces entrées peuvent être de n'importe quelle classe d'objet souhaitée, mais elles sont généralement construites à l'aide de composants de domaine (dc=example,dc=com pour une information de gestion LDAP associée àexample.com), d'emplacements (l=new_york,c=us pour une organisation ou un segment dans NY) ou des segments organisationnels (ou=marketing,o=Example_Co).

Les entrées utilisées pour l'organisation (utilisées comme des dossiers) utilisent souvent l'objet OrganizationUnit objectClass, qui permet l'utilisation d'une simple étiquette d'attribut descriptif appeléeou=. Ceux-ci sont souvent utilisés pour les catégories générales sous l'entrée DIT de niveau supérieur (des éléments tels queou=people,ou=groups etou=inventory sont courants). LDAP est optimisé pour rechercher des informations latéralement le long de l’arbre plutôt que de haut en bas dans l’arbre. Il est donc souvent préférable de garder la hiérarchie DIT plutôt superficielle, avec des branches organisationnelles générales et une subdivision supplémentaire indiquée par l’attribution d’attributs spécifiques.

Nous nous référons aux entrées par leurs attributs. Cela signifie que chaque entrée doit avoir un attribut ou un groupe d'attributs sans ambiguïté à son niveau dans la hiérarchie DIT. Cet attribut ou groupe d’attributs est appelérelative distinguished name ouRDN de l’entrée et fonctionne comme un nom de fichier.

Pour faire référence à une entrée sans ambiguïté, vous utilisez le RDN de l’entrée combiné à tous les RDN de ses entrées parent. Cette chaîne de noms RDN permet de remonter au sommet de la hiérarchie DIT et fournit un chemin non ambigu vers l’entrée en question. Nous appelons cette chaîne de RDN lesdistinguished name ouDN de l’entrée. Vous devez spécifier le DN pour une entrée lors de la création afin que le système LDAP sache où placer la nouvelle entrée et s’assure que le RDN de l’entrée n’est pas déjà utilisé par une autre entrée.

Par analogie, vous pouvez considérer un RDN comme un nom de fichier ou de répertoire relatif, comme dans un système de fichiers. Le DN, en revanche, est plus analogue au chemin absolu. Une distinction importante est que les DN LDAP contiennent la valeur la plus spécifique du côtéleft-hand, tandis que les chemins de fichiers contiennent les informations les plus spécifiques du côtéright-hand. Les DN séparent les valeurs RDN par une virgule.

Par exemple, une entrée pour une personne nommée John Smith peut être placée sous une entrée «Personnes» pour une organisation sousexample.com. Étant donné qu’il peut y avoir plusieurs John Smith dans l’organisation, un ID utilisateur peut constituer un meilleur choix pour le RDN de l’entrée. L'entrée pourrait être spécifiée comme ceci:

Nous avons dû utiliser la classe d'objetinetOrgPerson pour accéder à l'attributuid dans cette instance (nous avons toujours accès à tous les attributs définis dans la classe objectClass deperson, comme nous le verrons dans le section suivante).

ObjectClass est une classe qui décrit les caractéristiques des objets de ce type.

Cependant, contrairement à l'héritage simple, les objets dans LDAP peuvent être et sont souvent des instances de plusieurs classes (certains langages de programmation fournissent des fonctionnalités similaires via l'héritage multiple). Ceci est possible car la conception d’une classe par LDAP est simplement une collection d’attributs qu’elle DOIT ou PEUT avoir. Cela permet de spécifier plusieurs classes pour une entrée (bien qu'une seule objectClass deSTRUCTURAL puisse et doive être présente), ce qui fait que l'objet a simplement accès à la collection fusionnée d'attributs avec la déclaration MUST ou MAY la plus stricte qui prévaut.

Dans sa définition, objectClass peut identifier un objectClass parent à partir duquel hériter de ses attributs. Cela se fait en utilisantSUP suivi de l'objet ObjectClass dont hériter. Par exemple, la classe objectClass deorganizationalPersoncommence comme ceci:

L'objetClass qui suit l'identifiantSUP est le parent objectClass. Le parent doit partager le type objectClass de l'objet ObjectClass en cours de définition (par exempleSTRUCTURAL ouAUXILIARY). L'objet objectClass enfant hérite automatiquement des attributs et des exigences d'attribut du parent.

Lorsque vous affectez une classe objectClass à une entrée, il vous suffit de spécifier le descendant le plus spécifique d'une chaîne d'héritage pour avoir accès aux attributs à la hausse. Dans la dernière section, nous l'avons utilisé pour spécifierinetOrgPerson comme unique objectClass pour notre entrée John Smith tout en ayant toujours accès aux attributs définis dans les objectClassesperson etorganizationalPerson. La hiérarchie d'héritage deinetOrgPerson ressemble à ceci:

Presque toutes les arborescences d'héritage objectClass se terminent par une objectClass spéciale appelée «top». Il s'agit d'une classe abstraite objectClass dont le seul but est d'exiger que objectClass soit lui-même défini. Il est utilisé pour indiquer le sommet de la chaîne d'héritage.

De la même manière, les attributs eux-mêmes peuvent lister un attribut parent lors de leur définition. L'attribut héritera ensuite des propriétés définies dans l'attribut parent.

Ceci est souvent utilisé pour créer des versions plus spécifiques d'un attribut général. Par exemple, un nom de famille est un type de nom et peut utiliser toutes les mêmes méthodes pour comparer et vérifier l’égalité. Il peut hériter de ces qualités pour obtenir la forme générale d'un attribut «nom». En fait, la définition réelle du nom de famille peut contenir un peu plus qu'un pointeur sur l'attribut parent.

Ceci est utile car il permet la création d'un attribut spécifique, utile pour les personnes interprétant l'élément, même lorsque sa forme générale reste inchangée. L'héritage de l'attributsurname dont nous avons discuté ici aide les gens à faire la distinction entre un nom de famille et un nom plus général, mais à part la signification de la valeur, il y a peu de différence entre un nom et un nom dans le système LDAP.