Vous êtes ici: index » documentation » supann » 2008 » documentcomplet
Table des matières



Recommandations SupAnn 2008

1. Contexte, objectifs, démarche

1.1. Contexte

Les Technologies de l'Information et de la Communication font aujourd'hui partie intégrante du fonctionnement des établissements d'enseignement supérieur. Les services et les ressources numériques accessibles par les étudiants, enseignants, chercheurs et personnels administratifs recouvrent l'ensemble des domaines fonctionnels.

Les ressources numériques et les services numériques d'un établissement sont généralement accessibles via un dispositif de type ENT (Espace Numérique de Travail) via l'Intranet ou au travers de l'Internet. L'accès via Internet ouvre la voie au nomadisme, au télétravail, au partage des ressources entre établissements, il permet d'élargir l'offre de formation à de nouvelles population (EAD/FOAD) et de renforcer les relations de l'établissement avec le grand public et le tissu socio-économique.

Il y a un intérêt stratégique à faciliter l'accès aux services et aux ressources numériques de l'établissement mais cet objectif ne doit pas éluder la nécessité de contrôler les accès pour certaines ressources à protéger et qui ne doivent être accessibles qu'aux personnes dûment autorisées.

Le contrôle d'accès aux ressources et services se traduit généralement par la mise en œuvre de mécanismes d'identification, d'authentification et de gestion des autorisations s'appuyant sur un ensemble de données géré au sein d'un référentiel de type « annuaire ».

Les annuaires, initialement mis en œuvre pour des fonctions contrôle d'accès et de pages blanches ont vu croître la liste des applications et des services qui en dépendent. Ils occupent une place cruciale au coeur du « Système d'Information Global » (SIG) des établissements. De leur qualité (complétude, exactitude et fiabilité) dépend le bon fonctionnement des Systèmes d'Informations.

Pour différentes raisons il est nécessaire d'avoir un cadre de cohérence commun matérialisant la structure et le contenu de ces annuaires: lisibilité des données, portabilité des applications, faciliter les échanges entre établissements.

Un ensemble de documents normatifs (RFC LDAP) élaborés au niveau international a établi un premier cadre pour la mise en oeuvre des annuaires. Cet effort initial a du être complété afin de satisfaire les spécificité de communautés particulières.

Pour les Établissements d'Enseignement Supérieur (EES) les premières recommandations appelées SupAnn v1 furent publiées en juillet 2003. Elles définissaient un ensemble d'éléments jugés suffisants au moment de sa publication. Depuis de nouveaux besoins sont apparus qui justifient la parution de cette nouvelle mouture des recommandations SupAnn appelées SupAnn 2008.

2009/04/14 11:37

1.2. Objectifs

Différents objectifs ont motivé l'élaboration des premières recommandations SupAnn v1, parmi lesquels il faut citer les principaux :

  • proposer aux établissements un cadre de cohérence pour la mise en œuvre de leurs annuaires respectifs via la spécification d'un noyau LDAP commun ;
  • favoriser la portabilité des logiciels utilisés par les EES, en homogénéisant les schémas d'annuaires dans les établissements. On pourra ainsi inclure nativement dans ces logiciels les interfaces adéquates avec l'annuaire et éviter des modifications trop profondes en aval ;
  • aboutir à une meilleure homogénéité des contenus d'annuaires dans les EES afin de faciliter la portabilité des logiciels et progiciels inter-agissant avec l'annuaire. Ceci permet d'inclure dans les logiciels en amont de leur livraison aux établissements les interfaces adéquates avec l'annuaire et évite ainsi aux établissements d'avoir à modifier profondément certains logiciels qui leur sont livrés ;
  • converger vers des compétences internes similaires en matière d'annuaire, afin de faciliter le travail des responsables annuaires au niveau opérationnel, et contribuer à accroître et améliorer les possibilités d'échanges entre les différents acteurs du fait de ce langage commun.

Il s'agissait également de sensibiliser les établissements à la nécessité de mettre en œuvre un référentiel central afin de rationaliser leur dispositif d'authentification et de contrôle d'accès ; un seul référentiel garantissant une vision globale de la politique de sécurité notamment, évitant les saisies multiples et les risques d'incohérence.

A ces objectifs, qui restent toujours pertinents, il faut aujourd'hui ajouter le besoin amené par les services de « fédération d'identités » dont la finalité est de permettre un contrôle d'accès à des ressources distantes, basé sur les profils de l'utilisateur issu de l'annuaire de son établissement de rattachement. Ce service impose l'utilisation de schémas d'annuaires communs à l'échelle des EES. En effet, le fonctionnement de la fédération d'identités n'est possible que si les informations consommées par le processus de contrôle d'accès respectent une syntaxe et une sémantique reconnues. La fédération d'identités est un service crucial pour le partage de ressources numériques au niveau des UNR et des UNT ou pour l'accès aux ressources numériques de type revues électroniques.

Il est également important de signaler que depuis la parution des recommandations SupAnn v1 la plupart des établissements avaient étoffé leur parc d'applications et de services requérant des informations de l'annuaire et les attentes de ces applications vis-à-vis de l'annuaire n'ont cessé de se diversifier. Un des objectifs de SupAnn 2008 était donc d'intégrer dans les recommandations SupAnn les données utiles à chaque EES et déjà implémentées dans les annuaires des établissements.

Les établissements d'enseignement supérieur français sont invités à se mettre en conformité avec les orientations présentées dans ce document de recommandations SupAnn 2008. Toutefois les présentes recommandations SupAnn 2008 doivent être considérées comme un ensemble minimum qui peut être complété par des éléments spécifiques à chaque établissement. Un établissement peut donc ajouter dans son annuaire les éléments qu'il juge nécessaires à ses besoins propres.

2009/04/14 11:37

1.3. De SupAnn v1 à SupAnn 2008

Les recommandations SupAnn 2008 ont été élaborées pour répondre aux attentes des établissements. En effet la première version de SupAnn publiée en juillet 2003 définissait un sur-ensemble de eduPerson relativement restreint. La nouvelle mouture aborde plus profondément les aspects métier des établissements d'enseignement supérieur : définition des étudiants, des personnels, des structures. Vous trouverez une description des nouveaux attributs utilisables dans les chapitre 4, 5 et 6.

Outre les nouveautés, le groupe technique SupAnn a également mis à jour, complété, corrigé la définition de certains attributs définis dans SupAnn v1 directement ou définis dans eduPerson. Dans ce cas la ligne directrice a privilégié la compatibilité entre SupAnn v1 et SupAnn 2008. Seuls quelques attributs ont été rendus obsolètes lorsqu'ils n'étaient plus compatibles avec les valeurs, la sémantique ou l'utilisation proposées dans SupAnn v1. Ces attributs, non repris dans SupAnn 2008, ont été remplacés par des attributs sensiblement équivalents (voir liste ci-après). Les établissements PEUVENT cependant continuer à utiliser ces attributs dits «obsolètes» mais ils DOIVENT choisir les nouveaux attributs lors de la conception de nouvelles applications ou dans les contextes d'échanges entre établissements.

Ci-après sont précisés les changements de SupAnn 2008 par rapport à SupAnn v1 et qui sont susceptibles d'induire des modifications dans les annuaires d'établissements afin d'être compatible SupAnn 2008.

Attributs ou valeurs rendus "obsolètes" :

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

Les éléments nouveaux :

  • nouvelle branche du DIT pour définir les entités de l'établissement (ou=structures)
    • 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, eduPersonPrimaryOrgUniDN;
  • nouveaux attributs pour la définition des “adresses email” : supannMailPerso, mailForwardingAddress;
  • nouveaux attributs pour la définition du profil “personnel” : supannRoleGenerique, supannRoleEntite, supannActivite;

Évolution de l'usage de certains attributs :

  • 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)
2009/04/14 11:37

1.4. Processus d'élaboration des recommandations

Étapes de production des recommandations

Ce document a été rédigé en respectant les étapes suivantes :

  • rédaction par le groupe de travail fonctionnel supann2 d'un cahier des charges explicitant les besoins fonctionnels qui ont sous-tendu à l'élaboration de SupAnn 2008 (voir constitution du groupe en annexe 5 );
  • reprise de ce cahier des charges par le groupe technique supann2-tech en vue de l'élaboration du présent document (voir constitution du groupe en annexe 5);
  • pendant la phase d'élaboration, les recommandations ont été scindées en différents volets qui ont fait l'objet d'un appel à commentaire auprès du groupe supann-utilisateurs (liste regroupant les administrateurs d'annuaires des EES) ;
  • intégration, au fur et à mesure, des appels à commentaires, après discussion au sein de supann2-tech ;
  • édition des présentes recommandations en fusionnant les éléments incontournables de SupAnn v1 avec les nouveaux volets ;
  • validation du document par le groupe fonctionnel et par le comité de pilotage des Systèmes d'Information.

Sources d'information, acteurs

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. 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.

Plusieurs catégories d'acteurs ont contribué aux recommandations SupAnn 2008 ou ont été consultées afin d'assister les deux groupes supann2 et supann2-tech :

  • 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.

Évolution des recommandations

Certaines propositions d'évolution pertinentes, issues du groupe technique ou issues de l'appel à commentaire, n'ont pu être exploitées (afin de respecter le calendrier) ; elles ont été mises de côté et seront discutées lors des prochains travaux d'évolution des recommandations SupAnn. La page « Pour SupAnn 2009 » regroupe ces propositions.

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

Principes d'élaboration des recommandations



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

  • compatibilité ascendante maximale avec les précédentes recommandations SupAnn v1 ;
  • articulation avec les recommandations internationales (plus particulièrement Internet2/eduPerson ou Terena/SCHAC) ;
  • 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 2008 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 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.

2009/04/14 11:37

1.5. Conformité à la règlementation

Conformité des annuaires avec la loi "Informatique et Libertés"

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.

Respect des droits des personnes

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

Annuaire des personnels

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.

Annuaire des étudiants

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.

Annuaire des diplômés

Pertinence des données collectées

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)

Durée de conservation des données

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

Attention à avoir une gestion rigoureuse des personnels hébergés, chercheurs invités, professeurs émérites, etc.

Sécurité

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.

Formalités

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.
2009/04/14 11:37


