IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Annuaires LDAP avec OpenLDAP

Annuaires LDAP avec OpenLDAP


précédentsommairesuivant

VII. Conception des schémas LDAP

Dans ce chapitre nous allons étudier comment écrire un schéma LDAP, c'est à dire comment créer de nouveaux objets et de nouveaux attributs lorsque cela est nécessaire. Nous commencerons par présenter le modèle des données de la norme LDAP.

VII-A. Modèle des données

Chaque entrée de l'annuaire est constituée d'un ensemble d'attributs, chaque attribut ayant une ou plusieurs valeurs.
Le schéma d'un annuaire définit l'ensemble des classes et attributs que celui-ci peut contenir. Chaque entrée de l'annuaire appartient à une ou plusieurs classes d'objet, et ne peut contenir que des attributs de cette classe.
Chaque classe d'objets est définie par une liste d'attributs - de propriétés - obligatoires et une liste d'attributs facultatifs. À chaque attribut sont associés notamment un nom et une syntaxe, mais aussi une description, et d'autres informations que nous allons étudier en détail.

VII-B. Les attributs

VII-B-1. Description des attributs

Un attribut est caractérisé par les informations suivantes :

  • Un nom : Un identifiant sous forme de chaîne de caractères. Les noms d'attributs sont toujours insensibles à la case. Un attribut peut avoir plusieurs noms. C'est le cas de l'attribut givenName qui s'appelle aussi gn.
  • Un Object Identifier (OID) : Un identifiant numérique. Voir la section dédiée.
  • Une description : La description d'un attribut fait partie du schéma à part entière.
  • Une syntaxe et des règles de comparaison : La syntaxe indiquera quel type d'information l'attribut peut contenir. Les règles de comparaison indiqueront comme effectuer des recherches sur les valeurs de l'attribut. La [rfc2252] fournit un ensemble de syntaxes et de règles de comparaison, que les serveurs LDAP doivent savoir gérer.
  • Sa valuation : S'il est mono ou multivalué
  • Un indicateur d'usage : Il existe quatre indicateurs d'usages possible (userApplication, directoryOperation, distributedOperation, dsaOperation). Les trois derniers types d'attributs sont dit Operational. Cela signifie qu'ils ne sont pas modifiables par l'utilisateur, ni accessibles, sauf certains qui peuvent être lus, comme par exemple modifytimestamp.
  • Un format ou une limite de taille
  • Il existe des relations d'héritage entre attributs. Lorsqu'on définit un attribut, il faut donc aussi définir l'attribut dont il descend, même si cela n'est pas obligatoire.

Ainsi les attributs sn (nom de famille), gn (prénom) dérivent de l'attribut name. L'aspect pratique de l'héritage entre attributs est qu'il est possible d'effectuer des recherches sur plusieurs attributs en même temps: En effectuant une recherche sur l'attribut name, on fera aussi une recherche sur ses sous-types.

VII-B-2. Exemples

VII-B-2-a. Exemples de syntaxes définies dans la [rfc2252]

OID Nom Description
1.3.6.1.4.1.1466.115.121.1.7 Boolean Booléen
1.3.6.1.4.1.1466.115.121.1.12 DN Un DN
1.3.6.1.4.1.1466.115.121.1.15 Directory String Une chaîne de caractères, encodée en UTF-8
1.3.6.1.4.1.1466.115.121.1.26 IA5String Une chaîne de caractères ASCII
1.3.6.1.4.1.1466.115.121.1.27 INTEGER Un entier

VII-B-3. Exemples et descriptions de règles de comparaison définies dans les [rfc2252]

OID Nom Description Syntaxe
2.5.13.0 objectIdentifierMatch Comparaison d'égalité entre deux OIDs. 1.3.6.1.4.1.1466.115.121.1.38
2.5.13.1 distinguishedNameMatch Comparaison d'égalité entre deux DN. 1.3.6.1.4.1.1466.115.121.1.12
2.5.13.2 caseIgnoreMatch Retourne vrai si les chaînes ont la même taille et sont identiques, à la case près. 1.3.6.1.4.1.1466.115.121.1.15
2.5.13.3 caseIgnoreOrderingMatch Règle d'inégalité, retourne vrai si la valeur de l'attribut comparé apparaît est avant la valeur passé en paramètre, une fois les deux chaînes convertis en majuscules. 1.3.6.1.4.1.1466.115.121.1.15
2.5.13.4 caseIgnoreSubstringsMatch Règle d'inclusion, insensible à la case, comme les deux règles précédentes. 1.3.6.1.4.1.1466.115.121.1.58
2.5.13.8 numericStringMatch Règle identique à la règle caseIgnoreMatch sauf que les espaces sont ignorés pendant la comparaison. 1.3.6.1.4.1.1466.115.121.1.36
2.5.13.10 numericStringSubstringsMatch Règle identique à la règle caseIgnoreSubstringsMatch sauf que les espaces sont ignorés pendant la comparaison. 1.3.6.1.4.1.1466.115.121.1.58
2.5.13.23 uniqueMemberMatch Retourne vrai si la valeur soumise et la valeur de l'attribut comparés sont des DN identiques; ou bien si le DN de l'attribut contient un composant uid, celui-ci peut être absent du DN de la valeur soumise, ou bien s'il est présent il doit être égal. 1.3.6.1.4.1.1466.115.121.1.34

