accueilSystèmes et réseauxAnnuaires LDAP
 

Schéma Annuaire Référentiel


Présentation

Le schéma Référentiel est celui de l’annuaire sur lequel se base le fournisseur d’identités Janus.

Préambule

Inspiration

Ce schéma est fortement inspiré du Schéma CNRS 1.0 et des recommandations supann 2008

Partie pris de la langue

La langue de LDAP est l’anglais, les classes comme les attributs sont en anglais. Nous considérons que le mélange des langues, français et anglais, n’a pas de sens, aussi avons nous fait le choix d’utiliser un anglais compréhensible pour les noms des classes et des attributs.

Conventions

Attributs étiquetés

Cette convention est tirée des propositions supann pour des attributs portants des valeurs provenant potentiellement de plusieurs référentiels ou nomenclatures

Pour identifier le référentiel de provenance, les attributs utilisant ces référentiels DOIVENT faire précéder la valeur de l’attribut par une étiquette. Le format de ces attributs est le suivant :

{<provenance>}<valeur>

Par exemple

{LABINTEL}1245678

{SIRHUS}DEFFRTYH

Attribut à sémantique variable

Certaines valeurs d’attribut se comprennent dans une sémantique variable. Par exemple, (cas parfaitement idiot), imaginons un attribut plat préféré platPréféré.

Le plat préféré peut dépendre du contexte. Le plat n’est pas le même au petit déjeuner qu’au souper. Le contexte est nécessaire à la compréhension de la valeur.

Nous prendrons la convention

sémantique=valeur

Par exemple

platPréféré: petitDéjeuner=café
platPréféré: souper=soupe à la tomate

Notons que nous pouvons généraliser cette convention à toute affectation d’une valeur à une variable

variable=valeur

Par exemple le fait d’écrire

unite=UMR1234

signifie que la valeur UMR1234 est affecté à la variable unité

Attributs composites

Cette convention est tirée des propositions supann pour des attributs regroupant des valeurs d’attributs élémentaires, dont l’association a un sens.

[etiq1=valeur1][etiq2=valeur2][etiq3=valeur3]...

Par exemple

departmentnumber: [unite=UMR1234][institut=DS12][dr=DR13]

Elle est évidemment lié à la convention sur les attributs à sémantique variable

Attributs clef/libellé

Un certain nombre d’attribut ont une valeur clef, utilisée par les applications, et un libellé, visible par les humains. Par exemple

clef F4E04
libellé Technicien d'exploitation et de fabrication

Pour conserver les deux il faut décider d’une convention

nous avions

clef=libellé

Mais il y a un risque de confusion avec la convention des attributs composites.

Il pourrait être préférable de choisir une syntaxe à la C++

clef->valeur

Par exemple

F4E04->Technicien d'exploitation et de fabrication

Cela permettrait de mélanger les syntaxe sans confusion de sens, par exemple