2. Choix techniques

2.1. Choix du protocole LDAP

LDAP est un standard reconnu et, parmi les avantages que comporte son utilisation pour notre communauté, on peut citer :

  • l'utilisation d'un protocole standardisé, ce qui simplifie l'intégration avec les nouvelles briques logicielles ;
  • d'excellentes performances en lecture (comparé à une base de données relationnelle).

LDAP comporte deux volets :

  • un protocole d'accès à l'annuaire ;
  • des méthodes de structuration et de présentation des données.

La partie protocole d'accès, est définie très précisément et de façon complète dans des documents normatifs (les RFCs). Il sera donc identique pour tous et il ne requièrt pas de recommandations complémentaires.

Le présent document explicite des recommandations concernant les classes d'objets, les attributs et la structure d'un annuaire LDAP d'établissement.

2009/04/14 11:37

2.2. Nomenclatures

 

2.3. Etiquetage des attributs

Attributs étiquetés

Pour identifier la nomenclature de provenance, 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
  • CNU : la valeur qui suit est issue du Conseil National des Universités (CNU) à travers une table de la BCN
    • exemple : {CNU}5404
  • 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
  • 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
  • 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.

2009/04/14 11:37

2.4. Profils multiples, attributs composites

Profil multiple

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 figurent à la fois 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.

Attributs composites

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, mais dont l'intitulé est différent (choix d'intitulés 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.

Remarque : un attribut composite peut être valué sans que tous les attributs élémentaires correspondants soient instanciés (exemple : supannTypeEntite dans supannRoleEntite).

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.

2009/04/14 11:37


3. Classes, attributs, DIT, nommage

3.1. Les classes et leurs attributs

Le schéma d'un annuaire a pour objet de répertorier les différentes classes utilisées dans l'annuaire en précisant leur type, les attributs qui leurs sont associés ainsi que les relations éventuelles entre attributs. Le schéma de base SupAnn 2008, présenté dans ces recommandations, pourra être complété en fonction des besoins propres de chaque établissement.

La conformité aux présentes recommandations implique l'utilisation au minimum des classes et attributs ci-après qualifiés de “O” (Obligatoire) ou “D” (Demandé).

Les classes du schéma d'annuaire SupAnn 2008

Le schéma SupAnn 2008 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 2008. 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 2008 :

branches du DITClasses utilisées
L'établissement à la racine de l'annuaire 1)la classe structurelle Organization (RFC 2798)
est la classe de base dont seule une partie des attributs est utilisée;
2) la classe auxiliaire dcObject (RFC2247);
3) la classe auxiliaire eduOrg;
4) la classe auxiliaire supannOrg.
L'établissement dans
la branche « ou=structures »
1) la classe structurelle Organization (RFC 2798)
est la classe de base dont seule une partie des attributs est utilisée;
2) la classe auxiliaire eduOrg ;
3) la classe auxiliaire supannOrg ;
4) la classe auxiliaire supannEntite.
Structures/entités dans
la branche « ou=structures »
1) la classe structurelle OrganizationalUnit (RFC2256)
est la classe de base dont seule une partie des attributs est utilisée;
2) la classe auxiliaire supannEntite.
Les personnes dans
la branche “ou=people“
1) la classe structurelle inetOrgPerson (RFC 2798)
est la classe de base dont seule une partie des attributs est utilisée,
Elle est une sous-classe de OrganizationalPerson (RFC 2256)
qui est elle-même une sous-classe de Person (RFC 2256) ;
2) la classe auxiliaire eduPerson dont seul une partie des attributs est utilisée
3) la classe auxiliaire supannPerson
Les groupes dans
la branche “ou=groups“
1) la classe structurelle groupOfNames (RFC 2256), dont seule une partie des attributs est utilisée ;
2) la classe auxiliaire supannGroupe.

Les attributs utilisés par chaque classe

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 pour les structures

Les attributs utilisés dans la classe organization

Nom attributO/DOrigine
description RFC2256
facsimileTelephoneNumber RFC2256
l RFC2256
o O RFC2256
postalAddress RFC2256
telephoneNumber RFC2256

Les attributs utilisés dans la classe dcObject

Nom attributO/DOrigine
dc O RFC2247

Les attributs utilisés dans la classe organizationalUnit

Nom attributO/DOrigine
description RFC2256
facsimileTelephoneNumber RFC2256
ou O RFC2256
postalAddress RFC2256
telephoneNumber RFC2256

Les attributs utilisés dans la classe eduOrg

Nom attributO/DOrigine
eduOrgHomePageURI eduOrg
eduOrgLegalName eduOrg
eduOrgSuperiorURI eduOrg
eduOrgWhitePagesURI eduOrg

Les attributs utilisés dans la classe supannOrg

Nom attributO/DOrigine
supannEtablissement D SupAnn 2008

Les attributs utilisés dans la classe supannEntité

Nom attributO/DOrigine
supannCodeEntite O SupAnn 2008
supannCodeEntiteParent SupAnn 2008
supannTypeEntite SupAnn 2008

Les attributs pour les personnes

Les attributs utilisés dans la classe inetOrgPerson

Nom attributO/DOrigine
cnORFC2256
displayName RFC2798
facsimileTelephoneNumber RFC2256
givenName D RFC2256
labeledURI RFC2798
mail RFC1274
mobile RFC1274
postalAddress RFC2256
preferredLanguage RFC2798
snORFC2256
telephoneNumber RFC2256
title RFC2256
uid D RFC2798
userCertificate RFC2256
userPassword RFC2307

Les attributs utilisés dans la classe eduPerson

Nom attributO/DOrigine
eduPersonAffiliation eduPerson
eduPersonNickname eduPerson
eduPersonOrgDN eduPerson
eduPersonOrgUnitDN eduPerson
eduPersonPrimaryAffiliation eduPerson
eduPersonPrimaryOrgUnitDN eduPerson
eduPersonPrincipalName eduPerson

Les attributs utilisés dans la classe supannPerson

Nom attributO/DOrigine
supannActivité SupAnn 2008
supannAliasLogin SupAnn v1
supannAutreTelephone SupAnn v1
supannCivilite SupAnn v1
supannCodeINE SupAnn v1
supannEmpId SupAnn v1
supannEntiteAffectation SupAnn 2008
supannEntiteAffectationPrincipale SupAnn 2008
supannEtablissement DSupAnn 2008
supannEtuAnneeInscription SupAnn 2008
supannEtuCursusAnnee SupAnn 2008
supannEtuDiplome SupAnn 2008
supannEtuElementPedagogique SupAnn 2008
supannEtuEtape SupAnn 2008
supannEtuID SupAnn v1
supannEtuInscription SupAnn 2008
supannEtuRegimeInscription SupAnn 2008
supannEtuSecteurDisciplinaire SupAnn 2008
supannEtuTypeDiplome SupAnn 2008
supannListeRouge DSupAnn v1
supannMailPerso SupAnn 2008
supannParrainDN SupAnn v1
supannRoleEntite SupAnn 2008
supannRoleGenerique SupAnn 2008

Autres attributs

Nom attributO/DOrigine
mailForwardingAddress Netscape

Les attributs pour les groupes

Attributs pour la classe groupOfNames

Nom attributO/DOrigine
cnORFC2256
description RFC2256
memberORFC2256
owner RFC2256

Attributs pour la classe supannGroupe

Nom attributO/DOrigine
supannGroupeAdminDN SupAnn v1
supannGroupeDateFin SupAnn v1
supannGroupeLecteurDN SupAnn v1
2009/04/14 11:37

3.2. DIT, nommage

La racine de l'arborescence est nommée par le nom DNS de l'établissement conformément aux recommandations préconisées par l'IETF (utilisation des Domain Component - RFC 2377). Ceci permet d'adresser de manière fiable les informations de tout établissement puisque l'unicité d'un domaine est assurée au sein d'Internet.

Exemple : pour l'université Michel de Montaigne, Bordeaux 3, “dc=u-bordeaux3,dc=fr”

On trouvera aussi :

  • dc=pf pour la Polynésie Française ;
  • dc=nc pour la Nouvelle Calédonie.