VII-B-4. Exemples d'attributs définis dans la [rfc2256]

Nom Description
sn Nom de famille, dérive de l'attribut name
telephoneNumber Numéro de téléphone
member Membre d'un groupe. Cet atribut contient un DN, donc une référence vers un noeud de l'annuaire.

VII-C. Les classes

VII-C-1. Description

Chaque entrée de l'annuaire appartient à une ou plusieurs classes. Les classes modélisent ainsi les objets réels ou abstraits décrits dans un annuaire. Des exemples de classes sont : personne, bâtiment, application.

Une classe est constituée de :

  • Un nom : Un identifiant sous forme de chaîne de caractères. Exactement comme les noms de classes sont insensibles à la case. Une classe peut elle aussi avoir plusieurs noms.
  • Un Object Identifier (OID) : Un identifiant numérique. Voir la section dédiée.
  • Une description : La description de la classe fait partie du schéma.
  • Un type

Il existe trois type de classes :

  • Les classses structurelles : C'est une classe classique qui peut être instanciée.
  • Les classes auxiliaires : Ce sont des classes permettant de rajouter des informations complémentaire à des objets structurels. Des exemples de classes auxiliaires sont: mailRecipient, labelURIObject. Ces classes contiennent un ensemble d'attributs, généralement facultatifs. Les classes auxiliaires sont similaires aux interfaces en java.
  • Les classes abstraites : Les classes abstraites ne peuvent pas être instanciées, mais seulement dérivées.

Il n'est pas possible de faire de l'héritage multiple entre classes: une classe dérive toujours d'une seule classe. Néanmoins une entrée de l'annuaire peut être constituée de plusieurs classes, à condition qu'elle ne soit constituée que d'une seule classe structurelle, et de zéro, une ou plusieurs classes auxiliaires.

L'ensemble des classes d'objet forme une hiérarchie, dont la classe Top est au sommet.

VII-C-2. Exemples

Exemples d'objet standards issus de la [rfc2256] :

OID Nom Supérieur Type Attributs obligatoires Attributs facultatif Description
2.5.6.0 top Aucun ABSTRACT Aucun Aucun Classe parente de toutes les classes
2.5.6.6 person top STRUCTURAL sn, cn userPassword, telephoneNumber, seeAlso, descriptio Classe de base modélisant une personne
2.5.6.9 groupOfNames top STRUCTURAL member, cn businessCategory, seeAlso, owner, ou, o, description Groupes d'utilisateurs

VII-D. Présentation des OID

VII-D-1. Présentation des OID

Les OID sont des identifiants universels, représentés sous la forme d'une suite d'entiers. Ils sont organisés sous forme hiérarchique. Ainsi seul l'organisme 1.2.3 peut dire quel est la signification de l'OID 1.2.3.4. Ils ont été définis dans une recommandation de l'International Telecommunication Union. L'IETF a proposé de représenter la suite d'entiers constituant les OID séparés par des points.
L'objectif des OID est d'assure l'interopérabilité entre différents logiciels. Les OID sont utilisés dans le monde LDAP mais aussi dans d'autres domaines, comme par exemple les logiciels SNMP pour identifier des ressources. Il est possible d'obtenir un OID, et par conséquence toute une branche, auprès de l'IANA.
Dans le monde LDAP les objets, les attributs, les syntaxes et les règles de comparaison sont référencés par un objet OID. La [rfc2256] normalise un certain nombre de ces objets.

VII-D-2. Exemples

VII-D-2-a. Exemples d'OID

OID Description
0 branche de l'International Telecommunication Union
1 branche ISO
2 branche commune entre l'International Telecommunication Union et ISO
2.5 fait référence au service X500
2.5.4 définition des types d'attributs
2.5.6 définition des classes d'objets
1.3.6.1 the Internet OID
1.3.6.1.4.1 IANA-assigned company OIDs, used for private MIBs
1.3.6.1.4.1.4203 OpenLDAP
1.3.6.1.4.1.10650 Easter-eggs

Supposons qu'un organisme ait le OID 1.1. L'exemple suivant montre une façon d'ordonner les OID qu'il créera pour ses propres besoins

VII-D-2-b. Exemple de hiérarchie

OID Description
1.1 OID de l'organisme
1.1.1 Branches des identifiants SNMP
1.1.2 Branches des identifiants LDAP
1.1.2.1 Branches des attributs LDAP
1.1.2.1.1 Identifiant du premier attribut LDAP
1.1.2.2 Branche des classes d'objets LDAP
1.1.2.2.1 Identifiant du premier objet LDAP

