• Origine : RFC 4519, inetOrgPerson (RFC 2798) (cf. Normes)
• Nom : uid
• Description : identifiant de connexion d'une personnes sur les systèmes informatiques
• OID : 0.9.2342.19200300.100.1.1
• Attribut parent : aucun
• Valuation : multivalué, mais mono-valuation demandée dans le cadre de SUPANN
• Obligatoire: Non, mais exigé dans le cadre de SUPANN
• ObjectClass : inetOrgPerson
• Type de donnée : chaîne de caractères (max. 256)
• Règles de comparaison : égalité (casse ignorée)

• Type d'usage: identifiant de connexion, identifiant technique
• Contexte d'utilisation : LDAP
• Unicité : oui
• Visibilité : limitée
• Indexation recommandée : eq
• Voir aussi : supannAliasLogin, eduPersonPrincipalName, eduPersonUniqueId, cn (commonName)

L'attribut uid est un identifiant de connexion aux systèmes informatiques, unique au sein de l'établissement. Il est destiné à un usage local: il ne DEVRAIT pas être propagé à des applications hors du périmètre de responsabilité de l'établissement.

Cet attribut n'est pas opaque: en particulier, il PEUT être basée sur des informations nominatives, sans toutefois que ce ne soit une obligation.

Dans le cadre de SUPANN, il DOIT être utilisé comme RDN pour les entrées de personnes, et il ne DEVRAIT contenir qu'une seule valeur.

Cet attribut est historiquement utilisé par de très nombreux systèmes et applications comme identifiant technique de personne, parfois sans distinction possible de son usage d'identifiant de connexion. En conséquence:

• il ne DOIT PAS être réattribué d'une personne à une autre. L'établissement devra faire son possible pour garantir cette qualité de non-réattribution pendant une durée suffisante au vu de la durée de rétention des identifiants dans l'ensemble de ses systèmes, applications et archives.

• il PEUT être modifié de manière occasionnelle. Du fait de sa non-opacité, cet attribut peut être amené à changer, par exemple lors d'une modification d'état-civil ou pour corriger une erreur. Les conditions de modification sont laissées à l'appréciation de l'établissement, mais DEVRAIENT rester exceptionnelles. En cas de changement, l'établissement doit prendre les mesures nécessaires pour garantir la propagation de ce changement à toutes les briques de son SI qui l'utilisent, ou assumer les conséquences de sa non-propagation (pertes d'accès, rupture d'unicité, etc). Il doit en outre garantir la non-réattribution de l'ancienne valeur à un autre individu, au même titre qu'une valeur en cours de validité.

Du fait de son usage possible comme identifiant de connexion, la valeur de l'uid DEVRAIT être choisie courte et mnémonique. Par ailleurs, de nombreux systèmes se basant sur l'uid (systèmes d'exploitation, d'authentification…) y imposent des contraintes de syntaxe ou de longueur: dans la pratique il est recommandé de ne pas dépasser 20 caractères, et de se limiter aux lettres ASCII non accentuées, chiffres, tiret “-”, tiret bas “_” et point “.”.

Remarques:

• même si l'usage de l'uid comme identifiant technique est couramment admis, l'attribut eduPersonUniqueId, qui offre de meilleures garanties de stabilité et d'opacité, doit lui être préféré pour cet usage.
• Lorsque les notions d'identifiants de connexion et technique peuvent être dissociées, il est préférable d'utiliser l'attribut supannAliasLogin comme identifiant de connexion.
• Dans un contexte ActiveDirectory, la valeur de l'uid PEUT être utilisée pour alimenter l'attribut sAMAccountName.
• Dans un contexte Kerberos, la valeur de l'uid PEUT être utilisée pour alimenter la partie gauche du principal de l'utilisateur. Une alternative est d'utiliser l'attribut supannAliasLogin.

dn: uid=jdupont21,ou=people,dc=univ-paris1,dc=fr
uid: jdupont21
supannAliasLogin: jeandup

(&(objectClass=supannPerson)(uid=jdupont21))