• supannAffectation remplacé par supannEntiteAffectation
• supannOrganisme remplacé par supannEtablissement
• supannRole remplacé par supannRoleGenerique
• la valeur staff de l'attribut eduPersonAffiliation est rendu obsolète.

• nouvelle branche du DIT pour définir les entités de l'établissement (ou=structures)
• Schéma :
  • rajout des classes : organization, dcObject, organizationalUnit, eduOrg, supannOrg, supannEntite;
  • nouveaux attributs : supannEtablissement, supannCodeEntite, supannCodeEntiteParent, supannTypeEntite;
• introduction d'un nouveau format pour les “attributs composites” (supannEtuInscription et supannRoleEntite)
• nouveaux attributs pour la définition du profil “étudiant” :
  • supannEtuAnneeInscription, supannEtuSecteurDisciplinaire, supannEtuDiplome, supannEtuTypeDiplome, supannEtuCursusAnnee, supannEtuEtape, supannEtuElementPedagogique, supannEtuRegimeInscription, supannEtuInscription;

* nouveaux attributs pour la définition des “affectations” :

• supannEntiteAffectation, eduPersonOrgDN, eduPersonOrgUnitDN, supannEntiteAffectationPrincipale, eduPersonPrimaryOrgUnitDN;

* nouveaux attributs pour la définition des “adresses email” : supannMailPerso, mailForwardingAddress;

• nouveaux attributs pour la définition du profil “personnel” : supannRoleGenerique, supannRoleEntite, supannActivite;

• mise à jour de eduPersonPrincipalName : le mode d'utilisation de l'attribut a été précisé
• mise à jour de eduPersonAffiliation : définition plus précise des populations, nouvelles valeurs (library-walk-in, researcher, retired et emeritus) ; valeur obsolète (staff)

Le maintien de la cohérence d'interprétation des sémantiques des valeurs de l'attribut eduPersonAffiliation entre les différents pays européens a amené le groupe SupAnn-tech à revoir les définitions de ces valeurs. Certaines évolutions sont incompatibles avec les définitions précédentes et devront s'accompagner de la modification de certains filtres LDAP au niveau des applications. En contrepartie le dialogue avec les fournisseurs de services, dans le cadre de la fédération d'identité, en sera grandement facilité.

• cn : précision sur le fait que, lorsqu'il s'agit du nom d'une personne, il ne doit contenir qu'une valeur
• mail : précision sur le fait qu'il ne doit contenir qu'une valeur
• supannMailPerso : précision sur le fait qu'il ne doit pas servir au routage de mails
• mailForwardingAddress : intégration dans la classe supannPerson, utilisation de la définition de Fedora Directory Server
• supannActivite : ajout nomenclature des fonctions SILLAND
• supannEtuCursusAnnee : indication que la valeur de l'année peut être omise si elle n'est pas connue
• eduPersonAffiliation : suppression des implications concernant la valeur member; dorénavant cette valeur ne dépend plus que de l'inscription de la personne dans les bases de gestion de l'établissement. Une nouvelle annexe recense les principales catégories de personnels rencontrées dans les établissements et les valeurs correspondantes de l'attribut. La valeur staff est réintroduite et les définitions de faculty et employee sont modifiées pour être compatibles avec les autres pays utilisant eduPerson. La valeur teacher est introduite et library-walk-in est dépréciée au profit de la nouvelle valeur registered-reader.
• supannRoleEntite : remplacement des attributs élémentaires initiaux supannCodeEntite et supannTypeEntite (issus de la classe supannEntite) par les attributs supannEntiteAffectation et supannTypeEntiteAffectation (introduit dans la classe supannPerson).
• supannTypeEntite : retiré de la classe supannPerson (remplacé par supannTypeEntiteAffectation)

• supannAutreMail (supannPerson) : adresses de courrier électronique autres que l'adresse institutionnelle contenue dans mail
• supannEmpCorps (supannPerson) : corps d'appartenance d'un agent
• supannTypeEntiteAffectation (supannPerson) : type de l'entité/structure d'affectation d'une personne
• supannRefId (supannPerson, supannEntite, supannGroupe) : identifiants/liens avec d'autres bases du SI

• NCORPS pour la nomenclature des corps utilisée par supannEmpCorps
• des valeurs de nomenclatures provenant d'organismes hors enseignement supérieur peuvent figurer en étant préfixées avec la convention <nom d'organisme>_<type nomenclature>. Exemple : CNRS_CORPS

Des nomenclatures (utilisant l'étiquette {SUPANN}) pour les attributs supannRoleGenerique, supannTypeEntite et supannRoleEntite ont été élaborées et mises en ligne à http://www.cru.fr/documentation/supann/nomenclatures-proposees

Dans les descriptions des attributs (§ 7) : ajout de l'information sur la (les) branche(s) du DIT où ils apparaissent.

L'annuaire d'établissement peut être considéré comme une clé de voûte du Système Global d'Information (SGI) ; en effet il maintient la cohérence entre toutes les briques applicatives dans les domaines de l'authentification, du contrôle d'accès,.... Le format de cet annuaire doit, de ce fait, obéir à des contraintes d'inter-opérabilité fortes en ce qui concerne la syntaxe, la sémantique et les valeurs des attributs stockées.

Différentes catégories d'acteurs ont contribué aux recommandations SupAnn ou ont été consultées :

• les responsables de projets UNR et UNT pour la partie définition des besoins fonctionnels ;
• les établissements par le biais d'un sous-ensemble de responsables annuaire pour la partie technique ;
• les représentants des directions du ministère de tutelle en charge des Systèmes d'Information ;
• les concepteurs d'applications métier (AMUE, Consortium Cocktail) ;
• la DEPP pour les aspects nomenclatures ;
• les EPSTs partenaires : CNRS, INRIA

Les établissements souhaitant soumettre des propositions pour des évolutions ou de nouveaux attributs sont invités à contacter le groupe technique supann-tech@cru.fr.

L'élaboration des recommandations SupAnn 200x obéit à un certain nombre de règles parmi lesquelles :

• assurer la plus grande compatibilité ascendante possible avec les précédentes recommandations ;
• articulation avec les recommandations internationales (plus particulièrement Internet2/eduPerson ou Terena/SCHAC, REFEDs) ;
• prise en compte des nomenclatures nationales (voir chapitre Nomenclatures) ;
• non prise en compte des besoins trop spécifiques ; chaque établissement ayant la liberté d'enrichir son schéma d'annuaire pour répondre à ses besoins propres;
• pour certains attributs, SupAnn prévoit des codes (exemple : ”{SISE}2001142” pour un diplôme de droit social), mais ne prévoient pas d'éléments pour véhiculer les libellés correspondant à ces codes ; les applications clientes devront elles-mêmes effectuer la correspondance code→libellé si nécessaire offrant ainsi une souplesse adaptée pour le contexte local.

Niveaux de préconisations

Ce document décrit des préconisations et des bonnes pratiques. Afin de déterminer le niveau d'obligation de respect de ces préconisations, la terminologie définie dans le RFC 2119 est utilisée.

Voici une traduction de la définition de ces termes explicités dans le RFC 2119 :

1. DOIT : ce mot, ou le terme “EXIGÉ”, signifient que la définition est une exigence absolue de la spécification.

2. NE DOIT PAS: cette expression signifie que la définition est une prohibition absolue de la spécification.

3. DEVRAIT : ce mot, ou l'adjectif “RECOMMANDÉ”, signifient qu'il peut exister des raisons valables, dans des circonstances particulières, pour ignorer cet item particulier, mais les conséquences doivent être comprises et pesées soigneusement avant de choisir une voie différente.

4. NE DEVRAIT PAS : cette expression, ou l'expression “NON RECOMMANDÉ”, signifient que la définition est prohibée. Il peut toutefois exister des raisons valables, dans des circonstances particulières, quand le comportement particulier est acceptable ou même utile, de ne pas suivre cette recommandation. Mais les conséquences doivent être comprises et le cas soigneusement pesé.

5. PEUT : ce mot, ou l'adjectif “FACULTATIF”, signifient qu'un item est vraiment facultatif. Un vendeur peut inclure l'item parce qu'un marché particulier l'exige ou parce qu'il estime qu'il améliore le produit tandis qu'un autre vendeur peut omettre le même item.

Les annuaires contiennent des données à caractère personnel. C'est pourquoi ils doivent se mettre en conformité avec les grands principes de la loi “Informatique et Libertés” qui sont au nombre de 5 :

• finalité : tout traitement doit correspondre à une finalité déterminée, précise et légitime ;
• proportionnalité : les données traitées doivent être pertinentes au regard de la finalité ;
• durée limitée de conservation des données : les informations ne peuvent pas être conservées de façon indéfinie ; la durée établie doit être adéquate au regard de la finalité ;
• sécurité et confidentialité : les données doivent bénéficier de mesures permettant d'assurer leur sécurité, afin d'éviter qu'elles ne soient déformées, endommagées, ou que des personnes non autorisées puissent y avoir accès ;
• respect des droits des personnes : tout individu dont les données personnelles font l'objet d'un traitement dispose d'un droit à l'information, d'un droit d'accès et de rectification des informations le concernant, ainsi que d'un droit d'opposition (à moins que le traitement ne présente un caractère obligatoire)

Dans le cadre d'annuaires des personnels et des usagers, voici comment peuvent se décliner ces grands principes.

Dans tous les cas, il est nécessaire d'apporter une information claire aux personnes, dès leur ajout dans l'annuaire.

L'établissement peut considérer que la présence de tous les personnels dans l'annuaire publié sur l'intranet est obligatoire.
Par contre, les personnels sont en droit de s'opposer à figurer dans l'annuaire publié sur internet. Néanmoins, il n'est pas nécessaire de recueillir leur accord préalable.

Si l'établissement souhaite constituer un annuaire public des étudiants, il est nécessaire de recueillir leur autorisation expresse. En effet, la CADA considère que la liste des étudiants est protégée par le secret de la vie privée.

De plus, il faudra gérer leur droit d'opposition ultérieure.

Ce cas est traité dans la fiche n°5 du Guide Informatique et Libertés pour l'enseignement supérieur et la recherche.

Cas particulier de la photo : pout respecter le droit à l'image, il est nécessaire de recueillir l’autorisation expresse de la personne (ou de laisser la mise en ligne à son initiative, c'est plus simple à gérer)