VII-E. Syntaxe

VII-E-1. Syntaxe de la définition d'un attribut

 
Sélectionnez
  AttributeTypeDescription = "(" whsp
        numericoid whsp              ; AttributeType identifier
      [ "NAME" qdescrs ]             ; name used in AttributeType
      [ "DESC" qdstring ]            ; description
      [ "OBSOLETE" whsp ]
      [ "SUP" woid ]                 ; derived from this other
                                     ; AttributeType
      [ "EQUALITY" woid              ; Matching Rule name
      [ "ORDERING" woid              ; Matching Rule name
      [ "SUBSTR" woid ]              ; Matching Rule name
      [ "SYNTAX" whsp noidlen whsp ] ; 
      [ "SINGLE-VALUE" whsp ]        ; default multi-valued
      [ "COLLECTIVE" whsp ]          ; default not collective
      [ "NO-USER-MODIFICATION" whsp ]; default user modifiable
      [ "USAGE" whsp AttributeUsage ]; default userApplications
      whsp ")"

Cette syntaxe est extraite de la [rfc2252]. whsp est un blanc. Le nom de l'attribut doit être entre parenthèses et entre simples quotes. Des espaces sont obligatoires entre les parenthèses et le nom entre quote, et entre les différents noms, s'il y en a plusieurs. La syntaxe de la description est identique, excepté qu'il ne peut y avoir qu'une seule description.

woid signifie OID. noidlen signifie que la syntaxe d'un attribut est aussi un OID qui peut être complété par une taille maximale, contenue entre {}.

AttributeUsage est l'une des quatre valeurs présentée ci-dessus: userApplications directoryOperation distributedOperation dSAOperation.

La [rfc2252] permet à un attribut d'être collectif, c'est à dire partagé entre plusieurs entrées. C'est un héritage de la norme X500. Néanmoins la norme LDAP n'a pas fourni d'indication sur l'implémentation de ces attributs. Ils ne sont donc pas utilisés actuellement. Une RFC récente, de décembre 2003, fournit plus d'informations. Il s'agit de la [rfc3671].

Exemples de déclarations d'attributs :

 
Sélectionnez
attributetype ( 2.5.4.4 NAME ( 'sn' 'surname' )
	DESC 'RFC2256: last (family) name(s) for which the entity is known by'
	SUP name )
 
attributetype ( 2.5.4.20 NAME 'telephoneNumber'
	DESC 'RFC2256: Telephone Number'
	EQUALITY telephoneNumberMatch
	SUBSTR telephoneNumberSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.50{32} )
 
( 2.5.4.31 NAME 'member' SUP distinguishedName )

VII-E-2. Syntaxe de la définition d'un objet

 
Sélectionnez
  ObjectClassDescription = "(" whsp
      numericoid whsp      ; ObjectClass identifier
      [ "NAME" qdescrs ]
      [ "DESC" qdstring ]
      [ "OBSOLETE" whsp ]
      [ "SUP" oids ]       ; Superior ObjectClasses
      [ ( "ABSTRACT" / "STRUCTURAL" / "AUXILIARY" ) whsp ]
                           ; default structural
      [ "MUST" oids ]      ; AttributeTypes
      [ "MAY" oids ]       ; AttributeTypes
  whsp ")"

Cette déclaration de la syntaxe d'un objet est en tout point similaire à celle d'un attribut.

Exemples de déclarations d'attributs :

 
Sélectionnez
( 2.5.6.0 NAME 'top' ABSTRACT MUST objectClass )
 
( 2.5.6.3 NAME 'locality' SUP top STRUCTURAL
 MAY ( street $ seeAlso $ searchGuide $ st $ l $ description ) )
 
( 2.5.6.6 NAME 'person' SUP top STRUCTURAL MUST ( sn $ cn )
 MAY ( userPassword $ telephoneNumber $ seeAlso $ description ) )
 
( 2.5.6.9 NAME 'groupOfNames' SUP top STRUCTURAL MUST ( member $ cn )
 MAY ( businessCategory $ seeAlso $ owner $ ou $ o $ description ) )

VII-F. L'intérêt de créer ses propres schémas

Bien qu'il existe de nombreux objets et attributs normalisés, ceux-ci ne sont pas toujours adaptés au besoin d'une organisation. Généralement chaque organisation possède des informations à stocker dans l'annuaire qui lui sont spécifiques.
Sachant que les objets standards sont impossible à modifier, il reste la possibilité de créer ses propres attributs et ses propres objets. Cela nécessite la démarche administrative consistant à récupérer un identifiant auprès de l'IANA.


précédentsommairesuivant

Copyright (c) 2005, Michaël Parienti Maire. This work is licensed under the Creative Commons Attribution-Share Alike License. Modifications, reproductions, diffusions autorisées à condition de mentionner le nom de l'auteur original et de conserver les termes de cette licence Creative Commons.