Schéma enrichi

Ce document décrit l’ensemble des informations nécessaires aux systèmes de création d’entrée, de consultation et de mise à jour.

Objectifs

Les différents services de l’annuaire ont besoins d’informations sur les attributs :

  • pour connaître les conditions d’utilisation des attributs dans différents contextes : attribut obligatoire ou non, modifiable ou non, etc...
  • pour pouvoir présenter les attributs aux utilisateurs : libellés divers associés à chaque attribut ; besoin de consultation (sélection de population) et mise à jour.
  • pour pouvoir donner des valeurs par défaut en création d’attribut (besoin de mise à jour)
  • pour savoir s’il faut faire une double saisie de certains attributs (besoin de mise à jour)
  • pour savoir s’il faut envoyer un message d’alerte avant saisie (besoin de mise à jour)
  • pour savoir s’il faut faire un prétraitement de mise en forme avant affichage
  • pour savoir si un attribut doit rester caché à l’utilisateur (besoin de consultation et mise à jour, Arbres & Groupes)
  • pour savoir s’il faut faire un post-traitement après saisie (mise en forme, contrôle d’unicité). Par exemple pour l’adresse de messagerie officielle. (pour les identifiants des personnes et les RDN générés (entrées « ou » et « cn »), décision de faire la génération dans couches supérieures : mise à jour et migration)
  • pour pouvoir limiter la valeur d’un attribut à une liste définie de valeurs ; besoin de choix de critères de consultation (sélection de population), besoin de mise à jour.
  • pour déduire de ces différentes informations les héritages entre les attributs de classes d’objets différentes lors de la création de nouvelles entrées (besoin de Arbres & Groupes)
  • pour contrôler la visibilité des attributs en fonction de l’acteur, de façon à ne lui présenter que les attributs sur lesquels il pourra filtrer, consulter (sélection de population) ou saisir (mise à jour)
  • pour savoir si un attribut doit être proposé en saisie à la création d’une entrée (besoin de mise à jour et Arbres & Groupes)

Rappels

Comme l’étude détaillée « arbres et groupes » le précise, l’utilisation du schéma interne à ldap ne peut pas répondre à l’ensemble de ces besoins. Il faut donc introduire le schéma enrichi dans l’annuaire lui-même.

A titre de rappel, les raisons et les explications de l’utilisation d’AACLs sur le schéma enrichi se trouve dans le document décrivant les AACLs dans la section « Justification de l’utilisation d’AACLs sur le schéma enrichi » ; pour plus de commodité, elles sont reproduites ci-dessous dans la partie « confidentialité » en fin de document.

Définitions

Parmi les listes de valeurs il faut distinguer deux familles.

Les listes de valeurs induites : les valeurs contenues ne servent qu’en lecture (sélection de population) ; elles peuvent être déduites du contenu « lié » de l’annuaire, fourni par les migrations d’importation à partir de sources externes.

Ces listes de valeurs devront être tenues à jour à chaque importation (migration). Nous avons alors intérêt à en faire une par attribut de type « pris dans liste » et par classe d’objet de « bas » niveau de manière à présenter des choix les plus proches de la population existant réellement dans l’annuaire. (TODO voir chapitre spécial « liste de valeurs » dans Consultation et Mise à Jour)

Les listes de valeurs générales : les valeurs contenues sont communes aux différentes classes d’objet pour un même attribut. Attribut pouvant être saisi, et non pas seulement consulté, choisi dans une liste exhaustive. (TODO voir chapitre spécial « liste de valeurs » dans Consultation et Mise à Jour)

Un cas particulier : la catégorie de personne (employeeType)

La catégorie de personne ne doit pas avoir de liste de valeur au niveau général (TODO voir chapitre spécial « liste de valeurs » dans Consultation et Mise à Jour)

D’autre part, à cause de la possibilité de saisie directe de personne dans l’annuaire, la liste de valeur associée à chaque employeeType dans chaque sous-classe doit être exhaustive (doit refléter toute la nomenclature déduite d’HARPEGE) (TODO voir chapitre spécial « liste de valeurs » dans Consultation et Mise à Jour)

Le Schéma enrichi

