Portail des services RENATER

La description des personnes dans l'annuaire se base sur les classes suivantes :

• la classe structurelle inetOrgPerson;
• la classe auxiliaire eduPerson;
• la classe auxiliaire supannPerson.

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

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 (userid) : identifiant de connexion aux systèmes informatiques, à portée locale (établissement). Constitue le RDN des objets de type Personne. Largement utilisé dans de nombreux systèmes et applications comme identifiant utilisateur principal, il souffre d'un amalgame historique entre ses usages d'identifiant de référence (qui devrait être opaque et immuable), et d'identifiant de connexion (mnémonique donc non-opaque, potentiellement modifiable). Il est désormais recommandé de réserver cet identifiant aux usages historiques ou pouvant s'accommoder de modifications occasionnelles.

• eduPersonPrincipalName : identifiant de personne à portée globale. 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 via son domaine DNS. Très utilisé dans le domaine de la fédération d'identités comme identifiant utilisateur de référence, il souffre du même problème de manque d'opacité et de stabilité que l'uid (SupAnn préconise d'ailleurs d'utiliser l'uid comme valeur de sa partie gauche). Il est désormais recommandé de n'y faire appel qu'en second choix en absence du eduPersonUniqueId, ou pour des usages de type identifiant de connexion (userPrincipalName ActiveDirectory par exemple).

• eduPersonUniqueId : identifiant expressément opaque à portée globale. Une alternative au eduPersonPrincipalName, offrant de meilleures garanties d'opacité, de stabilité et de non-réattribution. Cet attribut est recommandé lorsqu'un identifiant de référence global immuable est demandé, notamment dans le cadre de la fédération.

• supannAliasLogin : identifiant de connexion (chaîne de caractères mnémonique, saisie par l'utilisateur pour s'authentifier, associée au mot de passe), à portée locale. Sa valeur par défaut est celle de l'uid; il est modifiable et réattribuable. Recommandé pour tous les usages d'authentification. En aucun cas cet attribut ne doit être considéré comme un identifiant de référence. Le système d'authentification doit “traduire” dynamiquement cet identifiant de connexion en recherchant dans l'annuaire l'identifiant de référence correspondant (eduPersonUniqueId par exemple), ce dernier étant transmis à l'applicatif pour référencer l'utilisateur.

• mail : l'adresse email 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. Il est conseillé de n'utiliser l'adresse email comme identifiant qu'en dernier choix.

• Dans les contextes de fédération d'identité (Education/Recherche, FranceConnect), il peut être fait appel à des identifiants ciblés, opaques, dont la valeur dépend du couple fournisseur d'identité / fournisseur de service (voir: eduPersonTargetedID, supannFCSub). Ces attributs garantissent l'étanchéité des SI (absence de croisements possibles). Leur usage devra être privilégié dans toutes les situations où les responsabilités des SI sont clairement distinctes.

• Selon les environnements techniques, d'autres identifiants plus spécifiques sont également disponibles (uidNumber POSIX, objectSid ActiveDirectory, identifiants locaux dans les bases de données d'applications…). Lorsque aucun attribut LDAP dédié n'est prévu pour les accueillir, il est possible de faire appel au supannRefId pour les stocker dans l'annuaire et maintenir de cette manière les références croisées avec les applications concernées.

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 dans Liste des attributs.