Trois « Organizational Unit » sont décrites par SupAnn :

  • la première appelée « people » désigne le conteneur de l'ensemble des informations concernant les personnes présentes dans l'établissement. Il s'agit d'informations décrites à l'aide des classes InetOrgPerson, eduPerson, supannPerson ;
  • la seconde appelée « groups » désigne le conteneur des informations concernant la mise en cohorte d'individu. Ces informations sont décrites à l'aide des classes GroupOfNames et supannGroupe.
  • la troisième appelée « structures » est le conteneur des structures matérielles (services, UFR, etc) et des structures immatérielles (instances électives, modules d'enseignement, etc). Ces informations sont décrites par les classes OrganizationalUnit et supannEntite.

Il n'y a pas d'autre nœud sous les nœuds people et groups.

L'entrée d'une personne est référencée de manière unique au sein de l'établissement grâce au RDN de l'entrée personne qui est l'uid issu de la classe inetOrgPerson. Un DN d'une personne aura la forme suivante : uid=2RGET676,ou=people,dc=u-bordeaux3,dc=fr L'information d'un groupe est référencée de manière similaire grâce à son RDN qui est le cn issu 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

L'établissement est libre d'ajouter toute autre « Organizational Unit » qu'il juge nécessaire à son système interne.

2009/04/14 11:37


3.3. Représentation graphique des classes et du DIT


Le DIT
Le DIT


Liens entre objets
Liens entre les objects dans le DIT

2009/04/14 11:37


4. Représentation des structures

4.1. Les structures dans le DIT

Il a été jugé nécessaire de pouvoir associer les personnes aux entités structurelles (composantes, services, instances élective, etc.) de leur établissement ; il est donc nécessaire de représenter ces entités et leurs relations dans l'annuaire. Cela suppose d'adapter le DIT et de créer un type d'objet permettant de représenter aussi bien des structures matérielles (services communs, services centraux, UFR, UMR, etc.) qu'immatérielles (instances électives, modules d'enseignements, etc.).

Ce besoin de décrire diverses catégories d'objets a conduit à utiliser le terme «entité» plutôt que de «structure», ou d'«instance».

Emplacement des structures dans le DIT

Une branche spécifique est créée pour stocker les entités 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 décrits ci-dessous :

  • 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.

Cas spécial: entrée de l'établissement

  • 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 sous la branche ou=structures.
2009/04/14 11:37

4.2. Description de l'Etablissement

Situé à la racine de l'annuaire, l'établissement est représenté par les classes organization (structurelle), dcObject, eduOrg et supannOrg (auxiliaires). Il peut également figurer dans la branche ou=structures auquel cas la classe supannEntite remplace la classe dcObject pour sa description.

Les attributs ci-dessous sont utilisés pour décrire l'établissement. La section 7 décrit plus en détail les attributs ci-dessous.

Nom attribututilisation
oRDN de l'entrée, spécifie le nom de l'entrée «organization»
telephoneNumberNuméro de téléphone de l'établissement
facsimileTelephoneNumberNuméro de fax de l'établissement
postalAddressAdresse postale principale de l'établissement
lPeut contenir le nom de la ville
descriptionTexte libre décrivant l'établissement
eduOrgHomePageURIURL du serveur Web officiel
eduOrgLegalNameNom officiel de l'établissement
eduOrgSuperiorURIURL du serveur web de l'institution de rattachement
eduOrgWhitePagesURIAnnuaire pages blanches de l'établissement
supannEtablissementCode de l'établissement (UAI, SIRET, etc.)
2009/04/14 11:37

4.3. Description des entités internes à l'établissement

Situées sous la branche ou=structures, les entités sont représentées par la classe structurelle organizationalUnit complétée d'une classe auxiliaire supannEntite et sont identifiées par l'attribut supannCodeEntite.

Les attributs ci-dessous sont utilisés pour décrire les différentes entités d'un établissement. La section 7 décrit plus en détail chacun des attributs ci-dessous.

Nom attribututilisation
ouIntitulé de l'entité
telephoneNumberNuméro de téléphone de l'entité
facsimiléTelephoneNumberNuméro de fax de l'entité
postalAddressAdresse postale principale de l'entité
descriptionTexte libre décrivant l'entité
supannTypeEntiteType de l'entité : composante, service commun, UFR, service central, instance élective, etc.
supannCodeEntiteUsage interne aux applications accédant à l'annuaire
sert de RDN pour l'entrée entité
supannCodeEntiteParentPrécise le supannCodeEntite de l'entité de niveau immédiatement supérieur
2009/04/14 11:37


5. Représentation des personnes

L'annuaire doit contenir une entrée pour toute personne ayant une relation avec l'établissement et se trouvant être enregistrée soit dans la base de gestion des étudiants soit dans la(les) base(s) du personnel. La description des personnes dans l'annuaire se base sur les classes suivantes :

  • la classe structurelle : inetOrgPerson (RFC 2798). inetOrgPerson est une sous-classe de OrganizationalPerson (RFC 2256) qui est elle-même une sous-classe de Person (RFC 2256) ;
  • la classe auxiliaire eduPerson ;
  • la classe auxiliaire supannPerson;

Seule une partie des attributs définis par inetOrgPerson et eduPerson est utilisée.

Les paragraphes suivants regroupent par «profil» les listes d'attributs utilisables pour décrire une personne :

  • le «profil commun» contient les attributs qui peuvent/doivent être présents dans toutes les entrées de personnes (étudiants, personnels [enseignants, chercheurs, BIATOSS]) ;
  • le «profil étudiant» précise les attributs propres aux étudiants ;
  • le «profil personnel» donne la liste des attributs relatifs aux personnels (enseignants, chercheurs, BIATOSS, etc).
2009/04/14 11:37

Cette partie précise l'ensemble des attributs considérés comme communs à toutes les entrées de personnes (étudiants, personnels, etc.). Une définition plus complète de ces attributs se trouvent en section 7.

Liste des attributs du «profil commun»

Nom de l'attribututilisation
cn nom complet sans accent
displayNamenom complet avec accents
facsimileTelephoneNumbernuméro de télécopie
givenName prénom
labeledURI URL (page personnelle par exemple)
mailadresse électronique institutionnelle (adresse canonique)
mailForwardingAddressadresse de renvoi de courrier électronique reçu à l'adresse institutionnelle
mobile numéro de téléphone mobile
postalAddressadresse postale complète
preferredLanguage langue usuelle
sn nom d'usage (avec caractères diacritiques)
telephoneNumbernuméro de téléphone
titletitre (docteur, professeur, …)
uid identifiant unique
userCertificatecertificat X509
userPassword mot de passe
eduPersonAffiliationstatut de la personne: étudiant, BIATOSS, enseignant, contractuel, etc.
eduPersonPrimaryAffiliationle statut considéré de la personne considéré comme principal.
eduPersonNickNamesurnom ou pseudonyme
supannEntiteAffectation
eduPersonOrgDN
eduPersonOrgUnitDN
représentent la ou les affectations de la personne dans un établissement, une composante, un service, etc.
L'interopérabilité des applications est basée sur supannEntiteAffectation, les deux autres attributs pouvant être utilisés en interne.
supannEntiteAffectation remplace supannAffectation (de SupAnn v1) devenu obsolète
eduPersonPrincipalNameidentifiant institutionnel pouvant être référencé par une application
pour un contrôle d'accès concernant une personne d'un autre établissement
supannEntiteAffectationPrincipale
eduPersonPrimaryOrgUnitDN
représentent l'affectation principale de la personne dans l'établissement (composante, service, etc.)
L'interopérabilité des applications est basée sur supannEntiteAffectationPrincipale, eduPersonPrimaryOrgUnitDN pouvant être utilisé en interne.
supannAliasLogin login de l'utilisateur
supannAutreTelephone numéro(s) de téléphone alternatif(s)
supannCiviliteCivilité (Mr. Mme Mlle)
supannEmpID identifiant employé
supannEtablissementétablissement de rattachement administratif de la personne
supannListeRougePrécise la volonté de la personne d'être ou non sur liste rouge
supannMailPersoadresse électronique privée (sous la responsabilité de la personne)
supannParrainDN responsable de l'entrée
2009/04/14 11:37

Les attributs définis ci-dessous décrivent les étudiants. Pour chaque attribut il est précisé son format ainsi que des exemples de valeurs.

Certains attributs de ce profil utilisent les nomenclatures SISE du Ministère, voir la section “Nomenclatures” pour plus de précisions sur ces nomenclatures. Les recommandations SupAnn ne donnent que quelques exemples de valeurs pour chaque attribut. Référez-vous aux tables SISE, mentionnées dans la section “Nomenclatures”.

Remarque : pour chaque définition d'un attribut SupAnn faisant référence à la table SISE, il sera précisé la colonne dont il utilise la nomenclature (ces informations sont précisées en section 7).

Liste des attributs du profil étudiant

Nom attribututilisation
supannCodeINECode INE (Identifiant National Etudiant)
supannEtuAnneeInscriptionl'année de début de l'année universitaire concernée
supannEtuSecteurDisciplinairesecteur disciplinaire de diplôme ou d'enseignement
supannEtuDiplomediplôme préparé par l'étudiant
supannEtuTypeDiplometype ou catégorie du diplôme préparé
supannEtuCursusAnneeprécise le type de cursus (L, M, D ou X, etc.) ainsi que l'année dans le diplôme
supannEtuEtapefractionnement (semestre, année, etc.) dans le temps d'un enseignement conduisant à un diplôme
supannEtuElementPedagogiquedescription générique du contenu d'un enseignement ayant le niveau de granularité désiré
supannEtuRegimeInscription“type d'enseignement” SISE (formation initiale, formation continue, formation à distance, etc.)
supannEtuInscriptionattribut composite regroupant (liant) d'autres attribut et décrivant précisément une inscription étudiante
supannEtuIDidentifiant de scolarité
2009/04/14 11:37

Cette partie explicite les attributs spécifiques aux entrées de personnes des catégories BIATOSS, enseignant, chercheur, etc. Une définition plus complète de ces attributs se trouve en section 7.

Liste des attributs du «profil de personnel»

Nom attribututilisation
supannRoleGeneriquerôle(s) générique(s) de la personne dans l'établissement
supannRoleEntiteattribut composite. Chaque valeur précise un rôle spécifique dans une entité (rôle structurel et/ou électif)
supannActivitecatégorie de métier, branche d'activité
2009/04/14 11:37

Les recommandations SupAnn définissent plusieurs attributs candidats à être utilisés comme identifiant de personne, ils ont des caractéristiques différentes qui doivent permettre de choisir l'identifiant le plus adapté à chaque besoin.

  • uid (Unique IDentifier) : identifiant de l'utilisateur dans le système d'information. Il permet de faire référence à l'utilisateur pour les droits d'accès aux fichiers par exemple, mais plus largement dans des applications locales.
  • eduPersonPrincipalName : identifiant de personne, globalement unique. Pour ce faire il est constitué de deux partie, séparée 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. 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.
  • supannAliasLogin : chaîne de caractère, associée à un mot de passe, utilisée par l'utilisateur pour s'authentifier. Par défaut il correspond à l'attribut uid.
  • mail : l'adresse email de l'utilisateur est souvent utilisée pour faire référence à un utilisateur, notamment parce qu'il est le seul identifiant facilement utilisable pour faire référence à un tiers. Cependant cet attribut ne satisfait pas à deux caractéristiques d'un bon identifiant : il n'est ni stable ni pérenne. En effet, l'adresse email d'une personne peut changer suite à un mariage ou un divorce ; la pérennité n'est généralement garantie que durant une courte période au-delà de laquelle une adresse email peut être réassignée à une autre personne.
2009/04/14 11:37


6. Représentation des groupes

La constitution de groupes de personnes revêt une importance fonctionnelle particulière pour des contrôles d'accès aux ressources, la constitution de listes de diffusion électroniques, la création de groupes de TP/TD/cours sur les plateformes EAD, etc.

Les groupes peuvent être constitués de deux manières :

  • en renseignant dans l'entrée de personne des attributs spécifiques qui permettront d'associer une personne à un groupe (groupe dynamique) ;
  • et/ou par la constitution explicite de groupes (groupes statiques) qui incluent la liste des personnes membres du groupe dans leur entrée.

C'est cette seconde possibilité qui est décrite dans la section suivante.

DIT

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

ou=groupes,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

Les attributs de la classe groupOfNames

NomObligatoireSémantique
memberOmembre individuel (DN de chaque membre du groupe)
cnOnom du groupe, DOIT être utilisé comme rdn pour les entrées de type groupe
owner détenteur du groupe
description description du groupe

Les attributs de la classe supannGroupe

NomObligatoireSémantique
supannGroupeDateFin date de fin de validité du groupe
supannGroupeLecteurDN personnes ou groupes habilités à consulter les données du groupe
supannGroupeAdminDN administrateurs autorisés à modifier le contenu de l'entrée

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

2009/04/14 11:37


7. Description des attributs

cn (common name)

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

Origine : RFC2256 (inetOrgPerson, groupOfNames)

Valuation : multivalué

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.

Voir aussi : displayName, eduPersonNickname, givenName, sn,

dc (domainComponent)

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

Origine : RFC2247

Valuation : multivalué

Obligatoire : Oui

Contenu :

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

Exemples : « univ-metz », « fr »

description

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

Origine : RFC2256 (plusieurs classes l'utilisent: organizationalUnit, groupOfNames, etc.)

Valuation : multivalué

Obligatoire : Non

Contenu : texte libre

displayName

Sémantique : nom complet avec accents

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.

eduOrgHomePageURI

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

Origine : Internet2 (eduOrg)

Valuation : multivalué

Obligatoire : Non

Contenu : URL HTTP

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

Voir aussi : eduOrgSuperiorURI, eduOrgWhitePagesURI

eduOrgLegalName

Sémantique : nom officiel de l'établissement

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).

eduOrgSuperiorURI

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

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

eduOrgWhitePagesURI

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

Origine : Internet2 (eduOrg)

Valuation : Multivalué

Obligatoire : Non

Contenu : URL

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

Voir aussi : eduOrgHomePageURI

eduPersonAffiliation

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

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 enregistrée dans la base des étudiants inscrits dans l'établissement. La valeur “member” est également positionnée pour ces personnes ;
  • faculty : personnel géré ou hébergé par l'établissement assurant une activité d'enseignement. La valeur “member” est également positionnée pour ces personnes ;
  • staff : cette valeur est obsolète et ne devrait plus être utilisée ;
  • employee : personnel géré ou hébergé par l'établissement ayant une activité autre que d'enseignement ou de recherche. La valeur “member” est également positionnée pour ces personnes ;
  • member : personne inscrite dans la (les) base(s) de gestion des étudiants ou celle(s) des personnels. Le profil “member” inclut donc les profils suivants : “student”, “faculty”, “employee”, “researcher” ;
  • 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) : ce profil correspond à une personne enregistrée comme lecteur autorisé par la bibliothèque, le service de documentation. Cette valeur a été introduite pour répondre à la problématique d'accès à des périodiques électroniques. Cette notion est indépendante des autres valeurs de l'attribut et n'implique pas la valeur “member” ;
  • researcher (SupAnn 2008) : personne assurant une activité de recherche. La valeur “member” est également positionnée pour ces personnes ;
  • retired (SupAnn 2008) : personne à la retraite conservant des relations avec l'établissement ;
  • emeritus (SupAnn 2008) : professeur ayant obtenu l'éméritat dans l'établissement.

Exemples:

Usage de eduPersonAffiliation
Statut de l'individu student faculty Staff (*) employee affiliate alum library-walk-in researcher retired emeritus member
étudiant inscrit X X
enseignant-chercheur géré par l'établissement X X X
chercheur géré par l'établissement (contractuel « allocataire de recherche », etc. ) X X
enseignant non chercheur géré par l'établissement (enseignant du 1er, du 2nd degré, etc.) X X
personnel ni chercheur ni enseignant géré par l'établissement (BIATOS, vacataire, apprenti, CES, HS, etc.) X X
chercheur EPST hébergé (chercheur CNRS, INRA, etc.) X X
Thésard ou post-doc hébergé et inscrit X X X
Thésard ou post-doc hébergé non inscrit X X
chercheur invité hébergé X X
chercheur invité non hébergé X
intervenant extérieur enseignant hébergé X X
intervenant extérieur enseignant non hébergé X
personnel non chercheur EPST hébergé (ITA CNRS, etc.) X X
prestataire extérieur non enseignant, hébergé X X
prestataire extérieur non enseignant, non hébergé X
stagiaire hébergé X X
stagiaire non hébergé X
émérite X X
lecteur de bibliothèque X
ancien étudiant maintenant une relation avec l'établissement X
retraité maintenant une relation avec l'établissement X
Définitions:
Géré : enregistré dans la (les) base(s) de gestion du personnel et 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
Inscrit : enregistré dans la base des étudiants inscrits dans l'établissement
Remarques:
Un individu peut cumuler plusieurs lignes et donc cumuler les valeurs en conséquence. Exemples : ancien étudiant + chercheur, émérite + retraité, etc.
(*) : La valeur « staff » décrite dans SupAnn v1 est rendue obsolète.

Remarques La question de la “finesse” de représentation du statut a été débattue. Il a été décidé de s'en tenir à de grandes catégories en complétant la nomenclature grossière de eduPersonAffiliation.

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

Voir aussi : eduPersonPrimaryAffiliation

eduPersonNickname

Sémantique : nom d'affichage

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

eduPersonOrgDN

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

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.

eduPersonOrgUnitDN

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

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.

eduPersonPrimaryAffiliation

Sémantique : statut principal de la personne

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.

Voir aussi : eduPersonAffiliation

eduPersonPrimaryOrgUnitDN

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

Origine : Internet2 (eduPerson)

Valuation : monovalué

Obligatoire : Non

Contenu :
Distinguished Name.
Une des valeurs de eduPersonOrgUnitDN.

Voir aussi : eduPersonOrgUnitDN.

eduPersonPrincipalName

Sémantique : Identifiant institutionnel unique

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.

Exemple : “jdupond@univ-truc.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.

facsimileTelephoneNumber

Sémantique : numéro de fax

Origine : RFC2256 (inetOrgPerson)

Valuation : multivalué

Obligatoire : Non

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

givenName

Sémantique : prénom

Origine : RFC2256 (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

l (locality)

Sémantique : nom d'une localité.

Origine : RFC2256 (plusieurs classes l'utilisent)

Valuation : multivalué

Obligatoire : Non

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

Voir aussi : postalAddress

labeledURI

Sémantique : URL

Origine : RFC2798 (inetOrgperson)

Valuation : multivalué

Obligatoire : Non

Contenu : PEUT contenir une URL vers la page personnelle

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

mail

Sémantique : adresse de courrier électronique institutionnelle

Origine : RFC2798 (inetOrgPerson)

Valuation : multivalué

Obligatoire : Non

Contenu :
Chaîne de caractères au format RFC822.
Cet attribut DOIT contenir l'adresse de courrier électronique canonique institutionnelle.

Voir aussi : mailForwardingAddress, supannMailPerso

mailForwardingAddress

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

Origine : Netscape (cf. http://www3.tools.ietf.org/html/draft-lachman-ldap-mail-routing-03)

Valuation : multivalué

Obligatoire : Non

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

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.

Voir aussi : mail, supannMailPerso

member

Sémantique : membre individuel

Origine : RFC2256 (groupOfNames)

Valuation : multivalué

Obligatoire : Oui

Contenu : DN de chaque membre du groupe

mobile

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

Origine : RFC2798 (inetOrgPerson)

Valuation : multivalué

Obligatoire : Non

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

Voir aussi : facsimileTelephoneNumber, supannAutreTelephone, telephoneNumber

o (organization)

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

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

Valuation : multivalué

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

Contenu :

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

ou (organizational unit)

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

Origine : RFC2256 (organizationalUnit)

Valuation : Multivalué

Obligatoire : Oui

Contenu : texte libre

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

owner

Sémantique : Responsable (détenteur)

Origine : RFC2256 (groupOfNames)

Valuation : multivalué

Obligatoire : Non

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

postalAddress

Sémantique : adresse postale

Origine : RFC2256 (inetOrgPerson, organization, organizationalUnit)

Valuation : multivalué

Obligatoire : Non

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

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

Voir aussi : l (locality)

preferredLanguage

Sémantique : langue usuelle

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”

sn (surname)

Sémantique : nom

Origine : RFC2256 (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

supannActivite

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

Origine : SupAnn 2008 (supannPerson)

Valuation : multivalué

Obligatoire : Non

Contenu : Contenu étiqueté

  • enseignants : 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 : 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#)

Nomenclatures : nomenclatures provenant de la Base Centrale des Nomenclatures

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”

Remarques :

supannAffectation (obsolète)

Origine : SupAnn v1 (supannPerson)

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

supannAliasLogin

Sémantique : login de l'utilisateur

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

supannAutreTelephone

Sémantique : autres téléphones

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

supannCivilite

Sémantique : civilité

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

supannCodeINE

Sémantique : code INE pour les étudiants.

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.

supannCodeEntite

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

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

supannCodeEntiteParent

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

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

supannEmpId

Sémantique : identifiant employé

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 : supannEtuID

supannEntiteAffectation

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

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,

supannEntiteAffectationPrincipale

Sémantique : affectation principale de la personne

Origine : SupAnn 2008 (supannPerson)

Valuation : monovalué

Obligatoire : Non

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

Exemple: “z-385”

Voir aussi : supannEntiteAffectation

supannEtablissement

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

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.

Exemple :

  • ”{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

supannEtuAnneeInscription

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

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

supannEtuCursusAnnee

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

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

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

supannEtuDiplome

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

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ôme 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

supannEtuElementPedagogique

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

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

supannEtuEtape

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

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

supannEtuID

Sémantique : identifiant de scolarité

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 : supannEmpId

supannEtuInscription (attribut composite)

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.

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}O2][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

supannEtuRegimeInscription

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

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

supannEtuSecteurDisciplinaire

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

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)

Exemple : ”{SISE}27” pour “Histoire”

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

supannEtuTypeDiplome

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

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

supannGroupeAdminDN

Sémantique : administrateurs

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

supannGroupeDateFin

Sémantique : fin de validité du groupe

Origine : SupAnn v1 (supannGroupe)

Valuation : monovalué

Obligatoire : Non

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

Voir aussi : supannGroupeAdminDN, supannGroupeLecteurDN

supannGroupeLecteurDN

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

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

supannListeRouge

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

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

supannMailPerso

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

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

Voir aussi : mail, mailForwardingAddress

supannOrganisme (obsolète)

Origine : SupAnn v1 (supannPerson)

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

supannParrainDN

Sémantique : responsable de l'entrée

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.

supannRole (obsolète)

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é.

supannRoleEntite (attribut composite)

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

Origine : SupAnn 2008 (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 ;
  • supannTypeEntite (type d'entité) - obligatoire ;
  • supannCodeEntite (code de l'entité) - facultatif.

Syntaxe :

[role=supannRoleGenerique][type=supannTypeEntite][code=supannCodeEntite] 

Remarques :

Pour pouvoir être réellement utilisé, cet attribut nécessitera que les nomenclatures concernant supannRole et celle concernant supannTypeEntite soient publiées.

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.

Voir aussi : supannRole

supannRoleGenerique

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

Origine : SupAnn 2008 (supannPerson)

Valuation : multivalué

Obligatoire : Non

Contenu : étiqueté

Nomenclatures : Nomenclature de rôles en cours de définition. Cette nomenclature doit faire l'objet des travaux des groupes supann2-tech et supann2. Une première proposition se trouve sur Nomenclature des rôles generique (attribut supannRoleGenerique)

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.

Voir aussi : supannRole

supannTypeEntite

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

Origine : SupAnn 2008 (supannPerson)

Valuation : multivalué

Obligatoire : Non

Contenu : contenu étiqueté

Nomenclatures : Nomenclature des types d'entités(attribut supannTypeEntite)

Remarques : est utilisé dans l'attribut composite supannRoleEntite

Voir aussi : supannRoleGenerique, supannRoleEntite

telephoneNumber

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

Origine : RFC2256 (inetOrgPerson)

Valuation : multivalué

Obligatoire : Non

Contenu : numéro de téléphone principal. Attention, il DEVRAIT être monovalué dans SupAnn, contrairement au RFC 2256 (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

title

Sémantique : titre

Origine : RFC2256 (inetOrgPerson)

Valuation : multivalué

Obligatoire : Non

Contenu : titre de la personne

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

Voir aussi : supannCivilite

uid

Sémantique : identifiant unique

Origine : RFC2798

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,

userCertificate

Sémantique : certificat X.509

Origine : RFC2256 et RFC2798 (inetOrgPerson)

Valuation : multivalué

Obligatoire : Non

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

userPassword

Sémantique : mot de passe

Origine : RFC1274 (perseon)

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é.

2009/04/21 10:05


Annexe 1: supannEtuInscription (exemple d'utilisation)

L'illustration ci-dessous a pour but de montrer quelques scénarios 
d'utilisation de l'attribut composite supannEtuInscription.

Mlle. X. est étudiante, avec 2 inscriptions administratives 
sur l'année universitaire 2007/2008.

1ere inscription:
-----------------
- établissement: ENSCR (UAI=0350077U), établissement autonome cohabitant  
   dans les mêmes base Apogee et annuaire LDAP que Rennes 1 (UAI=0350936C) 
- année: 2007/2008
- régime: initial (code SISE "10"), 
- secteur disciplinaire: Chimie (code SISE "03"), 
- type diplôme: "FORM.ING." (code SISE "FI")
- cursus/année: 3eme année dans le diplôme ("X3" selon nomenclature SupAnn)
- ufr d'inscription: ENSCR (code entité "959" selon nomenclature locale 
   des Composantes/UFRs dans Apogée)
- diplôme:
    intitulé SISE: INGENIEUR DIPLOME DE L'ECOLE NATIONALE SUPERIEURE 
                     DE CHIMIE DE RENNES (code SISE "6000114")
    intitulé local: DIPL.  INGENIEUR    ENSCR (code local "I2030-241" )
- étape: DIPLOME D'INGENIEUR ENSCR 3ème année (code local "I20303-271" )
- cette inscription ne se décline pas en UE.

2eme inscription:
-----------------
- établissement: IGR Rennes (UAI=0350075S); l'IGR est une composante 
   de l'université de Rennes 1 (UAI=0350936C); on retient au final 
   le code du niveau 1 établissement (UAI=0350936C).
- année: 2007/2008
- régime: initial (code SISE "10"), 
- secteur disciplinaire: Sc Gestion (code SISE "39")
- type diplôme: "MASTER LMD" (code SISE "XB")
- cursus/année: Master 2 ("M2" selon nomenclature SupAnn)
- ufr d'inscription : ENSCR (code entité "933" selon nomenclature 
   locale des Composantes/UFRs dans Apogée)
- diplôme: 
   intitulé SISE: SCIENCES JURIDIQUES, POLITIQUES, ECONOMIQUES 
                   ET DE GESTION (code SISE "2212140")
   intitulé local: Master mention ADMINISTRATION DES ENTREPRISES 
                    (code local "GM052-241")
- étape: Master M2 mention administration des entreprises 
                    (code local "GM0522-241")
- dans le cadre de cette inscription, l'étudiante est pédagogiquement 
   inscrite à 4 UE (Unités d'Enseignement): 
     G3GAE08U:Managt syst.inf.contrôle ; 
     G3GAE07U:Technique quantitative ; 
     G4GAE13U:Langue ; 
     G4GAE09U:Managt stratégique ; 

1er scénario:
-------------
On enregistre dans LDAP le "minimum syndical" nécessaire aux besoins externes; 
dans l'attribut composite, seuls les composants obligatoires sont valorisés:

dn: uid=X, ou=people, dc=univ-rennes1, dc=fr
-- "minimum syndical" --
supannEtablissement: {UAI}0350077U
supannEtablissement: {UAI}0350936C
supannEntiteAffectation: 933
supannEntiteAffectation: 959
supannEtuAnneeInscription: 2007
supannEtuRegimeInscription: {SISE}10
supannEtuSecteurDisciplinaire: {SISE}03
supannEtuSecteurDisciplinaire: {SISE}39
supannEtuTypeDiplome: {SISE}XB
supannEtuTypeDiplome: {SISE}FI
supannEtuCursusAnnee: {SUPANN}M2
supannEtuCursusAnnee: {SUPANN}X3
-- attribut composite avec "minimum syndical" --
0123456789----------0123456789----------0123456789----------0123456789----------
supannEtuInscription: [etab={UAI}0350077U][anneeinsc=2007][regimeinsc={SISE}10]
  [sectdisc={SISE}03][typedip={SISE}FI][cursusann={SUPANN}X3]
supannEtuInscription: [etab={UAI}0350936C][anneeinsc=2007][regimeinsc={SISE}10]
  [sectdisc={SISE}39][typedip={SISE}XB][cursusann={SUPANN}M2]

2eme scénario :
---------------
Pour améliorer le "minimum syndical" et répondre en plus à quelques besoins 
internes, on descend dans l'attribut composite jusqu'à l'étape (codification 
locale), en passant par l'ufr (code local) et le diplôme (codage SISE).

dn: uid=X, ou=people, dc=univ-rennes1, dc=fr
-- minimum syndical --
supannEtablissement: {UAI}0350077U
supannEtablissement: {UAI}0350936C
supannEntiteAffectation: 933
supannEntiteAffectation: 959
supannEtuAnneeInscription: 2007
supannEtuRegimeInscription: {SISE}10
supannEtuSecteurDisciplinaire: {SISE}03
supannEtuSecteurDisciplinaire: {SISE}39
supannEtuTypeDiplome: {SISE}XB
supannEtuTypeDiplome: {SISE}FI
supannEtuCursusAnnee: {SUPANN}M2
supannEtuCursusAnnee: {SUPANN}X3
-- supplément au mininum syndical --
supannEtuDiplome: {SISE}6000114
supannEtuDiplome: {SISE}2212140
-- supplément pour besoins internes --
supannEtuEtape: {UAI:0350936C}I2030-241
supannEtuEtape: {UAI:0350936C}GM052-241
-- attribut composite avec "minimum syndical" et suppléments --
supannEtuInscription: [etab={UAI}0350077U][anneeinsc=2007][regimeinsc={SISE}10]
  [sectdisc={SISE}03][typedip={SISE}FI][cursusann={SUPANN}X3][affect=959]
  [diplome={SISE}6000114][etape={UAI:0350936C}I20303-271]
supannEtuInscription: [etab={UAI}0350936C][anneeinsc=2007][regimeinsc={SISE}10]
  [sectdisc={SISE}39][typedip={SISE}XB][cursusann={SUPANN}M2][affect=933]
  [diplome={SISE}2212140][etape={UAI:0350936C}GM0522-241]

3eme scénario: 
--------------
D'un côté, afin de répondre aux besoins externes on descend jusqu'au 
diplôme (codage SISE) mais en ignorant l'entité/UFR; dans l'attribut 
composite, on valorise les composants 1 à 6 et 8;
D'autre part, pour de gros besoins internes, on "pousse" jusqu'aux 
éléments pédagogiques (ici on s'intéresse aux Unités d'Enseignement
dites "UE") mais en utilisant cette fois-ci les codes locaux des UFR, 
des diplômes, étapes et éléments pédagogiques (ici les UE s'il y en a).
L'attribut composite aura donc 2 méthodes de remplissage, l'une répondant 
aux besoins externes, l'autre aux besoins internes.
Au vu des attributs élémentaires, d'autres combinaisons de remplissage de 
l'attribut composite auraient pu être mises en oeuvre mais - par souci 
d'économie - n'ont pas été retenues.

dn: uid=X, ou=people, dc=univ-rennes1, dc=fr
-- "minimum syndical" --
supannEtablissement: {UAI}0350077U
supannEtablissement: {UAI}0350936C
supannEntiteAffectation: 933
supannEntiteAffectation: 959
supannEtuAnneeInscription: 2007
supannEtuRegimeInscription: {SISE}10
supannEtuSecteurDisciplinaire: {SISE}03
supannEtuSecteurDisciplinaire: {SISE}39
supannEtuTypeDiplome: {SISE}XB
supannEtuTypeDiplome: {SISE}FI
supannEtuCursusAnnee: {SUPANN}M2
supannEtuCursusAnnee: {SUPANN}X3
-- supplément au "mininum syndical" (avec codage SISE pour chaque diplôme) --
supannEtuDiplome: {SISE}6000114
supannEtuDiplome: {SISE}2212140
-- supplément pour gros besoins internes (avec codes locaux ) --
supannEtuDiplome: {UAI:0350936C}I2030-241
supannEtuDiplome: {UAI:0350936C}GM052-241
supannEtuEtape: {UAI:0350936C}I2030-241
supannEtuEtape: {UAI:0350936C}GM052-241
supannEtuElementPedagogique: {UAI:0350936C}G3GAE08U
supannEtuElementPedagogique: {UAI:0350936C}G3GAE07U
supannEtuElementPedagogique: {UAI:0350936C}G4GAE13U
supannEtuElementPedagogique: {UAI:0350936C}G4GAE09U
-- attribut composite pour "minimum syndical" (avec diplome codage SISE)  --
supannEtuInscription: [etab={UAI}0350077U][anneeinsc=2007][regimeinsc={SISE}10]
  [sectdisc={SISE}03][typedip={SISE}FI][cursusann={SUPANN}X3]
  [diplome={SISE}6000114]
supannEtuInscription: [etab={UAI}0350936C][anneeinsc=2007][regimeinsc={SISE}10]
  [sectdisc={SISE}39][typedip={SISE}XB][cursusann={SUPANN}M2]
  [diplome={SISE}2212140]
-- attribut composite pour gros besoins internes (avec ufr, diplome, 
    étape  et UE en codage local)  --
supannEtuInscription: [etab={UAI}0350077U][anneeinsc=2007][regimeinsc={SISE}10]
  [sectdisc={SISE}03][typedip={SISE}FI][cursusann={SUPANN}X3][affect=933]
  [diplome={UAI:0350936C}I2030-241][etape={UAI:0350936C}I20303-271]
supannEtuInscription: [etab={UAI}0350936C][anneeinsc=2007][regimeinsc={SISE}10]
  [sectdisc={SISE}39][typedip={SISE}XB][cursusann={SUPANN}M2][affect=933]
  [diplome={UAI:0350936C}GM052-241][etape={UAI:0350936C}GM0522-241]
  [eltpedago={UAI:0350936C}G3GAE08U]
supannEtuInscription: [etab={UAI}0350936C][anneeinsc=2007][regimeinsc={SISE}10]
  [sectdisc={SISE}39][typedip={SISE}XB][cursusann={SUPANN}M2][affect=933]
  [diplome={UAI:0350936C}GM052-241][etape={UAI:0350936C}GM0522-241]
  [eltpedago={UAI:0350936C}G3GAE07U]
supannEtuInscription: [etab={UAI}0350936C][anneeinsc=2007][regimeinsc={SISE}10]
  [sectdisc={SISE}39][typedip={SISE}XB][cursusann={SUPANN}M2][affect=933]
  [diplome={UAI:0350936C}GM052-241][etape={UAI:0350936C}GM0522-241]
  [eltpedago={UAI:0350936C}G4GAE13U]
supannEtuInscription: [etab={UAI}0350936C][anneeinsc=2007][regimeinsc={SISE}10]
  [sectdisc={SISE}39][typedip={SISE}XB][cursusann={SUPANN}M2][affect=933]
  [diplome={UAI:0350936C}GM052-241][etape={UAI:0350936C}GM0522-241]
  [eltpedago={UAI:0350936C}G4GAE09U]

Quelques filtres LDAP pour les besoins externes
-----------------------------------------------

Tous les étudiants qui sont inscrits en Master 2 (LMD) : 
     (supannEtuCursusAnnee={SUPANN}M2)

Tous les étudiants inscrits dans le secteur disciplinaire Chimie :
     (supannEtuSecteurDisciplinaire={SISE}03)

Tous les étudiants inscrits en Master 2 ou bien dans le secteur 
disciplinaire Chimie:
     (|(supannEtuCursusAnnee={SUPANN}M2)(supannEtuSecteurDisciplinaire={SISE}03))

Tous les étudiants qui sont inscrits en Master 2 et dans le secteur 
disciplinaire Chimie :
     (&(supannEtuCursusAnnee={SUPANN}M2)(supannEtuSecteurDisciplinaire={SISE}03))

Avec le filtre ci-dessus, Mlle X est sélectionnée mais il n'est pas certain 
que ce soit le but recherché; en effet Mlle X a effectivement une inscription 
en Master 2 et une autre inscription en Chimie; mais si l'on souhaite que 
ces 2 critères de sélection se réalisent sur la même inscription, il faut 
solliciter l'attribut composite, comme ci-dessous: 

Tous les étudiants ayant une inscription en Master 2 dans le secteur 
disciplinaire Chimie : 
     (supannEtuInscription=*[sectdisc={SISE}03]*[cursusann={SUPANN}M2]*)

Avec ce dernier filtre, Mlle X n'est pas sélectionnée.

Quelques filtres LDAP pour des besoins internes
-----------------------------------------------

Tous les étudiants inscrits pédagogiquement à l'UE 
G3GAE07U:Technique quantitative:
     (supannEtuElementPedagogique={UAI:0350936C}G3GAE07U)

Tous les étudiants inscrits en 2007/2008 dans l'entité/ufr 
933:Institut de Gestion de Rennes:
     (supannEtuInscription=*[anneeinsc=2007]*[affect=933]*)

Tous les étudiants inscrits en 2007/2008, administrativement à l'étape 
GM0522-241:Master M2 mention administration des entreprises:
 (supannEtuInscription=*[anneeinsc=2007]*[etape={UAI:0350936C}GM0522-241]*)
2009/04/14 11:37


Annexe 2: Schéma d'annuaire (syntaxe RFC 4512)

##############            schema supann 	        ##############
#                      C. Claveleira - CRU                           #

# $Id: supann.schema,v 2008.3 2008/10/23 11:59:56 clavelei Exp $	


# Schema des objets specifiques des recommandations supann

# Placé sous l'arc 1.3.6.1.4.1.7135.1.2 du CRU
# sous-arc 1 : attributs
# sous-arc 2 : classes

# Modifications :
#
# 23 oct.  08 (CC) : ajout SINGLE-VALUE à supannEntiteAffectationPrincipale
# 24 juin  08 (CC) : plus de clause MUST à supannPerson, ajout supannRoleGenerique
# 18 juin  08 (CC) : intégration de supann 2008.rc1
# 25 juil. 03 (CC) : supannGroup* -> supannGroupe*
# 10 juil. 03 (CC) : supannGroupeLecteur -> supannGroupeLecteurDN, supannGroupeAdministrateur -> supannGroupeAdminDN
# 09 juil. 03 (CC) : ajout supannGroupeLecteur
# 08 juil. 03 (CC) : exactmatch pour supannEtuId, supannEmpId, supannAliasLogin
# 07 juil. 03 (CC) : mise en conformite avec V033
# 05 juin  03 (CC) : ajout supannDateFin, supannParrain et classe freduPerson
# 27 mai   03 (CC) : supannEmpActivite plus obligatoire
# 23 mai   03 (CC) : supannOrganisme et supannCivilite monovalues, ajout supannRole
# 16 mai   03 (CC) : supannCodeINE->supannEtuCodeINE, supannEtablissement->supannOrganisme, supannAliasLogin
# 17 avril 03 (CC) : adaptations pour V 015
# 10 avril 03 (CC) : support version 14 des recommandations
# 20 fevr. 03 (CC) : mise a jour
# 28 nov.  02 (CC) : version initiale

# Attributs :
#
attributetype ( 1.3.6.1.4.1.7135.1.2.1.1 NAME 'supannListeRouge'
	DESC 'indique que l entree correspondante n est pas publique'
	EQUALITY booleanMatch
	SINGLE-VALUE
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 )

attributetype ( 1.3.6.1.4.1.7135.1.2.1.2 NAME 'supannActivite'
	DESC 'activite ou metier de la personne'
	EQUALITY caseIgnoreMatch
	SUBSTR caseIgnoreSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} )


attributetype ( 1.3.6.1.4.1.7135.1.2.1.3 NAME 'supannOrganisme'
	DESC 'code organisme d appartenance'
	EQUALITY caseIgnoreMatch
	SUBSTR caseIgnoreSubstringsMatch
	SINGLE-VALUE
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} )

attributetype ( 1.3.6.1.4.1.7135.1.2.1.4 NAME 'supannCivilite'
	DESC 'civilite : M., Mme, Mlle'
	EQUALITY caseIgnoreMatch
	SUBSTR caseIgnoreSubstringsMatch
	SINGLE-VALUE
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.44{32} )

attributetype ( 1.3.6.1.4.1.7135.1.2.1.5 NAME 'supannAffectation'
	DESC 'affectation'
	EQUALITY caseIgnoreMatch
	SUBSTR caseIgnoreSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} )

attributetype ( 1.3.6.1.4.1.7135.1.2.1.6 NAME 'supannCodeEntite'
	DESC 'identifiant d entite'
	EQUALITY caseIgnoreIA5Match
	SUBSTR caseIgnoreIA5SubstringsMatch
	SINGLE-VALUE
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{128} )

attributetype ( 1.3.6.1.4.1.7135.1.2.1.7 NAME 'supannCodeEntiteParent'
	DESC 'identifiant d entite parente'
	EQUALITY caseIgnoreIA5Match
	SUBSTR caseIgnoreIA5SubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{128} )

attributetype ( 1.3.6.1.4.1.7135.1.2.1.8 NAME 'supannEntiteAffectation'
	DESC 'identifiant d entite d affectation'
	EQUALITY caseIgnoreIA5Match
	SUBSTR caseIgnoreIA5SubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{128} )

attributetype ( 1.3.6.1.4.1.7135.1.2.1.9 NAME 'supannCodeINE'
	DESC 'code INE'
	EQUALITY caseIgnoreMatch
	SUBSTR caseIgnoreSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.44{128} )

attributetype ( 1.3.6.1.4.1.7135.1.2.1.10 NAME 'supannEtuId'
	DESC 'identifiant scolarite'
	EQUALITY caseExactMatch
	SUBSTR caseExactSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} )

attributetype ( 1.3.6.1.4.1.7135.1.2.1.11 NAME 'supannEmpId'
	DESC 'identifiant personnel'
	EQUALITY caseExactMatch
	SUBSTR caseExactSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} )

attributetype ( 1.3.6.1.4.1.7135.1.2.1.12  NAME 'supannAutreTelephone' 
	SUP telephoneNumber
	DESC 'numeros de telephone secondaires' )

attributetype ( 1.3.6.1.4.1.7135.1.2.1.13 NAME 'supannEntiteAffectationPrincipale'
	DESC 'identifiant d entite principale d affectation'
	EQUALITY caseIgnoreIA5Match
	SUBSTR caseIgnoreIA5SubstringsMatch
	SINGLE-VALUE
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{128} )

attributetype ( 1.3.6.1.4.1.7135.1.2.1.14 NAME 'supannEtablissement'
	DESC 'code d etablissement'
	EQUALITY caseIgnoreMatch
	SUBSTR caseIgnoreSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} )

attributetype ( 1.3.6.1.4.1.7135.1.2.1.15 NAME 'supannMailPerso'
	DESC 'Mailbox RFC822 privee'
    	EQUALITY caseIgnoreIA5Match
    	SUBSTR caseIgnoreIA5SubstringsMatch
   	 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} )

attributetype ( 1.3.6.1.4.1.7135.1.2.1.16 NAME 'supannTypeEntite'
	DESC 'type de structure ou entite'
	EQUALITY caseIgnoreMatch
	SUBSTR caseIgnoreSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} )