Les personnes doivent être supprimées de l'annuaire à partir du moment où elles n'ont plus de lien avec l’établissement.

Il est recommandé d'utiliser des techniques permettant de rendre très difficile la collecte automatique d’adresses mail. Les protections utilisées doivent dissuader les spammeurs.

La mise en oeuvre d'annuaires de personnels ou d'usagers est soumise au régime de déclaration :

• si l'établissement a désigné un correspondant Informatique et Libertés (CIL), ce dernier inscrira l'annuaire dans le registre des traitements à caractère personnel de l'établissement ;
• sinon, l'établissement devra réaliser une déclaration normale auprès de la CNIL.

Certains attributs de SupAnn font référence à des nomenclatures nationales. Il s'agit de nomenclatures déjà utilisées dans les applications métier de la majorité des établissements. Ci-dessous sont indiquées différentes nomenclatures utilisées, en mentionnant le site web de référence ; charge aux gestionnaires d'annuaires d'utiliser une version à jour de ces nomenclatures.

En cas d'utilisation d'une nomenclature par un attribut, celle-ci est précisée au niveau de la définition de l'attribut (voir section 7). Le site de référence et la table définissant la nomenclature sont alors mentionnés. L'utilisation d'une nomenclature dans un attribut est indiquée au moyen d'une étiquette (voir le chapitre 2.3 dédié aux étiquettes).

Remarque : lorsque SupAnn définit un attribut contenant un code (exemple : {SISE}2001142 pour un diplôme de droit social), il n'a pas été prévu d'attribut correspondant pour stocker le libellé correspondant à ce code. Les applications clientes de l'annuaire devront donc elles-mêmes effectuer la correspondance code→libellé si nécessaire.

Référentiel : Base Centrale des Nomenclatures

