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

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 possibles (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 OID.

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ée en paramètre, une fois les deux chaînes converties 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é 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 attribut contient un DN, donc une référence vers un nœud 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 types de classes :

  • Les classes structurelles : C'est une classe classique qui peut être instanciée.
  • Les classes auxiliaires : Ce sont des classes permettant de rajouter des informations complémentaires à 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 facultatifs

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 quelle 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'assurer l'interopérabilité entre différents logiciels. Les OID sont utilisés dans le monde LDAP, mais aussi dans d'autres domaines, par exemple les logiciels SNMP pour identifier des ressources. Il est possible d'obtenir un OID, et par conséquent 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 quotes, 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ées 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.