attributetype ( 1.3.6.1.4.1.7135.1.2.1.17  NAME 'supannParrainDN' 
	SUP distinguishedName
	DESC 'dn du responsable de cette entree' )

attributetype ( 1.3.6.1.4.1.7135.1.2.1.18 NAME 'supannGroupeDateFin'
	DESC 'indique la date de fin de validite de l entree correspondante'
	EQUALITY generalizedTimeMatch
	ORDERING generalizedTimeOrderingMatch
	SINGLE-VALUE
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )

attributetype ( 1.3.6.1.4.1.7135.1.2.1.19  NAME 'supannGroupeAdminDN' 
	SUP distinguishedName
	DESC 'dn des administrateurs du groupe concerne' )

attributetype ( 1.3.6.1.4.1.7135.1.2.1.20 NAME 'supannAliasLogin'
	DESC 'login personalise'
	EQUALITY caseExactMatch
	SUBSTR caseExactSubstringsMatch
	SINGLE-VALUE
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} )

attributetype ( 1.3.6.1.4.1.7135.1.2.1.21 NAME 'supannRole'
	DESC 'role'
	EQUALITY caseIgnoreMatch
	SUBSTR caseIgnoreSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} )

attributetype ( 1.3.6.1.4.1.7135.1.2.1.22  NAME 'supannGroupeLecteurDN' 
	SUP distinguishedName
	DESC 'dn des entites habilite a lire le contenu d un groupe' )