[grade={CNRS}IE2->Ingénieur d'études seconde classe]
[identifiant={UNIVERSITE}DF154F]

Propriétés générales des attributs

Sauf contre indication, les propriétés des attributs spécifiques sont :

  • Egalité : caseIgnoreMatch
  • Règle de mise en correspondance sous-chaine : caseIgnoreSubstringsMatch
  • Syntaxe : 1.3.6.1.4.1.1466.115.121.1.15

Regexp pour l’utilisation du formalisme

Object Identifier

Branches IANA

Le schéma LDAP du CNRS est associé à un domaine OID enregistrée auprès de l’IANA.

Le numéro OID déposé pour le CNRS est 1.3.6.1.4.1.10813
La branche réservée à la PKI est 1.3.6.1.4.1.10813.1
La branche schéma CNRS 1.3.6.1.4.1.10813.2
La branche schéma CNRS 1.3.6.1.4.1.10813.3
Sous-branches
Classe 1.3.6.1.4.1.10813.3.1
Attribut 1.3.6.1.4.1.10813.3.2
Branche objets ad-hoc 1.3.6.1.4.1.10813.2.9

Construction de l’OID CNRS

L’OID est construit selon le modèle

$OID = "$branch.$i.$s.$v"

  • branch est l’identifiant de la branche de l’objet désigné (attribut, classe, ...)
  • i indice d’identification croissant (i=1,2,...)
  • s est spécialisation de la définition, dénotant une filiation directe (valeur par défaut 0)
  • v la version de la définition (valeur par défaut 0)
La branche schéma Référentiel 1.3.6.1.4.1.10813.3
Sous-branches
Classe 1.3.6.1.4.1.10813.3.1.i.0.0
Attribut 1.3.6.1.4.1.10813.3.2.i.0.0
Branche objets ad-hoc 1.3.6.1.4.1.10813.3.9.i.0.0

Les classes et attributs spécifiques au schéma référentiel seront préfixés par ref


Schéma

ObjectClass

refUser

La classe refUser représentant un utilisateur au sens du référentiel, c’est à dire un couple (personne physique, affectation) Elle permet de définir (identifier) une personne sur les plans :

  • organisationnels (délégation, département, unité),
  • professionnels (grade,fonction),
  • géographique (ville, rue, adresse),
  • S.I. (identifiant unique, mail, mot de passe).

Pour plus de détail voir RefUser - Annuaire Référentiel

  • OID : 1.3.6.1.4.1.10813.2.3.1.0.0
  • Classes supérieures
    • inetOrgPerson
  • Type : structurel
  • Attributs obligatoires
    • uid
  • Attributs optionnels
    • refRegionalOffice
    • refScientificOffice
    • refScientificPosition
    • refNature
    • refGrade
    • refRole
    • refAccess
    • refID
    • refUniqueID

Syntaxe LDIF

objectclasses : (  1.3.6.1.4.1.10813.2.3.1.0.0
NAME ’refUser’
DESC ’Utilisateur dans le sens personne affectée à une unité’
SUP ’inetOrgPerson’ 
STRUCTURAL 
MUST (  uid ) 
MAY ( refRegionalOffice $ refScientificOffice 
$ refScientificPosition  $ refNature $ refGrade 
$ refRole $ refAccess $ refID $ refUniqueID) 

refSystemInfo

Classe servant à créer des informations au niveau système utiles à des processus automatiques de gestion des annuaires.

  • OID : 1.3.6.1.4.1.10813.3.2.4.0.0
  • Classes supérieures
    • top
  • Type : auxilliaire
  • Attributs optionnels
    • refSystemFlag
    • refPointTo
    • refUnauthenticable

Attributs

refRegionalOffice

Entité régionale de rattachement de l’entité (personne, unité, groupe, ...).

Typiquement pour le CNRS la délégation régionale

  • OID : 1.3.6.1.4.1.10813.3.2.1.0.0

Exemple de valeur

refRegionalOffice: DR05->Ile-de-France Ouest et Nord

refScientificOffice

Entité scientifique de rattachement l’entité (personne, unité, groupe, ...).

Typiquement pour le CNRS le département scientifique

  • OID : 1.3.6.1.4.1.10813.3.2.2.0.0

Exemple de valeur

refScientificOffice: DS97->Moyens communs

refScientificPosition

Position scientifique, typiquement les sections du comité national associées à l’entité (personne, unité, groupe, ...).

Cet attribut n’est pas utilisé actuellement dans l’annuaire central où il est nommé cnrsSection

  • OID : 1.3.6.1.4.1.10813.3.2.3.0.0

refNature

Attribut détaillant la nature de l’entitée

  • OID : 1.3.6.1.4.1.10813.3.2.4.0.0

Cf RefUser - Annuaire Référentiel#refNature refGrade

Grade de la personne selon la nomenclature CNRS.

Correspond à la table Labintel gra.

  • OID : 1.3.6.1.4.1.10813.3.2.5.0.0

refRole

Attribut permettant d’associer un rôle à une entité. Il permettrait dans l’hypothèse où une topologie des rôles ainsi qu’une ou plusieurs applications de référence seraient établies et reconnues d’associé clairement des rôles multiples à des personnes.

A l’heure actuelle, seul celui de directeur d’unité est reconnu.

Il s’écrit sous la forme sous le formalisme d’attribut à sémantique variable

DU=code de l'unité

Par exemple

DU=UPS837

Mais nous pourrons en ajouter un certains nombre ainsi par exemple

refRole: DU=UMR1234
refRole: ACMO=UMR0001
refRole: gestionnaire BFC=UMR1234
refRole: gestionnaire RH=UMR1234
refRole: gestionnaire demande de moyen=UMR1234
  • OID : 1.3.6.1.4.1.10813.3.2.6.0.0

refAccess

Attribut permettant d’associer un accès à une entité en dehors de ses rôles et de ses propriétés propres

  • OID : 1.3.6.1.4.1.10813.3.2.7.0.0

Il s’écrit sous la forme sous le formalisme #Attribut à sémantique variable

refAccess: BFC=ECC
refAccess: BFC=BW
refAccess: IHMLDAP=UMR1243
refAccess: IHMLDAP=DR05

Il faudra veiller à ne pas confondre refRole et refAccess !

  • refRole est une vision métier
  • refAccess est une vision applicative

refID

refID est un attribut permettant d’identifier une entrée dans l’annuaire par rapport à des référentiels extérieurs

Par exemple, il est tout à fait possible d’identifier une personne par rapport à Labintel et Sirhus en utilisant la convention #Attribut à sémantique variable

refID: labintel=124567
refID: sirhus=AZE45ER
refID: nabucco=124567
  • OID : 1.3.6.1.4.1.10813.3.2.8.0.0

refGlobalID

NOTE IMPORTANTE : Cette fonctionnalité n’est pas implémentée et est restée à l’état d’étude

refGlobalID est un identifiant opaque construit à partir d’informations confidentiels et discriminantes afin d’identifier au plus juste les personnes malgré l’absence d’unicité des sources d’informations et les possibilité de doublons multiple. L’encodage fait à partir de ces informations ne doit pas être réversible.

  • OID : 1.3.6.1.4.1.10813.3.2.9.0.0

refSystemFlag

Attribut servant à maintenir tout type d’information ad-hoc nécessaire au fonctionnement de l’annuaire et des outils associés

  • OID : 1.3.6.1.4.1.10813.3.2.10.0.0

refPointTo

Cet attribut joue le rôle de pointeur LDAP. Il peut servir à tenir à jour des références entre entrées. Il n’est pas vraiment utilisé.

  • OID : 1.3.6.1.4.1.10813.3.2.11.0.0
  • Règle d’égalité : distinguishedNameMatch
  • Syntaxe : 1.3.6.1.4.1.1466.115.121.1.12

refUnauthenticable

Cet attribut permet de qualifier une entrée comme valide ou non pour une opération d’authentification. Par défaut cet attribut n’est pas renseigné ou est à FALSE

  • OID : 1.3.6.1.4.1.10813.3.2.12.0.0
  • syntaxe : 1.3.6.1.4.1.1466.115.121.1.7 booléen
  • matching : booleanMatch

refLogin

Cet attribut correspond aux identifiants de l’utilisateur.

  • OID : 1.3.6.1.4.1.10813.3.2.13.0.0

Le formalisme sera celui des #Attributs étiquetés

reflogin: {sap}username=_jgab


Principes de construction de l’identifiant
  • Générer un bi-clé asymétrique de type RSA
  • Mettre la clef privée sous séquestre ou la détruire
  • Protéger la clef publique et restreindre sa diffusion
  • Définir un algorithme qui va chiffrer une chaîne basée sur l’ensemble d’informations discriminant l’utilisateur tel que nous le définissons (nom, prénom, date de naissance, lieu de naissance, …)
  • Fournir l’algorithme d’un côté, la clef de l’autre aux applications autorisées
  • A chaque création d’une personne, générer cet identifiant avec l’algorithme

Ces informations sont à priori

  • nom
  • prénom
  • date de naissance
  • lieu de naissance
  • pays de naissance

Mais ces informations ne sont pas toujours disponibles, aussi faudra-t-il trouver au moins deux ensembles

  • ensemble complet
  • ensemble partiel

L’ensemble partiel se limitant à

  • nom
  • prénom
  • date de naissance

Nous distinguerons les deux valeurs par

  • 1 pour l’ensemble complet
  • 2 pour l’ensemble partiel
refGlobalID: {1}erGhtRfdSShGFFDDKhhGFfdDdHgFDDFDgGFDDDDDFDERSSZEXCVNHFEF==
refGlobalID: {2}erGhtRfdSS3DDCGGHJHFJQF74GQGSDHILJSFfghjzjhqQGqfgsdfgsfg==


ARESU
Direction des Systèmes d'Information du CNRS

358 rue P.-G. de Gennes
31676 LABEGE Cedex

Bâtiment 1,
1 Place Aristide Briand
92195 MEUDON Cedex



 

 

Direction des Systèmes d'Information

Pôle ARESU

Accueil Imprimer Plan du site Credits