Arbres

  • arbre Systeme : nœud origine : ou = Systeme, dc = upmc, dc = fr
  • nœud schema : ou = schema, ou = Systeme, dc= upmc, dc = fr
  • un nœud par classe d’objets : ou = , ou = schema, ou = Systeme, dc = upmc, dc = fr (nom classe = même nom que dans le schéma ldap)
  • un nœud par attribut : cn = , ou = , ou = schema, ou = Systeme, dc = upmc, dc = fr (nom attribut = même nom que dans le schéma ldap)

Contenu du « Schéma » enrichi

Classes
  • ou = Nom de la classe
  • OID de la classe (mono-valué/obligatoire)
  • Libellé pour affichage détaillé (mono-valué/obligatoire)
  • Libellé pour affichage dense (mono-valué/obligatoire)
  • Libellé pour impression (mono-valué/obligatoire)
  • Indicateur « filtrable » ou non de la classe (mono-valué/booléen/obligatoire)
  • Description exhaustive (dictionnaire de données) (mono-valué/optionnel)
  • Classes parentes (multi-valué/optionnel) (heriteDe)
Attributs
  • cn = Nom de l’attribut
  • OID de l’attribut (mono-valué/obligatoire)
  • Indicateur « multi-valué » ou non de l’attribut (mono-valué/booléen/obligatoire)
  • Indicateur « obligatoire » ou non de l’attribut ((mono-valué/booléen/obligatoire)
  • Indicateur « modifiable » ou non de l’attribut (mono-valué/booléen/obligatoire)
  • Indicateur « filtrable » ou non de l’attribut (mono-valué/booléen/obligatoire)
  • Indicateur « visible » ou non de l’attribut (mono-valué/booléen/obligatoire)
  • Indicateur « proposé en création » ou non de l’attribut (mono-valué/booléen/ optionnel)
  • Indicateur « pris dans liste » ou non de l’attribut (mono-valué/booléen/obligatoire)
  • Indicateur « double validation » ou non de l’attribut (mono-valué/booléen/obligatoire)
  • Valeur par défaut de l’attribut (mono-valué/optionnel)
  • Fonction de prétraitement (mono-valué/optionel)
  • Fonction de post-traitement (mono-valué/optionel)
  • Confidentialité de l’attribut (multi-valué/optionel) (en rapport avec la branche ou=Confidentialites,ou=Systeme
  • Libellé pour affichage détaillé (mono-valué/obligatoire)
  • Libellé pour affichage dense (mono-valué/obligatoire)
  • Libellé pour impression (mono-valué/obligatoire)
  • Message d’alerte (mono-valué/optionnel)
  • Bulle d’aide contextuelle de consultation (mono-valuée, optionnelle) (bulle d’aide sur le bouton « ? »
  • Bulle d’aide contextuelle de modification (mono-valuée, optionnelle) (bulle d’aide sur le bouton « modification »
  • URL d’aide (incluant une url http et potentiellement une URL ldap simplifiée) (mono-valué/optionnel) (page d’aide exhaustive obtenue en cliquant sur un bouton « ? »)
  • Description exhaustive (dictionnaire de données) (mono-valué/optionnel)
  • Valeur dans le format {code}libellé (multi-valué/obligatoire si indicateur « pris dans liste » = TRUE. (pour tous types de listes de valeurs)
    • {code}libellé ; dans ce cas seul le code figure dans l’attribut
    • {{code}libellé} ; dans ce cas l’ensemble {code} libellé figure dans l’attribut
Afin de pouvoir afficher correctement les pages d’aide sur les attributs contenus dans le schéma enrichi, et notamment transformer l’URL LDAP simplifiée, il faut une page spécifique. Cette page devra afficher la page et remplacer l’URL par le contenu de l’attribut description de l’entrée pointée et y insérer un lien permettant de naviguer vers les informations de cette entrée. (Exemple attribut diffusionPhoto invitant l’utilisateur à se renseigner auprès du Service de la Scolarité)

Création du schéma enrichi (schéma du schéma enrichi)

La description du schéma du schéma enrichi est faite dans le document « Schéma général LDAP ».

Exemple
Classe etudiantUPMC

dn : ou=etudiantUPMC, ou=schema, ou=Systeme, dc=upmc, dc=fr
objectClass : top
objectClass : descriptionClasse
libelleLong : Étudiant de l’Université Pierre et Marie Curie
libelleCourt : Étudiant UPMC
libelleImpression : Étudiant Université P. et M. Curie
filtrable : TRUE
description : classe des étudiants de l’UPMC
heriteDe : personne
Attribut diffusionPhoto de la classe etudiantUPMC

dn : cn=diffusionPhoto, ou=etudiantUPMC, ou=schema, ou=Systeme, dc=upmc, dc=fr
objectClass : top
objectClass : descriptionAttribut
multiValue : FALSE
obligatoire : TRUE
modifiable : TRUE
filtrable : TRUE
prisDansListe : TRUE
doubleValidation : FALSE
valeurParDefaut : FALSE
confidentialite : CE
libelleLong : Autorisation de diffusion de la photo
libelleCourt : Diffusion photo
libelleImpression : Diffusion de la photo
aideModification : Accordez ou refusez la diffusion de votre photo
urlAide : http://adresse_serveur/aide/diffusionPhoto.php
description : «  Positionné à faux par défaut. La personne peut passer cet attribut à « vrai » = autoriser la diffusion de sa photo ; diffusion de type restreinte, soumise à liste rouge.
Si la personne autorise la diffusion, celle-ci est soumise à liste rouge : 
si pas de liste rouge, diffusion publique
si liste rouge : une personne authentifiée qui est un personnel peut voir la photo.
sinon, (diffusion non autorisée) seuls le Groupe Responsable (GR) de l’individu, les GR des niveaux au-dessus, et les services centraux autorisés peuvent voir la photo (i.e. Service de Scolarité, Service Juridique, Secrétariat général, Présidence) »
valeur : {TRUE}accordée
valeur : {FALSE}refusée

Contenu de l’URL d’aide : 

« Vous pouvez autoriser ou interdire la diffusion publique de votre photo. Si votre photo n’a pas été enregistrée, adressez-vous au service de la Scolarité, ……., email service scolarité »
Classe personnel

dn : ou=personnel, ou=schema, ou=Systeme, dc=upmc, dc=fr
objectClass : top
objectClass : descriptionClasse
libelleLong : Personnel
libelleCourt : Personnel
libelleImpression : Personnel
filtrable : TRUE
description : classe des personnels
heriteDe : personne
Attribut diffusionPhoto de la classe personnel

dn : cn=diffusionPhoto, ou=personnel, ou=schema, ou=Systeme, dc=upmc, dc=fr
objectClass : top
objectClass : descriptionAttribut
multiValue : FALSE
obligatoire : TRUE
modifiable : TRUE
filtrable : TRUE
prisDansListe : TRUE
doubleValidation : FALSE
valeurParDefaut : FALSE
confidentialite : CP
libelleLong : Autorisation de diffusion de la photo
libelleCourt : Diffusion photo
libelleImpression : Diffusion de la photo
aideModification : Accordez ou refusez la diffusion de votre photo
urlAide : http://adresse_serveur/aide/diffusionPhoto.php
description : «  Positionné à faux par défaut. La personne peut passer cet attribut à « vrai » = autoriser la diffusion de sa photo ; diffusion de type restreinte, soumise à liste rouge.
Si la personne autorise la diffusion, celle-ci est soumise à liste rouge : 
si pas de liste rouge, diffusion publique
si liste rouge : une personne authentifiée qui est un personnel peut voir la photo.
sinon, (diffusion non autorisée) seuls le Groupe Responsable (GR) de l’individu, les GR des niveaux au-dessus, et les services centraux autorisés peuvent voir la photo (i.e. Service du Personnel, Service Juridique, Secrétariat général, Présidence) »
valeur : {TRUE}accordée
valeur : {FALSE}refusée

Contenu de l’URL d’aide : 

« Vous pouvez autoriser ou interdire la diffusion publique de votre photo. Si votre photo n’a pas été enregistrée, adressez-vous au service ????, ……., email service ????. »
Classe personnelUPMC

dn : ou=personnelUPMC, ou=personnel, ou=schema, ou=Systeme, dc=upmc, dc=fr
objectClass : top
objectClass : descriptionClasse
libelleLong : Personnel de l’Université Pierre et Marie Curie
libelleCourt : personnel UPMC
libelleImpression : Personnel Université P. et M. Curie
filtrable : TRUE
description : classe des personnels de l’UPMC
heriteDe : personne, personnel
Attribut typeDeCarriere de la classe personnelUPMC

dn : cn=typeDeCarriere, ou=personnelUPMC, ou=schema, ou=Systeme, dc=upmc, dc=fr
objectClass : top
objectClass : descriptionAttribut
multiValue : TRUE
obligatoire : FALSE
modifiable : FALSE
filtrable : TRUE
prisDansListe : TRUE
doubleValidation : FALSE
confidentialite : CP
libelleLong : Type de carrière d’un agent titulaire
libelleCourt : Type de carrière
libelleImpression : Type de carrière
aideConsultation : « Le type de carrière ne concerne que les personnels titulaires ; il est équivalent au type de population d’Harpège » 
description : « Type de carrière d’un agent titulaire (plusieurs possibles pour une même personne) Cf. dictionnaire de données d’HARPEGE; nomenclature restreinte. »
valeur : {{GA}Pers. des grands etablissements}
valeur : {{SB}Enseignants hospitalo-univers. }
valeur : {{DA}Enseignant du 2nd degre}
valeur : {{AA}Pers. de l'admin. scolaire et univ. }
valeur : {{AC}Pers. tech., ouvrier et de service}
valeur : {{IA}Pers. Ing. Tech. et Adm. de RF}
valeur : {{CA}Agent contract. de l'adm. scol. et univ. }
valeur : {{CC}Contractuel type CNRS}
valeur : {{MA}Pers. medicaux et sociaux}
valeur : {{BA}Pers. des bibliotheques et des musees}
valeur : {{DC}Enseignant du 1er degre}
valeur : {{SA}Enseignants Chercheurs}
valeur : {{OA}Pers. d'inform. d'orient. et d'education}
Remarques sur l’exemple

personnelUPMC et etudiantUPMC correspondent aux classes d’objets associées aux employeeType équivalents ; personnel est une sur-classe des classes personnel*.

Du point de vue de l’arborescence, on a un schéma à un seul niveau :

  • Schema > classe > attribut
  • Schema > personnelUPMC > typeDeCarriere
  • Schema > personnel > diffusionPhoto
  • Schema > etudiantUPMC > diffusionPhoto

Impact sur le schéma LDAP en général

Les attributs communs à plusieurs classes devront être mis en communs par une sur‑classe. Le lien vers les sur-classes se fait par l’attribut heriteDe de la classe descriptionClasse

La création d’une sous-classe distincte dépend d’une variante d’un des attributs de la description d’un attribut.

De façon assez naturelle, les listes de valeur générales devraient se trouver dans des descriptions d’attributs de sur-classe, donc une seule fois, et les listes de valeurs induites dans des descriptions d’attributs de sous-classes, donc plusieurs fois.

L’attribut confidentialite des attributs du schéma enrichi

Utilité de l’attribut confidentialité (extrait documentation AACLs)

Pour contrôler la visibilité, l’utilisation d’AACLs ne peut agir directement. En effet toute AACL s’applique sur une cible existante : elle autorise ou non un acteur à agir sur celle-ci.

Lors d’une création ou d’un filtrage, au moment où l’on veut présenter les attributs à un utilisateur, la cible n’est pas encore définie. La seule solution envisageable est de fournir une cible modèle à une AACL. Une cible potentielle ne peut être qu’une partie de l’annuaire. La création du schéma enrichi comme arbre de l’annuaire permet, non seulement, d’enregistrer toutes les informations fines sur chaque attribut (informations qui ne peuvent pas être renseignées dans le schéma LDAP), mais aussi, d’appliquer des AACLs sur les éléments de ce schéma. Et ainsi de permettre le filtrage sur cet attribut, ou son utilisation lors de l’héritage.

Confidentialité (extrait documentation AACLs)

Comme l’étude détaillée « sélection de population » le précise, certaines populations d’acteurs, qui n’ont pas de caractéristiques communes dans l’annuaire, doivent être regroupées : Service du Personnel, Service Juridique, Secrétariat général, Présidence doivent avoir accès à des informations confidentielles du personnel ; Service de Scolarité, Service Juridique, Secrétariat général, Présidence doivent avoir accès à des informations confidentielles des étudiants. Ces regroupements se feront dans une branche « Confidentialite » de l’annuaire. Le lien avec les attributs sera assuré, si besoin est, par une caractéristique de chaque attribut du schéma enrichi : confidentialite.

Des AACLs prendront comme acteurs personnes liées à la branche « Confidentialite » par lien de pesonne ou de sous-arbre (pour désigner un service par exemple).