attributetype ( 1.3.6.1.4.1.7135.1.2.1.23 NAME 'supannRoleGenerique'
	DESC 'role generique d une personne'
	EQUALITY caseIgnoreMatch
	SUBSTR caseIgnoreSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )

attributetype ( 1.3.6.1.4.1.7135.1.2.1.24 NAME 'supannRoleEntite'
	DESC 'role contextuel'
	EQUALITY caseIgnoreMatch
	SUBSTR caseIgnoreSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{512} )

attributetype ( 1.3.6.1.4.1.7135.1.2.1.25 NAME 'supannEtuAnneeInscription'
	DESC 'annee inscription'
	EQUALITY numericStringMatch
	ORDERING numericStringOrderingMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.36{4} )

attributetype ( 1.3.6.1.4.1.7135.1.2.1.26 NAME 'supannEtuCursusAnnee'
	DESC 'cursus et annee dans le diplome'
	EQUALITY caseIgnoreMatch
	SUBSTR caseIgnoreSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} )

attributetype ( 1.3.6.1.4.1.7135.1.2.1.27 NAME 'supannEtuDiplome'
	DESC 'diplome'
	EQUALITY caseIgnoreMatch
	SUBSTR caseIgnoreSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} )

attributetype ( 1.3.6.1.4.1.7135.1.2.1.28 NAME 'supannEtuElementPedagogique'
	DESC 'element pedagogique'
	EQUALITY caseIgnoreMatch
	SUBSTR caseIgnoreSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} )