SISE (Système d'Information pour le Suivi des Etudiants) permet de faire remonter au Ministère les données relatives aux inscriptions des étudiants dans les principaux établissements d'enseignement supérieur. Les données remontées vers la Direction de l'Evaluation de la Prospective et de la Performance (DEPP) doivent respecter certaines nomenclatures.

SupAnn exploite ces nomenclatures pour définir le parcours d'un étudiant.

Référentiel : table N_DISCIPLINE_SUPERIEUR dans la Base Centrale des Nomenclatures

Le CNU (Conseil National des Universités) est l'instance chargée d'organiser la carrière des enseignants-chercheurs. Le CNU est divisé en groupes de sections, et en autant de sections qu'il y a de disciplines officielles, chaque groupe rassemblant plusieurs sections. Dans les disciplines médicales, odontologiques et pharmaceutiques, chaque section est encore divisée en sous-sections correspondant à des options. Les codes sections et sous-sections CNU sont utilisés dans les applications de gestion des personnels et des étudiants.

SupAnn exploite cette nomenclature pour préciser le métier d'un enseignant (attribut supannActivite).

Référentiel : table N_EMPLOI_TYPE dans la Base Centrale des Nomenclatures

REFERENS (REFérentiel des Emplois-types de la Recherche et de l'ENseignement Supérieur) est un référentiel définissant les emplois type pour les personnels ITRF. Ce référentiel est notamment utilisé pour définir des fiches de poste, voir le site referens.

SupAnn exploite cette nomenclature pour coder le type d'emploi d'un personnel non enseignant (attribut supannActivite).

Référentiel : Base Centrale des Etablissements

Un code UAI (Unité Administrative Immatriculée) est attribué à chaque établissement d'enseignement (pas restreint à l'enseignement supérieur). Les codes UAI remplacent les code RNE (Répertoire National des Etablissements) depuis 1996 ; ils reprennent la nomenclature existante.

SupAnn exploite cette nomenclature pour représenter l'établissement de rattachement d'une personne (attribut supannEtablissement).

Tout établissement d'enseignement supérieur doit posséder un code UAI.

Référentiel : l'annuaire des unités du CNRS

L'application Labintel définit des codes pour chaque laboratoire ; ces codes peuvent être retrouvés en consultant l'annuaire des unités du CNRS.

SupAnn exploite cette nomenclature pour représenter le laboratoire de rattachement d'une personne (attribut supannEtablissement).

Référentiel : INSEE

Le numéro de SIRET est un identifiant d'établissement, composé d'un code SIREN, complété d'un NIC (Numéro Interne de Classement).

SupAnn exploite cette nomenclature pour représenter un établissement qui ne possède pas de code UAI (attribut supannEtablissement).

Certaines nomenclatures étant incomplètes voire inexistantes ont conduit le groupe supann-tech à en compléter ou en créer de nouvelles. Elles sont recensées dans cette page : http://www.cru.fr/documentation/supann/nomenclatures-proposees.

Pour identifier la nomenclature de provenance de certaines valeurs, les attributs utilisant ces nomenclatures DOIVENT faire précéder la valeur de l'attribut par une étiquette. Le format de ces attributs est le suivant :
{<provenance>}<valeur>

Choix possibles pour <provenance> :

• UAI : la valeur est un code UAI
  • exemple : {UAI}0350936C
• SIRET : la valeur est un code SIRET
  • exemple : {SIRET}19350936100013
• SISE : la valeur qui suit est issue de la nomenclature SISE
  • exemple: {SISE}2101332 identifiant le Diplôme “Master” en ARTS, LETTRES ET LANGUES : HUMANITES
• UAI:<codeUAI> : la valeur qui suit est issue d'une nomenclature interne à l'établissement ayant ce 'codeUAI'
  • exemple: {UAI:0350936C}dummy25 pour une valeur issue d'une nomenclature de Rennes 1
• UAI:<code UAI>:<étiquette> la valeur qui suit provient de la brique <étiquette> (cf valeurs possibles ci-dessous) du SI de l'établissement ayant ce <codeUAI>
  • exemple : {UAI:0440984F:APOGEE}54321 pour un identifiant issu du logiciel APOGEE de l'université de Nantes
• CNU : la valeur qui suit est issue du Conseil National des Universités (CNU) à travers une table de la BCN
  • exemple : {CNU}5404 provient du SI d'un autre établissement (exemple : {UAI:0440984F:APOGEE})
• SILLAND : la valeur qui suit est issue de la liste des “fonctions SILLAND”
  • exemple : {SILLAND}ADMI pour la fonction “Administration de la recherche”
• REFERENS : la valeur qui suit est issue du REFérentiel des Emplois-types de la Recherche et de l'ENseignement Supérieur (http://referens.univ-poitiers.fr/)
  • exemple : {REFERENS}E1C05
• NCORPS : la valeur qui suit est issue de la colonne “CORPS” de la table “N_CORPS” du domaine “Gestion du personnel” de la BCN
• SUPANN : la valeur qui suit est issue d'une nomenclature propre à SupAnn
  • exemple : {SUPANN}M2 pour préciser “2ème année de Maîtrise” pour l'attribut supannEtuCursusAnnee
• <nom d'organisme>_<type nomenclature> : la valeur qui suit est issue de la nomenclature de l'organisme indiqués
  • exemple : {INRIA_CORPS}SAR pour le corps de “Secrétaire d'administration de la recherche” de l'INRIA
• APOGEE, HARPEGE, SIFAC, NABUCO, SCOLARIX, MANGUE, PAPAYE, GRHUM, ASTRE, JERICO, GEISHA, POEMS, HELICO : la valeur qui suit est issue d'un de ces logiciels
  • exemple : {APOGEE}12345 pour désigner le dossier correspondant dans APOGEE
• INCONNU : indique qu'aucune valeur appropriée n'a pu être déterminée (et n'est donc pas suivi d'une valeur). Sera utilisé en particulier pour remplir un champ obligatoire pour lequel on n'a pas de valeur légitime.
  • valeur : {INCONNU}

Noter qu'il n'y a pas d'espace entre ”}” et la valeur qui suit.

On entend par profil multiple les cas où :

• une personne a plusieurs statuts (par exemple enseignant et étudiant) ;
• un personnel a plusieurs rôles (par exemple responsable d’UFR, responsable d’une maîtrise) ;
• un étudiant prépare plusieurs diplômes ;
• un étudiant suit une formation en relation avec plusieurs disciplines (par exemple en math et physique) ;
• un personnel est affecté à plusieurs structures.

Problème : dès qu'une personne a plusieurs profils, il y a risque de perdre l'association entre des informations corrélées. Par exemple, le diplôme, et le niveau dans le diplôme, s'ils sont stockés dans des attributs distincts. Ce problème est lié à la nature non relationnelle d'un annuaire LDAP.

Plusieurs solutions techniques ont été envisagées par le groupe de travail SupAnn pour parer à cette perte d'information :

1. attribut composite : regrouper les informations liées dans un seul attribut dont le contenu devient structuré. Par exemple : ”<rôle>|<structure>” (ex. “directeur|UFR de maths”) ou ”<rôle>|<DN>” (ex. “directeur|ou=12345,o=98765,dc=univ-truc,dc=fr”) ou ”<diplôme>|<discipline>|<étape>”. Avantage : information accessible en une seule recherche. Inconvénient : les applications doivent savoir “décortiquer” cet attribut.
2. pointer vers des objets (situés ailleurs dans l'annuaire) décrivant le “profil” correspondant. Exemple : un objet “formation” contenant au moins les trois informations diplôme, discipline et étape. Cet objet est instancié autant de fois qu'il y a d'instances de formations dans l'établissement. Avantage : cela peut rejoindre un autre besoin (description des formations dans l'annuaire). Inconvénient : recherches indirectes (pour rechercher les étudiants en biologie il faut repérer tous les objets formation dont la discipline est biologie puis rechercher les personnes ayant un pointeur sur ces objets).
3. croiser plusieurs informations contenues dans l'annuaire. Exemple : croiser l'information “rôle” d'une personne avec le contenu de la branche des structures pour savoir de quelle entité elle est directeur par exemple.
4. solution hybride : les informations sont à la fois inscrites dans des attributs séparés et regroupées dans un attribut spécifique composite. Inconvénient : il faut veiller à la cohérence entre les attributs.
5. utilisation de groupes : à chaque profil correspond un groupe auquel appartiennent les personnes ayant ce profil.
6. utilisation d'alias remontant des structures vers les personnes : des objets alias dans les feuilles de la branche des structures, des inscriptions des étudiants, des inscriptions des personnes dans les applications de gestion, etc... pointent sur les entrées de personnes appartenant à l'entité avec des attributs associés à l'alias décrivant la fonction.
7. pointeurs vers les entrées de personnes depuis une branche contenant la description des formations ou des fonctions.

Le groupe de travail a retenu la solution des attributs composites. Les attributs de ce type regroupent les valeurs de plusieurs attributs, dans un ordre défini, séparées par une séquence spécifique. Voir paragraphe ci-après.

Les attributs dits “composites” regroupent des valeurs d'attributs élémentaires, dont l'association a un sens (cf. Problématique des profils multiples ci-dessus), sous la forme d'une succession ordonnée de champs :

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

Chaque champ est composé des éléments suivants :

• des délimiteurs encadrant le champ : ”[” en début de champ, ”]” en fin de champ
• une étiquette se rapportant à un attribut élémentaire, dont l'intitulé est proche mais plus court,
• un séparateur ”=” entre l'étiquette et la valeur,
• une valeur reprenant une des valeurs de l'attribut élémentaire correspondant.

Il n'y a pas d'espace entre les différents constituants.

Certains champs peuvent être facultatifs. Ils sont en principe à la fin de l'attribut composite.

Les attributs composites sont multivalués, une valeur représentant un “profil”:

Exemple : l'attribut composite supannEtuInscription qui regroupe plusieurs attributs définissant la ou les inscriptions d'un étudiant. Voir l'exemple détaillé en annexe 1.

Les recherches sur ces attributs peuvent alors se faire de la façon générique suivante :

• (attributComposite=*[etiq_x=valeur_x]*[etiq_y=valeur_y]*)

L'ordre etiqu-x ... etiq_y dans l'écriture du filtre de recherche doit respecter l'ordre dans lequel ces attributs élémentaires sont ordonnés dans la définition de l'attribut composite.

Remarque : le format des attributs composites permet l'évolutivité de ces attributs : en cas de besoin il est possible de rajouter des champs sans perturber les applications (filtres) existantes.

Le schéma SupAnn intègre des classes d'objets ainsi que des attributs issus des RFC LDAP ainsi que des classes d'objets et des attributs spécifiques à SupAnn. Les noms d'attributs définis dans les recommandations SupAnn débutent par le préfixe supann.

Classes utilisées dans le schéma SupAnn :

Les tableaux qui suivent (un par classe) précisent les listes d'attributs dont l'utilisation est recommandée.

Légende des tableaux

Niveau d'obligation pour la présence de l'attribut :

• O : présence obligatoire au sens LDAP ;
• D : présence demandée par SupAnn (même si la norme LDAP ne l'impose pas).

Un attribut est optionnel dans SupAnn 2008 si ni «O» ni «D» ne sont précisés.

NB: pour les classes issues des RFC LDAP, seuls sont précisés les attributs dont l'usage est recommandé ou conseillé.

Les attributs utilisés dans la classe organization

Les attributs utilisés dans la classe dcObject

Les attributs utilisés dans la classe organizationalUnit

Les attributs utilisés dans la classe eduOrg

Les attributs utilisés dans la classe supannOrg

Les attributs utilisés dans la classe supannEntite

Les attributs utilisés dans la classe inetOrgPerson

Les attributs utilisés dans la classe eduPerson

Les attributs utilisés dans la classe supannPerson

Attributs pour la classe groupOfNames

Attributs pour la classe supannGroupe

Liens entre les objects dans le DIT

Une branche spécifique est créée pour stocker les entités/structures de l'établissement :

• ou=structures,dc=<domaine_etab>,dc=fr

Cette branche n'a pas de sous branches : tous les objets sont au même niveau.

Les relations de dépendance entre entités, au lieu d'être représentées hiérarchiquement dans le DIT, sont représentés à l'aide d'un attribut faisant référence aux entités parentes (cf ci-dessous).

Ce choix offre les avantages * de s'affranchir des problèmes de réorganisation : le DN des objets reste inchangé ;

• de pouvoir définir plusieurs entités parentes pour une entité ;
• d'éviter de gérer les entités électives à part ;
• d'adopter une organisation semblable aux branches voisines ou=people et ou=groups.

Les objets de cette branche sont identifiés (RDN) par l'attribut supannCodeEntite.

* l'entrée de l'établissement (gestionnaire de l'annuaire) DOIT être stockée à la racine de l'annuaire. Elle utilise les classes d'objet organization, dcObject, eduOrg et supannOrg.

• l'entrée du même établissement peut également être représentée en tant qu'entité dans la branche ou=structures, avec les classes organization, eduOrg, supannOrg et supannEntite;
• des entrées représentant d'autres établissements peuvent également figurer sous la branche ou=structures.

Une branche spécifique est créée pour stocker les groupes :

ou=groups,dc=<domaine_etab>,dc=fr

Cette branche n'a pas de sous branches : tous les objets sont au même niveau. Il n'y a pas de relation de dépendance entre les entrées de cette branche.

Les objets de cette branche sont identifiés (RDN) par l'attribut «cn» de la classe groupOfNames.

Un groupe est donc référencé par un DN s'exprimant sous la forme suivante :

cn=grp-2387-B,ou=groups,dc=mon-domaine,dc=fr

Pour plus d'informations concernant ces attributs voir la liste des attributs en section 7.

Sémantique : nom complet sans accent soit d'une personne, soit d'un “groupOfNames”

Branche DIT : ou=people/ou=groups

Origine : RFC4519 (inetOrgPerson, groupOfNames)

Valuation : multivalué mais ne devrait contenir qu'une valeur dans le cas du nom d'une personne

Obligatoire : Oui

Contenu :

• pour une personne DOIT contenir le nom suivi du prénom (séparés par un espace). Attention : pas de caractère avec signe diacritique pour simplifier les recherches ;
• pour un “groupOfNames” un nom sans accent ;
• pour un organisme idem.

Exemple : « Bugale Jerome »

Remarque : il est demandé de positionner le nom en premier pour des raisons de facilité de tri. Cet attribut est utilisé uniquement à des fins techniques comme faciliter des recherches.

Voir aussi : displayName, eduPersonNickname, givenName, sn,

Sémantique : un élément d'un nom de domaine

Branche DIT : racine

Origine : RFC2247 (dcObject)

Valuation : multivalué

Obligatoire : Oui

Contenu :

• un des éléments d'un nom de domaine DNS

Exemples :

• « univ-metz »
• « fr »

Sémantique : une description en langage clair d'un objet

Origine : RFC4519 (organizationalUnit, groupOfNames, etc.)

Valuation : multivalué

Obligatoire : Non

Contenu : texte libre

Sémantique : nom complet avec accents

Branche DIT : ou=people

Origine : RFC2798 (inetOrgPerson)

Valuation : monovalué

Obligatoire : Non

Contenu : DOIT contenir le prénom suivi du nom. Version accentuée de la valeur principale de cn. Attention : il s'agit ici de l'ordre inversé de cn

Exemple : « Jérôme Bugalé »

Voir aussi : cn, eduPersonNickname, sn, supannCivilite, title.

Sémantique : URL du serveur web officiel de l'établissement

Branche DIT : racine/ou=structures

Origine : Internet2 (eduOrg)

Valuation : multivalué

Obligatoire : Non

Contenu : URL

Exemple : ”http://www.univ-paris1.fr/”

Voir aussi : eduOrgSuperiorURI, eduOrgWhitePagesURI

Sémantique : nom officiel de l'établissement

Branche DIT : racine/ou=structures

Origine : Internet2 (eduOrg)

Valuation : multivalué mais ne devrait contenir qu'une valeur

Obligatoire : Non

Contenu : texte libre

Exemple : “Université de Pau et des Pays de l'Adour”

Remarques :

Il est recommandé de ne mettre qu'une seule valeur, qui doit être le nom officiel de l'établissement (et non un nom d'usage ou un sigle).

Sémantique : URL du serveur web de l'institution de rattachement

Branche DIT : racine/ou=structures

Origine : Internet2 (eduOrg)

Valuation : multivalué

Obligatoire : Non

Contenu : URL

Exemple : ”http://education.gouv.fr/”

Remarques : typiquement, pour les établissement d'enseignement supérieur, cet attribut contiendra : ”http://education.gouv.fr/”

Voir aussi : eduOrgHomePageURI

Sémantique : annuaire pages blanches de l'établissement

Branche DIT : racine/ou=structures

Origine : Internet2 (eduOrg)

Valuation : Multivalué

Obligatoire : Non

Contenu : URL

Exemple : ”http://www.univ-paris1.fr/annuaire”, ”ldap://ldap.univ-nancy1.fr/”

Voir aussi : eduOrgHomePageURI

Sémantique : statut de la personne : étudiant, BIATOSS, enseignant, contractuel, retraité, personnel hébergé (CNRS, INSERM, etc.), ancien étudiant, etc.

Branche DIT : ou=people

Origine : Internet2 (eduPerson)

Valuation : multivalué

Usage : pages blanches, contrôle d'accès à des ressources

Obligatoire : Non

Contenu : nomenclature originale d'eduPerson + extensions SupAnn :

• student : personne suivant une formation quelconque dans l'établissement. Si la valeur “member” est positionnée la personne est enregistrée dans la base des étudiants;
• faculty : personnel dont l'activité principale (dans l'établissement) est pédagogique, d'enseignement ou/et de recherche. La valeur “member” est positionnée si ce personnel est géré par l'établissement;
• staff : personnel dont l'activité principale (dans l'établissement) est autre qu'enseignant ou chercheur (typiquement BIATOS) ;
• employee : tout personnel rémunéré par l'établissement, quelque soit son activité;
• member : personne inscrite dans la (les) base(s) de gestion des étudiants ou celle(s) des personnels;
• affiliate : personne qui ne dépend pas de l'établissement (exemple : un partenaire extérieur). La valeur “member” est exclue pour ces personnes;
• alum : ce profil définit un ancien étudiant conservant des relations avec l'établissement ;
• library-walk-in (eduPerson 2007) : sans objet dans SupAnn. Voir registered-reader ci-dessous et remarques;
• researcher (SupAnn v1) : personne assurant une activité de recherche. La valeur “member” est positionnée si ce personnel est géré par l'établissement;
• retired (SupAnn 2008) : personne à la retraite conservant des relations avec l'établissement ;
• emeritus (SupAnn 2008) : professeur ayant obtenu l'éméritat dans l'établissement.
• teacher (SupAnn 2009) : personnel assurant une activité d'enseignement ;
• registered-reader (SupAnn 2009) : lecteur de bibliothèque autorisé.

Exemple: “employee” + “member” + “staff” pour un personnel BIATOS

Remarques

La valeur “member” peut éventuellement être utilisée comme “valeur refuge” pour des catégories de personnes dont l'activité n'est pas encore identifiée dans la(les) base(s) du personnel.

L'annexe 2 décrit les valeurs à utiliser en fonction des principales catégories de personnes rencontrées dans les établissements.

Voir aussi : eduPersonPrimaryAffiliation

Sémantique : nom d'affichage

Branche DIT : ou=people

Origine : Internet2 (eduPerson)

Valuation : multivalué

Obligatoire : Non

Contenu : PEUT contenir un nom d'usage informel choisi par l'utilisateur. Il peut s'agir d'un surnom.

Voir aussi : cn, displayName

Sémantique : désigne l'entrée de l'établissement d'affectation de la personne dans l'annuaire

Branche DIT : ou=people

Origine : Internet2 (eduPerson)

Valuation : monovalué

Obligatoire : Non

Contenu : Distinguished Name sur une entrée d'établissement

Exemples :

• “dc=univ-rennes1,dc=fr”
  
• “supannCodeEntite=127,ou=structures,dc=univ-rennes1,dc=fr”

Remarques : si besoin, cet attribut PEUT contenir le DN de l'entrée de l'établissement d'affectation de la personne dans l'annuaire

Voir aussi : supannEntiteAffectation, eduPersonOrgUnitDN, supannEtablissement.

Sémantique : désigne l'entrée de la structure d'affectation (composante, service, ...) de la personne dans l'annuaire.

Branche DIT : ou=people

Origine : Internet2 (eduPerson)

Valuation : multivalué

Obligatoire : Non

Contenu : Distinguished Name désignant le(s) service(s) (département, UFR, etc.) d'affectation de la personne

Remarques : si besoin, cet attribut PEUT contenir le DN de la ou des entrées décrivant les services d'affectation de la personne dans l'annuaire

Voir aussi : eduPersonOrgDN, supannEntiteAffectation.

Sémantique : statut principal de la personne

Branche DIT : ou=people

Origine : Internet2 (eduPerson)

Valuation : monovalué

Obligatoire : Non

Contenu : PEUT contenir le statut « principal » de l'usager. Si valué, il DOIT contenir une des valeurs de eduPersonAffiliation (sauf member, à moins que ça ne soit la seule valeur de eduPersonAffiliation).

Remarques : peut être utilisé pour choisir un profil d'affichage dans l'ENT ou mettre en évidence un profil principal dans l'annuaire.

Voir aussi : eduPersonAffiliation

Sémantique : désigne l'entrée de la structure (composante, service) dans l'annuaire considérée comme affectation principale de la personne

Branche DIT : ou=people

Origine : Internet2 (eduPerson)

Valuation : monovalué

Obligatoire : Non

Contenu :
Distinguished Name.
Une des valeurs de eduPersonOrgUnitDN.

Voir aussi : eduPersonOrgUnitDN.

Sémantique : Identifiant institutionnel unique

Branche DIT : ou=people

Origine : Internet2 (eduPerson)

Valuation : Monovalué

Obligatoire : Non

Contenu : nom qualifié de la forme <identifiant local>@<domaine>

Cet attribut n'a pas vocation à être directement manipulé par les utilisateurs (un utilisateur n'est pas censé connaître la valeur de son eduPersonPrincipalName). En revanche cet attribut pourra être utilisé par une application pour faire référence (par exemple pour gérer des règles de contrôle d'accès) à des utilisateurs issus d'un autre établissement.

Exemples :

• “jdupond@univ-truc.fr”
• “63936407@univ-machin.fr”

Remarques :
L'attribut eduPersonPrincipalName est un identifiant de personne, globalement unique. Pour ce faire il est constitué de deux parties, séparées par le caractère '@'. La partie gauche doit être unique pour un établissement donné ; la partie droite qualifie l'établissement. Le format de la partie gauche n'est pas contraint ; il peut correspondre à l'uid de l'utilisateur, par exemple. En revanche, la partie droite DOIT correspondre au domaine DNS de l'établissement.

Comme l'attribut eduPersonPrincipalName peut être utilisé comme identifiant dans des applications, il est important que la valeur de cet attribut ne soit pas réassignée à une autre personne d'une année à l'autre. Un établissement devra donc faire son possible pour garantir cette qualité de non-réassignabilité de l'attribut eduPersonPrincipalName, ou la garantir pendant une période donnée (1 an, 5 ans, 10 ans). L'utilisation d'un uid d'utilisateur incrémental et opaque peut aider à atteindre cet objectif.

Cet attribut ne doit pas être confondu avec l'attribut mail qui a une syntaxe proche.

Voir aussi : supannAliasLogin, uid.

Sémantique : numéro de fax

Branche DIT : racine/ou=people/ou=structures

Origine : RFC4519 (inetOrgPerson, organization, organizationalUnit)

Valuation : multivalué

Obligatoire : Non

Contenu : un numéro E 123 (voir syntaxe de l'attribut telephoneNumber)

Sémantique : prénom

Branche DIT : ou=people

Origine : RFC4519 (inetOrgPerson)

Valuation : multivalué mais ne devrait contenir qu'une valeur

Obligatoire : Demandé

Contenu : DOIT contenir le prénom. Tout caractère avec signe diacritique. Il est conseillé d'utiliser uniquement le prénom principal.

Exemple : « Jérôme »

Voir aussi : cn, displayName, eduPersonNickname, sn

Sémantique : nom d'une localité.

Branche DIT : racine/ou=structures

Origine : RFC4519 (organization, organizationalUnit)

Valuation : multivalué

Obligatoire : Non

Contenu : texte libre. Nom d'une ville, lieu-dit, etc.

Voir aussi : postalAddress

Sémantique : URL

Branche DIT : ou=people

Origine : RFC2798 (inetOrgperson)

Valuation : multivalué

Obligatoire : Non

Contenu : PEUT contenir une URL vers la page personnelle

Exemple : ”http://www.cru.fr/perso/jplg”

Sémantique : adresse de courrier électronique institutionnelle

Branche DIT : ou=people

Origine : RFC2798 (inetOrgPerson)

Valuation : multivalué mais ne devrait contenir qu'une valeur

Obligatoire : Non

Contenu :
Chaîne de caractères au format RFC822.
Cet attribut DOIT contenir l'adresse de courrier électronique canonique institutionnelle. Les autres adresses éventuelles doivent aller dans l'attribut supannAutreMail.

Voir aussi : mailForwardingAddress, supannMailPerso, supannAutreMail

Sémantique : adresse de renvoi de courrier électronique reçu à l'adresse institutionnelle

Branche DIT : ou=people

Origine : Netscape/Fedora (classe mailRecipient)

Valuation : multivalué

Obligatoire : Non

Contenu : chaîne de caractères au format rfc822 ou valeur d'uid

Exemple : “Vincent.Poursan@free.fr”

Remarques
Cet attribut PEUT être utilisé pour stocker l'adresse à laquelle l'utilisateur souhaite que soit redirigé son courrier électronique.
La valeur de l'attribut uid peut également être ajoutée pour signifier le besoin d'une délivrance locale en plus d'une redirection.
Par commodité il a été intégré à la classe supannPerson et la définition de Fedora Directory Server est fournie avec le schéma SupAnn. En cas de conflit avec le schéma prédéfini d'un serveur, il suffit de l'effacer.

Voir aussi : mail, supannMailPerso, supannAutreMail

Sémantique : membre individuel

Branche DIT : ou=groups

Origine : RFC4519 (groupOfNames)

Valuation : multivalué

Obligatoire : Oui

Contenu : DN de chaque membre du groupe

Sémantique : numéro de téléphone mobile

Branche DIT : ou=people

Origine : RFC2798 (inetOrgPerson)

Valuation : multivalué

Obligatoire : Non

Contenu : un numéro E 123 (voir syntaxe de l'attribut telephoneNumber)

Voir aussi : facsimileTelephoneNumber, supannAutreTelephone, telephoneNumber

Sémantique : contient le nom d'une «organization»

Branche DIT : ou=people/ou=structures

Origine : RFC4519 (organization) et mentionné dans RFC2798 (inetOrgPerson)

Valuation : multivalué

Obligatoire : Oui dans «organization», non dans «inetOrgPerson»

Contenu :

• dans «organization» : nom de l'établissement. Obligatoirement renseigné.
• dans «inetOrgPerson» : établissement de rattachement de la personne.

Sémantique : nom d'une entité interne de type «organizationalUnit»

Branche DIT : ou=structures

Origine : RFC4519 (organizationalUnit)

Valuation : Multivalué

Obligatoire : Oui

Contenu : texte libre

Remarque: peut contenir le nom des structures et/ou entités.

Sémantique : Responsable (détenteur)

Branche DIT : ou=groups

Origine : RFC4519 (groupOfNames)

Valuation : multivalué

Obligatoire : Non

Contenu : DN du créateur du groupe et/ou des personnes habilitées à y apporter des modifications

Sémantique : adresse postale

Branche DIT : racine/ou=people/ou=structures

Origine : RFC4519 (inetOrgPerson, organization, organizationalUnit)

Valuation : multivalué

Obligatoire : Non

Contenu : adresse complète. Attention au format (“$” séparateur, voir RFC4519).

Exemple : 3bis chemin des bois$BP 4321$99456 Monton Laho

Voir aussi : l (locality)

Sémantique : langue usuelle

Branche DIT : ou=people

Origine : RFC2798 (inetOrgPerson)

Valuation : monovalué

Obligatoire : Non

Contenu : voir RFC 1766 et avis ISO 639 pour l'utilisation de cet attribut

Exemples :

• “fr”
• “fr, bre;q=0.8,en-gb;q=0.5”

Sémantique : nom

Branche DIT : ou=people

Origine : RFC4519 (person) RFC2798 (organizationalPerson)

Valuation : multivalué

Obligatoire : Oui

Contenu : DOIT contenir le nom d'usage (cf glossaire). Il est possible d'ajouter le nom de famille (nom patronymique) en seconde valeur.
Tout caractère avec signe diacritique. Première lettre en majuscule.

Exemple : « Bugalé »

Voir aussi : cn, displayName, eduPersonNickname, givenName

Sémantique : catégorie de métier, branche d'activité

Branche DIT : ou=people

Origine : SupAnn 2008 (supannPerson)

Valuation : multivalué

Obligatoire : Non

Contenu : Contenu étiqueté

• enseignants : ”{CNU}” suivi du code CNU sur 4 caractères issu de la colonne “DISCIPLINE SUPERIEUR” de la table N_DISCIPLINE_SUPERIEUR du domaine “Gestion du personnel” de la BCN

(http://www.infocentre.education.fr/bcn/domaine/voir/id/30#)

• personnels :
  • ”{REFERENS}” suivi du code REFERENS de 5 caractères issu de la colonne EMPLOI TYPE de la table N_EMPLOI_TYPE du domaine “Gestion du personnel” de la BCN

(http://www.infocentre.education.fr/bcn/domaine/voir/id/30#),

• fonction SILLAND (table FONCTION_SILLAND d'Harpege, pas de source en ligne pour l'instant)

Nomenclatures : nomenclatures provenant de la Base Centrale des Nomenclatures et de l'AMUE

Exemples :

• ”{CNU}5404” pour “Endocrinologie et maladies métaboliques ”
• ”{CNU}0100” pour “Droit prive et sciences criminelles ”
• ”{CNU}3300” pour “Chimie des matériaux”
• ”{REFERENS}E1C05” pour “Expert système, réseaux et télécommunications”
• ”{REFERENS}I3H07” pour “Assistant juridique”
• ”{SILLAND}ADMI” pour “Administration de la recherche”

Remarques :

• l'attribut supannActivite n'est renseigné que pour les personnels BIATOS, enseignants et chercheurs
• concernant la nomenclature REFERENS voir également http://referens.univ-poitiers.fr/version/men/default.asp

Voir aussi : supannRoleGenerique, supannRoleEntite

Origine : SupAnn v1 (supannPerson)

Remarque : cet attribut est remplacé par l'attribut supannEntiteAffectation

Sémantique : login de l'utilisateur

Branche DIT : ou=people

Origine : SupAnn v1 (supannPerson)

Valuation : monovalué

Obligatoire : Non

Contenu : Cet attribut PEUT contenir un alias, différent de l'uid que l'usager saisit lorsqu'il se connecte à l'ENT de son établissement. Il est unique dans l'établissement et peut être changé directement par l'usager (à condition de rester unique), selon la politique de l'établissement.

Voir aussi : eduPersonPrincipalName, uid

Sémantique : autre(s) adresse(s) de courrier électronique

Branche DIT : ou=people

Origine : SupAnn 2009 (dérivé d'inetOrgPerson)

Valuation : multivalué

Obligatoire : Non

Contenu : Chaîne de caractères au format RFC822. Cet attribut est destiné à contenir les différentes adresses de courrier électronique, autres que l'adresse institutionnelle contenue dans l'attribut mail, gérées et validées par l'établissement (alias de messagerie locale). Il doit y avoir unicité de valeur au sein de l'annuaire.

Remarques : l'attribut mailAlternateAddress n'a pas été retenu car il semble y en avoir plusieurs définitions et qu'au niveau du schéma il est autonome (descend de top) contrairement à supannAutreMail qui descend de mail (des recherches sur mail rendent également les valeurs de supannAutreMail).

Voir aussi : mail, mailForwardingAddress, supannMailPerso

Sémantique : autres téléphones

Branche DIT : ou=people

Origine : SupAnn v1 (supannPerson)

Valuation : multivalué

Obligatoire : Non

Contenu : téléphones fixes autres que le téléphone principal. Même syntaxe que TelephoneNumber.

Voir aussi : facsimileTelephoneNumber, mobile, telephoneNumber

Sémantique : civilité

Branche DIT : ou=people

Origine : SupAnn v1 (supannPerson)

Valuation : monovalué

Obligatoire : Non

Contenu : « M. », « Mme » ou « Mlle » (ne pas oublier le point après le M pour monsieur)

Voir aussi : title

Sémantique : identifiant d'entité au sein de l'annuaire

Branche DIT : ou=structures

Origine : SupAnn 2008 (supannEntite)

Valuation : monovalué

Obligatoire : Oui

Contenu : code interne à l'établissement identifiant de façon unique les différentes entités (structures, instances électives, etc.) où exercent les personnes

Exemple : “z-385”

Remarques :

• cet attribut DOIT servir de RDN pour les objets supannEntite :
• cet attribut n'a aucune utilité en dehors de l'annuaire. Il sert à faire un lien entre objets.

Voir aussi : supannCodeEntiteParent, supannEntiteAffectation, supannRoleEntite

Sémantique : exprime une relation de dépendance avec une ou plusieurs autres entrées

Branche DIT : ou=structures

Origine : SupAnn 2008 (supannEntite)

Valuation : multivalué

Obligatoire : Non

Contenu : une ou plusieurs des valeurs de l'attribut supannCodeEntite d'autre(s) entrée(s)

Exemple : “z-385”

Usage : pages jaunes, organigramme d'établissement, etc.

Remarques : pour trouver les “fils” d'une entrée il suffit de faire une recherche sur les entrées dont l'attribut supannCodeEntiteParent contient le supannCodeEntite de l'entrée considérée

Voir aussi : supannCodeEntite

Sémantique : code INE pour les étudiants.

Branche DIT : ou=people

Origine : SupAnn v1 (supannPerson)

Valuation : multivalué mais ne devrait contenir qu'une valeur

Obligatoire : Non

Contenu : code Identifiant National Etudiant (INE). Il DOIT être renseigné si l'attribut eduPersonAffiliation contient student.

Exemple : “1499081132N”

Voir aussi : supannRefId

Sémantique : corps d'appartenance d'un agent

Branche DIT : ou=people

Origine : SupAnn 2009

Valuation : monovalué

Obligatoire : Non

Contenu : Contenu étiqueté (“NCORPS”), code issu de la colonne “CORPS” de la table “N_CORPS” du domaine “Gestion du personnel” de la BCN (http://www.infocentre.education.fr/bcn/domaine/voir/id/30#)

Nomenclature : table “N_CORPS” du domaine “Gestion du personnel” de la Base Centrale des Nomenclatures

Exemples :

• ”{NCORPS}836” pour Ingénieur de recherche
• ”{NCORPS}024” pour Agent comptable d'université
• ”{NCORPS}301” pour Maître de Conférence des universités

Sémantique : identifiant d'employé

Branche DIT : ou=people

Origine : SupAnn v1 (supannPerson)

Valuation : multivalué mais ne devrait contenir qu'une valeur

Obligatoire : Non

Contenu : identifiant de l'employé dans le logiciel de gestion du personnel de l'établissement

Voir aussi : supannRefId, supannEtuID

Sémantique : représente la ou les affectations de la personne dans un établissement, une composante, service, etc.

Branche DIT : ou=people

Origine : SupAnn 2008 (supannPerson)

Valuation : multivalué

Obligatoire : Non

Contenu : identifiant d'entité interne (service, composante, instance élective, UFR, etc.), c'est-à dire une des valeurs de supannCodeEntite

Exemple : “z-385”

Remarques :

• il peut être utilisé aussi bien pour les personnels (structure d'affectation) que pour les étudiants (structure d'inscription). Il remplace supannAffectation qui est considéré comme obsolète.
• Il est vivement conseillé d'utiliser supannEntiteAffectation,plutôt que d'utiliser eduPersonOrgUnitDN ou eduPersonOrgDN pour des raisons de portabilité d'applications.

Voir aussi : eduPersonOrgDN, eduPersonOrgUnitDN, supannAffectation, supannCodeEntite, supannEntiteAffectationPrincipale, supannEtuInscription,

Sémantique : affectation principale de la personne

Branche DIT : ou=people

Origine : SupAnn 2008 (supannPerson)

Valuation : monovalué

Obligatoire : Non

Contenu : texte (une des valeurs de supannEntiteAffectation (pour recherche))

Exemple: “z-385”

Voir aussi : supannEntiteAffectation

Sémantique : établissement (ou “unité”) de rattachement administratif de la personne

Branche DIT : racine/ou=people/ou=structures

Origine : SupAnn 2008 (supannPerson et supannOrg)

Valuation : multivalué

Obligatoire : Demandé

Contenu :

• quand utilisé dans supannPerson : code de l'établissement de rattachement administratif de la personne ;
• quand utilisé dans supannOrg : code de l'établissement qui est décrit.

La valeur est préfixée par l'origine du code :

• {UAI} pour les codes UAI ;
• {SIRET} pour les codes SIRET ;
• {CNRS} pour code LABINTEL provenant du CNRS ;
• {INRIA} pour code provenant de l'INRIA ;
• {INSERM} pour code provenant de l'INSERM ;
• {INRA} pour code provenant de l'INRA ;
• {AUTRE} pour autre provenance.

Nomenclatures :

Le contenu de cet attribut fait référence aux nomenclatures suivantes :

• UAI : nomenclature maintenue par la BCN ;
• SIRET : nomenclature maintenue par l'INSEE.

Les nomenclatures de type CNRS, INRIA, INSERM, INRA, etc. sont des nomenclatures internes sous la responsabilité des organismes précisés.

Exemples :

• ”{UAI}0350936C” pour désigner l'université de Rennes 1 ;
• ”{SIRET}18004312700067” pour désigner l'AMUE ;
• ”{CNRS}MOY1400” pour désigner la délégation régionale de Toulouse du CNRS.

Remarques

Cet attribut remplace supannOrganisme qui utilisait le préfixe “EES” et qui était monovalué ; il est désormais considéré comme obsolète.
Le code UAI doit être utilisé pour les établissements d'enseignement supérieur qui doivent tous en posséder un.
Pour les organismes de recherche (CNRS, INRIA, etc.) le préfixe correspondant doit être utilisé, suivi d'un code issu de la nomenclature propre à l'organisme pour désigner ses entités.

Voir aussi : eduPersonOrgDN, supannEtuInscription, supannOrganisme

Sémantique : l'année de début de l'année universitaire concernée

Branche DIT : ou=people

Origine : SupAnn 2008 (supannPerson)

Valuation : multivalué

Obligatoire : Non

Contenu : les quatre chiffres de l'année de rentrée. Exemple, pour l'année universitaire 2007-2008 : “2007”.

Remarques : si l'annuaire contient l'historique des inscriptions des étudiants cet attribut peut contenir d'autres valeurs que l'année universitaire en cours

Voir aussi : supannEtuCursusAnnee, supannEtuInscription, supannEtuRegimeInscription

Sémantique : type de cursus (L, M, D ou X, ...) ainsi que l'année dans le diplôme.

Branche DIT : ou=people

Origine : SupAnn 2008 (supannPerson)

Valuation : multivalué

Obligatoire : Non

Contenu : syntaxe sur deux caractères “Xn” où X est choisi parmi les valeurs L, M, D, X et n représente l'année en cours dans le diplôme. Si l'année n'est pas connue n peut être omis.

Nomenclatures :
Elle sera maintenue par SupAnn pour le premier caractère. Les valeurs actuellement définies sont :

• “L” pour Licence ;
• “M” pour Master ;
• “D” pour Doctorat ;
• “X” pour tout autre catégorie de diplôme ;
• “B” pour préciser le cas échéant le nombre d'années après le BAC.

Exemple : ”{SUPANN}L3” pour troisième année de Licence

Remarques : les cursus qui ne correspondent pas au schéma LMD (IUT, diplômes d'ingénieur, études de médecine) pourront utiliser la notation “Xn” pour indiquer l'année dans le diplôme ; l'attribut supannEtuDiplome fournira plus de précisions sur le diplôme auquel on se réfère.

Voir aussi : supannEtuAnneeInscription, supannEtuInscription, supannEtuRegimeInscription

Sémantique : diplôme préparé par l'étudiant

Branche DIT : ou=people

Origine : SupAnn 2008 (supannPerson)

Valuation : multivalué

Obligatoire : Non

Contenu : code du diplôme SISE (table N_DIPLOME_SISE), codé sur sept chiffres, à défaut code interne (issu d'application métier par exemple)
Contenu étiqueté pour identifier l'origine de la nomenclature

Nomenclatures : nomenclature SISE de la Base Centrale des Nomenclatures

Exemples :

• ”{SISE}2001169” pour MATHEMATIQUES ET APPLICATIONS (le type correspondant à ce diplôme SISE est un Magistère, dont le code est “FE”) ;
• ”{SISE}2001350” pour la licence de Mathématiques Appliquées aux Sciences Sociales ;
• ”{UAI:0350936C}SM203” pour “Master biologie mention biologie spécialité génomique fonctionnelle et santé” de l'université de Rennes 1.

Remarques

Le “Diplôme” est un titre délivré par l'établissement après validation des enseignements d'une ou plusieurs étapes.
Au diplôme peut être associée au moins une version de diplôme, qui est une description détaillée du diplôme à un instant donné. La “Version de diplôme” permet de distinguer des contenus différents pour un même diplôme.
Le diplôme se décompose en étapes.
A un diplôme correspond un code, un type de diplôme et deux intitulés.
Deux catégories de codes de diplômes : les codes pour les diplômes de niveau “national” et les codes pour les diplômes de niveau “établissement”. Le code des diplômes d'établissement commence par 9. La source des codes de diplôme est SISE.

Voir aussi : supannEtuEtape, supannEtuInscription, supannEtuSecteurDisciplinaire, supannEtuTypeDiplome

Sémantique : description générique du contenu d'un enseignement avec un fort niveau de granularité

Branche DIT : ou=people

Origine : SupAnn 2008 (supannPerson)

Valuation : multivalué

Obligatoire : Non

Contenu : l'élément pédagogique est une description générique du contenu d'un enseignement qui permet à un établissement de décrire ses enseignements avec le niveau de granularité désiré. Un élément pédagogique peut lui-même se subdiviser en éléments pédagogiques plus fins. On pourra trouver des éléments pédagogiques de différentes natures :

• SEMESTRE : l'élément pédagogique correspond à un semestre d'une étape d'un diplôme. Un semestre pourra contenir un ensemble d'UE ;
• MATIERE : dans ce cas il s'agit d'un contenu thématique/scientifique ;
• UE (Unité d'Enseignement) : notion plus fine que les deux précédentes. UE peut elle-même contenir des éléments pédagogiques de plus bas niveau comme COURS, TD, etc. qui ne seront pas considérés dans ces recommandations.

Nomenclatures : code interne d'applications métier. En effet, il n'existe pas de nomenclature SISE pour les éléments pédagogiques.

Exemple :

• ”{UAI:0171463Y}4929” pour l'Unité d'Enseignement “Introduction à l'informatique” du parcours commun de la licence Sciences et Technologies mention Informatique, Mathématiques et Application à l'Economie (IMAE) de l'établissement ayant le code UAI 0171463Y ;

Remarques

Les établissements utilisant l'application Cocktail-Scolarix pourront alimenter cet attribut avec les informations de type “Unité d'Enseignement”

Voir aussi : supannEtuEtape, supannEtuInscription

Sémantique : l'étape peut être considérée comme un fractionnement (semestre, année, etc.) dans le temps d'un enseignement conduisant à un diplôme

Branche DIT : ou=people

Origine : SupAnn 2008 (supannPerson)

Valuation : multivalué

Obligatoire : Non

Contenu : contenu étiqueté pour identifier l'origine de la nomenclature

Nomenclatures : code interne pouvant provenir d'applications métier. En effet, il n'existe pas de nomenclature SISE pour les éléments pédagogiques

Exemples :

• ”{UAI:0350936C}SM2032” pour “Master STS m. biologie génomique fonct. et santé S3-S4” de l'université de Rennes 1 ;
• ”{UAI:0171463Y}401” pour le parcours “Pluridisciplinaire géosciences” de la licence Physique et Chimie de la Matière et de la Terre (exemple d'un établissement utilisant Cocktail-Scolarix).

Remarques :

• “version d'étape” : dans le cas d'Apogée, à chaque étape est associée au moins une version d'étape. Dans ce cas supannEtuEtape pourra être complété par la version d'étape. Il est proposé de séparer l'étape et la version d'étape par un ”-”. Une version d'étape permet de suivre l'évolution dans le temps du contenu d'une étape ou bien de décrire des étapes associées à des contenus pédagogiques différents au même moment. Les étudiants sont inscrits administrativement à une ou plusieurs versions d'étape. Chaque version d'étape se décompose en listes d'éléments pédagogiques.
  
• les établissements utilisant l'application Cocktail-Scolarix pourront alimenter l'attribut supannEtuEtape avec les informations de type “parcours”.

Voir aussi : supannEtuElementPedagogique, supannEtuInscription

Sémantique : identifiant de scolarité

Branche DIT : ou=people

Origine : SupAnn v1 (supannPerson)

Valuation : multivalué mais ne devrait contenir qu'une valeur

Obligatoire : Non

Contenu : identifiant de l'étudiant dans le logiciel de gestion de scolarité de l'établissement

Voir aussi : supannRefId, supannEmpId

Sémantique : chaque valeur de cet attribut composite décrit une inscription pour un étudiant en liant entre elles des informations “élémentaires” (discipline, diplôme, établissement, etc.) que l'on pourra également trouver en tant qu'attribut élémentaire.
Chaque valeur de supannEtuInscription représente un “profil” pouvant être utilisé pour du contrôle d'accès à des ressources, de la personnalisation de pages, etc.
Un étudiant pourra avoir plusieurs profils en fonction de ses différentes inscriptions.

Branche DIT : ou=people

Origine : SupAnn 2008 (supannPerson)

Valuation : multivalué

Obligatoire : Non

Contenu :

Attribut composite regroupant, de façon ordonnée, les attributs (étiquetés) suivants :

1. supannEtablissement (etab) - obligatoire ;
2. supannEtuAnneeInscription (anneeinsc) - obligatoire ;
3. supannEtuRegimeInscription (regimeinsc) - obligatoire ;
4. supannEtuSecteurDisciplinaire (sectdisc) - obligatoire ;
5. supannEtuTypeDiplome (typedip) - obligatoire ;
6. supannEtuCursusAnnee (cursusann) - obligatoire ;
7. supannEntiteAffectation (affect) - facultatif ;
8. supannEtuDiplome (diplome) - faculatif ;
9. supannEtuEtape (etape) - facultatif ;
10. supannEtuElementPedagogique (eltpedago) - facultatif.

Syntaxe :

[etab=<supannEtablissement>][anneeinsc=<supannEtuAnneeInscription>]
[regimeinsc=<supannEtuRegimeInscription>][sectdisc=<supannEtuSecteurDisciplinaire>]
[typedip=<supannEtuTypeDiplome>][cursusann=<supannEtuCursusAnnee>]
[affect=<supannEntiteAffectation>][diplome=<supannEtuDiplome>]
[etape=<supannEtuEtape>][eltpedago=<supannEtuElementPedagogique>]

Exemples :

• ”[etab={UAI}0860856N][anneeinsc=2007][regimeinsc={SISE}10][sectdisc={SISE}02][typedip={SISE}FC][cursusann=M2][diplome={SISE}224522]”
  définissant la formation initiale ({SISE}10), suivie en 2007, à l'Université de Poitiers ({UAI}0860856N), préparant un DEA de physique ({SISE}224522), secteur disciplinaire physique ({SISE}O2), type de diplôme DEA ({SISE}FC), cursus M2.

• ”[etab={UAI}0131843H][anneeinsc=2007][regimeinsc={SISE}10][sectdisc={SISE}04][typedip={SISE}YA][cursusann=D3][affect=56R17][diplome={SISE}2001099][etape={UAI:0131843H}B8EFAI-B8EFA3]”
  définissant l'étape “B8EFA3” du diplôme “B8EFAI”. Il s'agit d'un doctorat d'université (”{SISE}YA”) en mathématiques appliqués et en sciences sociales (”{SISE]04”) suivi à l'université d'Aix Marseille 2 (”{UAI}0131843H”) dans l'UFR de code “56R17”.

Remarques :

• les champs marqués “obligatoire” doivent être remplis et cela suppose l'existence des valeurs concernées dans les attributs élémentaires correspondants ;
• à une combinaison donnée de valeurs de cet attribut correspond un “profil”. Seules les combinaisons significatives ont vocation à faire l'objet d'une valeur de cet attribut. Une multiplication inutile de valeurs pourrait alourdir l'annuaire et son fonctionnement ;
• l'attribut supannEtuInscription inclus des informations provenant de deux types “formels” d'inscriptions :
  • “inscription administrative” : elle permet à l'étudiant de s'inscrire à une étape de diplôme; elle est assujettie au versement de droits d'inscription,
  • “inscription pédagogique” : elle permet à l'étudiant de préciser son choix d'étapes pour s'inscrire aux éléments pédagogiques correspondants ou prendre en compte ses résultats antérieurs sur ces éléments.

Voir aussi : exemple complet en annexe 1

Sémantique : correspond au “type d'enseignement” SISE dont les valeurs possibles sont : formation initiale, formation continue, formation à distance, etc.

Branche DIT : ou=people

Origine : SupAnn 2008 (supannPerson)

Valuation : multivalué

Obligatoire : Non

Contenu : code du régime d'inscription SISE (table N_REGIME_INSCRIPTION), codé sur deux chiffre.
Contenu étiqueté pour identifier l'origine de la nomenclature.

Nomenclatures : table N_REGIME_INSCRIPTION de la nomenclature SISE de la Base Centrale des Nomenclatures

Exemples :

• ”{SISE}10” pour “formation initiale” ;
• ”{SISE}21” pour “formation continue diplômante”.

Remarques: S'il n'existe pas de valeur appropriée le champ doit contenir ”{INCONNU}”.

Voir aussi : supannEtuDiplome, supannEtuInscription

Sémantique : secteur disciplinaire de diplôme ou d'enseignement

Branche DIT : ou=people

Origine : SupAnn 2008 (supannPerson)

Valuation : multivalué

Obligatoire : Non

Contenu : code du secteur disciplinaire SISE (colonne SECTEUR DISCIPLINAIRE SISE de la table N_SECTEUR_DISCIPLINAIRE_SISE du domaine ETUDIANT de la BCN, actuellement codé sur 2 chiffres).
Contenu étiqueté pour identifier l'origine de la nomenclature.

Nomenclatures : nomenclature SISE de la BCN (Base Centrale des Nomenclatures)

Exemples :

• ”{SISE}27” pour “Histoire”
• ”{SISE}06” pour “Sciences de la vie”

Remarques : Le groupe de travail supann2-tech a choisi d'utiliser la notion de secteur disciplinaire SISE, plutôt que la notion de discipline SISE car elle est plus précise et semblait de ce fait plus utile aux applications clientes de SupAnn. Il existe une table de correspondance SISE permettant d'associer une discipline à chaque secteur disciplinaire.
De fait une discipline peut être considérée comme un regroupement de secteurs disciplinaires. Exemple: ”{SISE}11” pour Médecine.

S'il n'existe pas de valeur appropriée le champ doit contenir ”{INCONNU}”.

Voir aussi : supannEtuDiplome, supannEtuInscription

Sémantique : type ou catégorie du diplôme préparé

Branche DIT : ou=people

Origine : SupAnn 2008 (supannPerson)

Valuation : multivalué

Obligatoire : Non

Contenu : contenu étiqueté pour identifier l'origine de la nomenclature.
Code du type de diplôme SISE (table N_TYPE_DIPLOME_SISE), codé sur deux caractères (à ce jour la table comporte 147 valeurs).

Nomenclature : nomenclature SISE de la Base Centrale des Nomenclatures

Exemples :

• ”{SISE}DC” pour “Maîtrise” ;
• ”{SISE}CB” pour “DUT” ;
• ”{SISE}MA” pour “DESC Médecine groupe 1”.

Voir aussi : supannEtuDiplome, supannEtuInscription, supannEtuSecteurDisciplinaire

Sémantique : administrateurs

Branche DIT : ou=groups

Origine : SupAnn v1 (supannGroupe)

Valuation : multivalué

Obligatoire : Non

Contenu : DN des personnes ou des groupes habilités à ajouter et supprimer des membres au groupe

Voir aussi : supannGroupeDateFin, supannGroupeLecteurDN

Sémantique : fin de validité du groupe

Branche DIT : ou=groups

Origine : SupAnn v1 (supannGroupe)

Valuation : monovalué

Obligatoire : Non

Contenu : date après laquelle le groupe n'est plus valide

Voir aussi : supannGroupeAdminDN, supannGroupeLecteurDN

Sémantique : entrées autorisées à consulter le contenu du groupe

Branche DIT : ou=groups

Origine : SupAnn v1 (supannGroupe)

Valuation : multivalué

Obligatoire : Non

Contenu : DN des personnes ou des groupes habilités à consulter les membres du groupe au niveau de l'établissement

Voir aussi : supannGroupeAdminDN, supannGroupeDateFin

Sémantique : entrée annuaire en «liste rouge»

Branche DIT : ou=people

Origine : SupAnn v1 (supannPerson)

Valuation : monovalué

Obligatoire : Demandé

Contenu : DOIT contenir une information sur le souhait de la personne de figurer en liste rouge. Booléen à VRAI pour les personnes figurant en liste rouge

Sémantique : adresse de courrier électronique privée

Branche DIT : ou=people

Origine : SupAnn 2008 (supannPerson)

Valuation : multivalué

Obligatoire : Non

Contenu : chaîne de caractères au format RFC822

Exemple : “Vincent.Poursan@free.fr”

Remarque : cet attribut PEUT être renseigné par la personne “titulaire” de l'entrée. Il ne doit donc pas servir au routage de ses courriers électroniques.

Voir aussi : mail, mailForwardingAddress

Origine : SupAnn v1 (supannPerson)

Remarque : cet attribut est remplacé par l'attribut supannEtablissement

Sémantique : responsable de l'entrée

Branche DIT : ou=people

Origine : SupAnn v1 (supannPerson)

Valuation : multivalué

Obligatoire : Non

Contenu : DN de la personne qui est « responsable » de la création de l'entrée dans l'annuaire. Doit être renseigné en particulier si eduPersonAffiliation ne contient pas “member”, c'est à dire pour les personnes extérieures à l'établissement.

Sémantique : identifiants/liens avec d'autres bases du SI

Branche DIT : ou=people/ou=structures/ou=groups

Origine : SupAnn 2009 (supannPerson, supannEntite, supannGroupe)

Valuation : multivalué

Obligatoire : Non

Contenu : contenu étiqueté, identifiant(s)/clés/indexes provenant d'autres bases du (d'un) SI
Étiquettes prédéfinies : {APOGEE}, {HARPEGE}, {SIFAC}, {NABUCO}, {SCOLARIX}, {MANGUE}, {PAPAYE}, {GRHUM}, {ASTRE}, {JERICO}, {GEISHA}, {POEMS}, {HELICO}, {INE},
{UAI:<code UAI>:<étiquette>} pour indiquer que l'identifiant provient du SI d'un autre établissement (exemple : {UAI:0440984F:APOGEE})

Exemples :

• ”{APOGEE}12345” pour faire le lien avec le dossier correspondant dans APOGEE
• ”{UAI:0131842G:MANGUE}58973” pour faire le lien avec un dossier de personnel de l'Université de Provence géré sous MANGUE
• ”{UAI:9830445S:SCOLARIX}158657” pour faire le lien avec un dossier d'étudiant de Nouvelle-Calédonie géré sous SCOLARIX

Remarques : cet attribut multivalué peut recevoir tout identifiant ou index permettant de faire le lien avec les autres bases de données d'un SI (local ou extérieur). Il peut en particulier compléter (ou remplacer) les attributs supannEtuID, supannEmpId, supannCodeINE...

Voir aussi : supannEtuID, supannEmpId, supannCodeINE

Origine : SupAnn v1 (supannPerson)

Remarque : cet attribut est remplacé par l'attribut supannRoleGenerique qui, associé à “supannTypeEntite” au sein de l'attribut composite “supannRoleEntite”, précise le rôle dans une entité.

Sémantique : rôle contextuel (relatif à une entité donnée). Rôle pouvant être structurel, électif, etc.

Branche DIT : ou=people

Origine : SupAnn 2008, modifié SupAnn 2009 (supannPerson)

Valuation : multivalué

Obligatoire : Non

Contenu : Attribut composite multivalué regroupant, de façon ordonnée, les attributs (étiquetés) suivants :

• supannRoleGenerique (role générique) - obligatoire ;
• supannTypeEntiteAffectation (type d'entité) - obligatoire ;
• supannEntiteAffectation (code de l'entité) - facultatif.

Syntaxe :

[role=supannRoleGenerique][type=supannTypeEntiteAffectation]
[code=supannEntiteAffectation]

Exemple : [role={SUPANN}D60][type={SUPANN}S201][code=z-385]

Remarques :

Cet attribut associe les rôles/fonctions des personnels, le type d'entités et les entités d'exercice de ces rôles/fonctions. Les deux premiers attributs sont intéropérables, le troisième n'a de sens que dans l'établissement d'origine.
SupAnn 2009 a remplacé les attributs initiaux supannTypeEntite et supannCodeEntite par supannTypeEntiteAffectation et supannEntiteAffectation.

Voir aussi : supannRoleGenerique, supannTypeEntiteAffectation, supannEntiteAffectation, supannTypeEntite, supannCodeEntite

Sémantique : rôle(s) générique(s) de la personne dans l'établissement

Branche DIT : ou=people

Origine : SupAnn 2008 (supannPerson)

Valuation : multivalué

Obligatoire : Non

Contenu : étiqueté ({SUPANN}), colonne FONCTION_ADMINISTRATIVE de la nomenclature SupAnn référencée ci-dessous.

Nomenclatures : Une nomenclature spécifique a été élaborée par supann-tech sur la base de la nomenclature N_FONCTION_ADMINISTRATIVE de la BCN. Elle doit à terme être intégrée dans le “circuit officiel”. En attendant elle est accessible via http://www.cru.fr/documentation/supann/nomenclatures-proposees.

Remarques :

• A la différence de SupAnn v1 la nouvelle nomenclature définit des rôles indépendamment des entités dans lesquelles elles sont exercées.
• Les anciennes valeurs définies par SupAnn v1 peuvent être conservées en utilisant l'attribut supannRole (rendu obsolète), ceci afin d'assurer la compatibilité avec des applications existantes.

Exemples :

• ”{SUPANN}D60” pour directeur de département
• ”{SUPANN}P00” pour président

Voir aussi : supannRoleEntite, supannRole

Sémantique : type de l'entité : composante, service commun, UFR, service central, instance élective, etc.

Branche DIT : ou=structures

Origine : SupAnn 2008 (supannEntite)

Valuation : multivalué

Obligatoire : Non

Contenu : contenu étiqueté ({SUPANN}) issu de la nomenclature spécifique référencée ci-dessous.

Nomenclatures : Une nomenclature spécifique a été élaborée par supann-tech. Elle doit à terme être intégrée dans le circuit officiel de la BCN. En attendant elle est accessible via http://www.cru.fr/documentation/supann/nomenclatures-proposees.

Remarques : est utilisé dans l'attribut composite supannRoleEntite

Exemples :

• ”{SUPANN}S231” pour service général
• ”{SUPANN}S208” pour IUFM

Voir aussi : supannRoleEntite, supannTypeEntiteAffectation

Sémantique : type de la ou des entités d'affectation d'une personne

Branche DIT : ou=people

Origine : SupAnn 2009 (supannPerson)

Valuation : multivalué

Obligatoire : Non

Contenu : voir l'attribut supannTypeEntite

Nomenclatures : voir l'attribut supannTypeEntite)

Exemple : {SUPANN}S201 pour UFR

Remarques : est utilisé dans l'attribut composite supannRoleEntite et contient toute valeur pouvant etre prise par supannTypeEntite

Voir aussi : supannRoleEntite, supannEntiteAffectation, supannTypeEntite

Sémantique : numéro de téléphone principal

Branche DIT : racine/ou=people/ou=structures

Origine : RFC4519 (inetOrgPerson, organization, organizationalUnit)

Valuation : multivalué

Obligatoire : Non

Contenu : numéro de téléphone principal. Attention, il DEVRAIT être monovalué dans SupAnn, contrairement au RFC 4519 (on ne peut pas sinon distinguer le téléphone principal des autres). Les autres numéros de téléphone de la personne sont dans supannAutreTelephone.
Format : +xx x xx xx xx xx (CCITT Rec. E123).

Exemple : +33 1 63 70 62 40.
Les autres formats sont acceptés : sera affiché sur l'interface Web tel qu'il est alimenté.
On peut ajouter pNNNN pour le numéro de poste.

Voir aussi : facsimileTelephoneNumber, mobile, supannAutreTelephone

Sémantique : titre

Branche DIT : ou=people

Origine : RFC4519 (inetOrgPerson)

Valuation : multivalué

Obligatoire : Non

Contenu : titre de la personne

Exemple : docteur, professeur, directeur, président, etc.

Voir aussi : supannCivilite

Sémantique : identifiant unique

Branche DIT : ou=people

Origine : RFC2798 (inetOrgPerson)

Valuation : multivalué mais ne devrait contenir qu'une valeur

Obligatoire : Demandé

Contenu : DOIT être utilisé comme RDN pour les entrées de personnes, contenu indifférent, aussi court que possible. Comme l'attribut uid peut être utilisé comme identifiant dans des applications, il est important que la valeur de cet attribut ne soit pas réassignée à une autre personne d'une année à l'autre. Un établissement devra donc faire son possible pour garantir cette qualité de non-réassignabilité de l'attribut uid ou la garantir pendant une période donnée (1 an, 5 ans, 10 ans). L'utilisation d'un uid d'utilisateur incrémental et opaque peut aider à atteindre cet objectif.

Voir aussi : eduPersonPrincipalName, supannAliasLogin,

Sémantique : certificat X.509

Branche DIT : ou=people

Origine : RFC4519 et RFC2798 (inetOrgPerson)

Valuation : multivalué

Obligatoire : Non

Contenu : PEUT contenir le(s) certificat(s) X.509 de la personne

Sémantique : mot de passe

Branche DIT : ou=people

Origine : RFC2307 (person)

Valuation : multivalué

Obligatoire : Non

Contenu : le mot de passe PEUT être stocké dans l'annuaire (il peut aussi être stocké au niveau du serveur d'authentification). Il DOIT être conforme à la syntaxe définie dans le RFC 2307. Il NE DOIT PAS être stocké en clair ou circuler en clair sur le réseau. Tout « bind » non anonyme doit s'effectuer sur un canal chiffré.

Les tableaux suivants tentent d'énumérer les différentes catégories de personnes que l'on peut rencontrer à l'université et d'indiquer les valeurs d'eduPersonAffiliation correspondantes. Certaines personnes peuvent d'ailleurs faire partie de plusieurs catégories (c'est fréquemment le cas) et donc cumuler les valeurs en conséquence. Exemples : ancien étudiant + chercheur, émérite + retraité, maître de stage interne, etc. Attention, dans ces cas, à respecter l'exclusion entre member et affiliate.

Ce tableau part du tableau relatif à l'attribut eduPersonAffiliation tel que spécifié dans SupAnn 2008, et se trouve complété ici par deux colonnes à gauche:

• la colonne “Cat” qui permet d'identifier plus facilement la catégorie concernée
• la colonne “Source” qui indique les bases métiers pouvant être utilisées comme source des données de l'annuaire pour telle ou telle catégorie de personne.

• Géré : étudiant inscrit dans l'établissement ou/et personnel payé par l'établissement
• Hébergé : enregistré dans la (les) base(s) de gestion du personnel mais non rémunéré par l'établissement
• Non hébergé : absent de la (les) base(s) de gestion du personnel de l'établissement

Signification des sigles dans la colonne “Source” (bases servant de source d'alimentation de l'annuaire):

• SCO : outil de gestion de la SCOlarité et des étudiants, des apprenants, de la formation continue,...
• RH: outil de gestion des Ressources Humaines;
• RE: outil de gestion de la REcherche, (utile pour savoir si un chercheur, doctorant est hébergé dans un laboratoire “officiel” par exemple);
• HC : heures complémentaires
• REF: un REFérentiel autre pouvant une base (une table d'une base, ...) contenant :
  • les “anciens” (Alumni, Retraités, Emérite, ...)
  • les personnes en autoformation (non diplomante) ou formation continue, ...
  • les stagiaires, les invités, ...
  • les personnalités et contacts extérieurs (membres du CA, ...)
  • les visiteurs (droits bibliothèque, WiFi, ...)
  • base issue d'un autre établissement
  • etc.

Les colonnes “Stu”, “F”, “E”, “A”, “AL”, “R”, “RD”, “Eus”, “M”, “Sta”, “T” et “RR” correspondent respectivement aux valeurs student, faculty, employee, affiliate, alum, researcher, retired, emeritus, member, staff, teacher et registered_reader.

Voir la définition d'eduPersonAffiliation dans le chapitre 7 pour les sémantiques associées.

A noter que staff, pour des raisons de compatibilité internationale, a été réintroduit (avec la précédente définition de employee) et que library-walk-in n'est plus utilisé.