attributetype ( 1.3.6.1.4.1.7135.1.2.1.29 NAME 'supannEtuEtape'
	DESC 'etape'
	EQUALITY caseIgnoreMatch
	SUBSTR caseIgnoreSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} )

attributetype ( 1.3.6.1.4.1.7135.1.2.1.30 NAME 'supannEtuInscription'
	DESC 'description d inscriptions'
	EQUALITY caseIgnoreMatch
	SUBSTR caseIgnoreSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{4096} )

attributetype ( 1.3.6.1.4.1.7135.1.2.1.31 NAME 'supannEtuRegimeInscription'
	DESC 'regime d inscription'
	EQUALITY caseIgnoreMatch
	SUBSTR caseIgnoreSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} )

attributetype ( 1.3.6.1.4.1.7135.1.2.1.32 NAME 'supannEtuSecteurDisciplinaire'
	DESC 'secteur disciplinaire'
	EQUALITY caseIgnoreMatch
	SUBSTR caseIgnoreSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} )

attributetype ( 1.3.6.1.4.1.7135.1.2.1.33 NAME 'supannEtuTypeDiplome'
	DESC 'type de diplome'
	EQUALITY caseIgnoreMatch
	SUBSTR caseIgnoreSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} )



######################## Classes d'objets :

# classe complementaire specifique de supann :
objectclass ( 1.3.6.1.4.1.7135.1.2.2.1 NAME 'supannPerson' SUP top AUXILIARY
	DESC 'classe d infos complementaires sur personnes supann'
	MAY ( supannOrganisme $ supannCivilite $ supannAutreTelephone $ supannAffectation $ 
	supannEmpId $ supannCodeINE $ supannEtuId $ supannAliasLogin $ supannParrainDN $
	supannActivite $ supannEntiteAffectation $ supannEntiteAffectationPrincipale $ 
	supannMailPerso $ supannRole $ supannRoleEntite $ supannRoleGenerique $ supannTypeEntite $
	supannEtuAnneeInscription $ supannEtuCursusAnnee $ supannEtuDiplome $ supannEtuElementPedagogique $
	supannEtuEtape $ supannEtuInscription $ supannEtuRegimeInscription $ supannEtuSecteurDisciplinaire $
	supannEtuTypeDiplome $ supannEtablissement $ supannListeRouge ) )

objectclass ( 1.3.6.1.4.1.7135.1.2.2.2 NAME 'supannOrg' SUP top AUXILIARY
	DESC 'classe d infos complementaires pour etablissement'
	MAY ( supannEtablissement ) )

objectclass ( 1.3.6.1.4.1.7135.1.2.2.3 NAME 'supannEntite' SUP top AUXILIARY
	DESC 'classe d infos complementaires pour entite'
	MUST ( supannCodeEntite )
	MAY ( supannTypeEntite  $ supannCodeEntiteParent ) )

#objectclass ( 1.3.6.1.4.1.7135.1.2.2.4 NAME 'entree disponible'

#-objectclass ( 1.3.6.1.4.1.7135.1.2.2.5 NAME 'entree disponible'

# attributs specifiques des groupes :
objectclass ( 1.3.6.1.4.1.7135.1.2.2.6 NAME 'supannGroupe' SUP top AUXILIARY
	DESC 'attributs specifiques des groupes'
	MAY ( supannGroupeDateFin  $ supannGroupeAdminDN $ supannGroupeLecteurDN ) )


2009/04/14 11:37


Annexe 3 Sigles, abbréviation, terminologie

Sigles, abréviations, terminologie

Sigle - abréviationDéfinition
AMUEAgence de mutualisation des universités (http://www.cpu.fr/Amue)
BAPBranche d'activité professionnelle
CNUConseil national des universités
CRUComité réseau des universités (http://www.cru.fr)
DNDistinguished Name
EESÉtablissement d'enseignement supérieur
ENTEspace numérique de travail
INEIdentifiant national étudiant
RDNRelative Distinguished Name
RFCRequest For Comments
SDETSchéma directeur des espaces numériques de travail
SGISystème Global d'Information
SISystème d'Information
URIUniform Resource Identifier
URLUniform Resource Locators
URNUniform Resource Name

Glossaire des termes employés

TermeDéfinition
Branche d'activité professionnelleLes métiers de la recherche et de la formation au ministère de la jeunesse, de l'éducation nationale et de la recherche sont répartis en 8 branches d'activité professionnelle (BAP) :
BAP A : sciences du vivant ;
BAP B : sciences chimiques sciences des matériaux ;
BAP C : sciences de l'ingénieur et instrumentation scientifique ;
BAP D : sciences humaines et sociales ;
BAP E : informatique et calcul scientifique ;
BAP F : documentation, édition et communication ;
BAP G : patrimoine, logistique et prévention ;
BAP I : gestion scientifique et technique des établissements publics à caractère scientifique, culturel et professionnel.
Campus numériqueUn campus numérique se définit comme un dispositif de formation centré sur l'apprenant proposant des services innovants via des technologies numériques.
Les ministères de l'éducation nationale et de la recherche ont lancé successivement, en 2000, 2001 et 2002, trois appels à projets pour la constitution de « Campus numériques français ».
L'objectif majeur des appels à projets est d'arriver à construire une offre nationale de formation ouverte et à distance (FOAD) de qualité et compétitive sur le marché international.
En 2002, l'appel à projets Campus numérique comportait un second volet concernant le développement technologique de solutions d'espaces numériques de travail.
Espaces numériques de travailUn espace numérique de travail désigne un dispositif global fournissant à un usager un point d'accès à travers les réseaux à l'ensemble des ressources et des services numériques en rapport avec son activité. Il est un point d'entrée pour accéder au système d'information de l'établissement.
Distinguished NameNom complet d'annuaire permettant de situer une entrée dans l'arborescence (DIT) de façon unique.
Le DN d'une entrée est composé de l'attribut défini pour la nommer, encore appelé nom relatif distinct (RDN) et du nom d'annuaire (DN) de son parent : DN = [RDN] + DN(parent).
Similaire au chemin complet d'un fichier dans un système de fichiers.
[CN = Pascal Thing-Leoh], OU = Personnes, O = Comelis, C = FR
Identifiant National EtudiantL'identifiant national étudiant (INE) est codé sur 11 caractères.
Il est la seule variable permettant de suivre, au fil des ans, le cursus d'un étudiant. Il doit donc rester le même, pour un individu donné, tout au long de sa scolarité.

La structure du numéro d'immatriculation est la suivante :
- code université : 5 caractères
- numéro de série : 1 caractère
- numéro d'ordre : 4 caractères
- clé de contrôle : 1 caractère

Le code université, le numéro de série et le numéro d'ordre sont des nombres en base 36.
Nom de familleSynonyme de nom patronymique ou nom de naissance
Nom de naissanceSynonyme de nom patronymique ou nom de famille (sauf dans le cas très rare d'une personne qui a effectué un changement de nom)
Nom d'usageIl s'agit d'un nom pouvant être utilisé par une personne dans les cas suivants :
– la loi du 23 décembre 1985 permet, depuis le 1er juillet 1986, à toute personne majeure d'ajouter à son nom patronymique celui de ses parents qui ne lui a pas été transmis, à titre d'usage. En ce qui concerne les mineurs, cette possibilité peut être exercée par les titulaires de l'exercice de l'autorité parentale;
–une femme mariée ou veuve peut adjoindre ou substituer à son nom patronymique le nom patronymique du conjoint. Par ailleurs, même si cela n'est pas l'usage, un homme marié peut, quant à lui, ajouter le nom de son épouse au sien ;
–une femme divorcée peut éventuellement garder l'usage du nom patronymique de l'ex-époux avec l'accord de celui-ci et avec l'autorisation du juge si elle justifie d'un intérêt particulier pour elle-même ou ses enfants, ou lorsque le divorce a été prononcé à la demande du mari, en cas de rupture prolongée de la vie commune, ou pour altération des facultés mentales.

Important : le nom d'usage ne peut en aucun cas être mentionné à l'état civil ou sur le livret de famille.

Dans la vie privée, familiale, sociale ou professionnelle, les personnes peuvent user soit de leur patronyme, soit d'un nom d'usage.

En revanche, le nom d'usage est utilisé dans les correspondances adressées par l'administration lorsque l'intéressé en a fait la demande expresse.

Le même nom d'usage doit être choisi pour tous les services administratifs.
Nom patronymiqueNom d'une personne enregistré dans l'état civil. Il est aussi appelé nom de famille ou nom de naissance.
Pages blanchesLes définitions des pages blanches varient. Dans le cadre de ce document, la définition utilisée est : on appelle « pages blanches » une application permettant de rechercher et consulter les coordonnées de personnes dans l'établissement. On peut rechercher les personnes à partir de leur nom, de leur service d'appartenance ou de leur activité.
Relative Distinguished NameVoir Distinguished Name.
Request For CommentsRecommandations Internet établies par l'IETF.
Les textes des RFC sont disponibles sur le site : http://www.rfc-editor.org
Uniform Resource IdentifierIndique précisément la position de chaque ressource d'Internet, les deux types d'URI sont les URL et les URN.
Uniform Resource LocatorsL'URL permet de référencer de manière unique un fichier informatique situé sur un serveur connecté à Internet. Elle comprend le protocole utilisé, la machine, le nom de domaine, le port TCP/IP ainsi que le chemin du fichier sur le serveur.
Signe diacritiqueSigne qui, adjoint à une lettre, en modifie la valeur ou permet de distinguer deux mots homographes (ex. : accent grave de à, cédille du ç).
2009/04/14 11:37


Annexe 4 Références

Nom courtNom completDescriptionURL
AASRecommandations AASRecommandations, dans le cadre du SDET, en matière d'identification, authentification, autorisation et SSO.http://www.educnet.education.fr/chrgt/sdet/SDET_Annexe_AAS_v2.0.pdf
Annuaire des unités du CNRSL'annuaire décrit les laboratoires CNRS et fournit le code de chacunhttp://web-ast.dsi.cnrs.fr/l3c/owa/annuaire.recherche
Attribute Recommendations for AAF Participants,Définition des attributs de personne utilisable au sein du service de fédération d'identités Australien, AAFhttp://www.aaf.edu.au/documentation
BcEBase Centrale des EtablissementsLa base est le référentiel pour les codes UAIhttp://www.infocentre.education.fr/ibce/
BcNBase Centrale des NomenclaturesRéférentiel des nomenclatures du Ministère de l'Education Nationalehttp://www.infocentre.education.fr/bcn/
CC-ScolCadre de cohérence ScolaritéDocument établi par un groupe de travail dans le domaine de la scolarité, sous l’égide du Comité de Pilotage SIhttp://www.cpu.fr/uploads/tx_publications/Cadre_de_coherence_scolarite-Rapport.pdf
CC-RHlCadre de cohérence Ressources HumainesDocument établi par un groupe de travail dans le domaine de la gestion des Ressources Humaines, sous l’égide du Comité de Pilotage SI http://www.cpu.fr/uploads/tx_publications/Cadre_de_coherence_SI_volet_RH_rapport.pdf
CCITT Rec. E123ITU-T Recommendation E.123. Notation for national and international telephone numbersFormat de présentation des numéros de téléphone.http://www.itu.int/rec/recommendation.asp?type=items&lang=e&parent=T-REC-E.123-200102-I
eduOrg Classe auxiliaire eduOrg, complétant « organization » eduOrg
eduPersoneduPerson Object Class Specification (200712)Spécifications de la classe EduPersonhttp://www.educause.edu/eduperson/949
Feide attributesDéfinition des attributs de personne utilisable au sein du service de fédération d'identités Norvégien, Feidehttp://rnd.feide.no/view/attributes
Guide Informatique et Libertéhttp://www.cpu.fr/uploads/tx_publications/Guide_Informatique_Libertes.pdf
Identifiers, authentication, and directoriesAnalyse des identifiants et de leur utilisationhttp://middleware.internet2.edu/internet2-mi-best-practices-00.html
ISO 639Codes for the representation of names of languagesCode abrégé des noms de langueshttp://www.w3.org/WAI/ER/IG/ert/iso639.htm
http://lcweb.loc.gov/standards/iso639-2/
MACE-DIR Initiative Internet2 dans le domaine annuaire MACE-DIR
Il s’y trouve tout un ensemble de documents dont eduPerson, eduOrg, Practices in Directories, etc.
organization Compléments d’information pour la classe « organization » défini en RFC2256 organization
RFC 1274The COSINE and Internet X.500 Schemahttp://www.ietf.org/rfc/rfc1274.txt
RFC 1766Tags for the Identification of LanguagesBalises indiquant la (les) langue(s) à utiliser pour présenter une informationhttp://www.ietf.org/rfc/rfc1766.txt
RFC 2119Key words for use in RFCs to Indicate Requirement LevelsMots clés utilisés dans les RFC pour définir le niveau de recommandationhttp://www.ietf.org/rfc/rfc2119.txt
RFC 2251Lightweight Directory Access Protocol (v3) : définition du protocole LDAP (v3)Définition du protocole LDAP (v3)http://www.ietf.org/rfc/rfc2251.txt
RFC 2252Lightweight Directory Access Protocol (v3): Attribute Syntax DefinitionsDéfinition du protocole LDAP (v3)
Syntaxe des attributs
http://www.ietf.org/rfc/rfc2252.txt
RFC 2253Lightweight Directory Access Protocol (v3) : UTF-8 String Representation of Distinguished NamesDéfinition du protocole LDAP (v3)
Représentation sous forme d'une chaîne de caractères, encodée UTF-8, des Distinguished Names
http://www.ietf.org/rfc/rfc2253.txt
RFC 2254The String Representation of LDAP Search FiltersReprésentation sous forme d'une chaîne de caractères des filtres de recherche LDAPhttp://www.ietf.org/rfc/rfc2254.txt
RFC 2255The LDAP URL FormatFormat des URL LDAPhttp://www.ietf.org/rfc/rfc2255.txt
RFC 2256A Summary of the X.500(96) User Schema for use with LDAPv3Les attributs et les classes objets standard LDAPhttp://www.ietf.org/rfc/rfc2256.txt
RFC 2307An Approach for Using LDAP as a Network Information ServiceUtilisation de LDAP dans le cadre de systèmes informatiqueshttp://www.ietf.org/rfc/rfc2307.txt
RFC 2377Naming Plan for Internet Directory-Enabled ApplicationsComment nommer les éléments des annuaires LDAP pour les rendre inter opérableshttp://www.ietf.org/rfc/rfc2377.txt
RFC 2798Definition of the inetOrgPerson LDAP Object ClassLa classe relative aux personnes, adaptée à l'Internet: inetOrgPerson\\http://www.ietf.org/rfc/rfc2798.txt
RGI Référentiel Général d’Interopérabilité Référentiel Général d’Interopérabilité
SCHACSCHema for ACademiaSchéma complémentaire à eduPerson, pour faciliter l'échange de données au niveau Européenhttp://www.terena.org/activities/tf-emc2/schacreleases.html
SDETShéma Directeur des Espaces Numériques de TravailRecommandations pour la mise en oeuvre des ENT (Espaces Numériques de Travail) dans les établissementshttp://www2.educnet.education.fr/sections/services/ent/sdet/
2009/04/14 11:37


Annexe 5 Constitution des groupes de travail

Deux groupes distincts ont contribué à la genèse de ces recommandations :

  • le groupe supann2 impliquant les personnes dites «fonctionnelles» qui ont eu pour mission de spécifier les nouvelles fonctionnalités attendues de l'annuaire ;
  • le groupe supann2-tech incluant les personnes dites «techniques».

Voici par ordre alphabétique les adresses de courrier électronique des personnes des deux groupes.

Constitution du groupe fonctionnel supann2 (devenu supann-fonctionnel)

Constitution du groupe technique supann2-tech (devenu supann-tech)

2009/04/14 11:37