Choix d'un identifiant utilisateur

Parmi l'ensemble des attributs disponibles, il en existe un certain nombre susceptibles d'être utilisés comme identifiant utilisateur. Néanmoins, le contexte d'une fédération fait qu'ils ne sont pas tous adaptés à cet usage. Deux propriétés en particulier sont nécessaires :

  • cet identifiant doit être persistant (constant dans le temps)
  • cet identifiant doit être unique au sein de la fédération

L'adresse électronique, en particulier, même si elle est largement utilisée, est certes unique, mais certainement pas persistante, comme le montrent les multiples changements de domaine de messagerie liés aux fusions entre universités. De plus, il n'y a aucun moyen de contrôler sa valeur, hormis sa syntaxe, et un fournisseur d'identité malveillant, ou compromis, peut tout a fait produire une valeur mensongère.

D'autres propriétés peuvent également être intéressantes:

  • un identifiant est non-réassignable s'il apporte la garantie qu'il ne sera jamais réutilisé pour un utilisateur à l'avenir, à cause d'une homonymie par exemple
  • un identifiant est ciblé s'il est unique pour une application donnée, et donc inexploitable par croisement avec une autre application
  • un identifiant est révocable si sa validité peut être annulée a posteriori
  • un identifiant est opaque s'il n'apporte aucune information sur l'utilisateur auquel il correspond

Cette page du wiki Shibboleth présente un panorama relativement exhaustif de ces propriétés.

Attribut Valeur Opaque Ciblé Ré-assignable Obsolète
eduPersonUniqueId bpWYKmQyl4HEQ3Z8POYXnimWgo6wvOuO@univ-xyz.fr oui non non oui
eduPersonTargetedId https://idp.domaine1.tld!https://sp.domaine2.tld!mXozexUF7lg8rBwwyumpZ6a+5wI= oui oui non oui
eduPersonPrincipalName jdupont@univ-xyz.fr non non non non
subjectId jdupont@univ-xyz.fr non non non non
pairwiseId ZTME3TMNBXGYYTIOBYGMY@univ-xyz.fr oui oui non non

L'avenir est clairement du coté des nouveaux attributs dédiés, subjectId et pairwiseId. Ils sont triviaux à mettre en place coté IdP, si celui-ci sait déjà générer les autres attributs, et vont sans doute se généraliser dans un avenir proche. Néanmoins, en l'absence d'un mécanisme de signalisation, il est impossible à l'heure actuelle de déterminer quels fournisseurs d'identité au sein d'une fédération sont effectivement capables de les produire. Le choix va donc être principalement dicté par l'audience visée par l'application, d'une part, et la connaissance de cette audience, d'autre part.

Si cette absence de visibilité n'est pas un problème (par exemple, parce les capacités des fournisseurs d'identité concernés sont connues autrement que par les métadonnées), alors le choix entre les deux correspond à celui d'un identifiant opaque ou non. Si l'application cherche à offrir le maximum de garantie de respect de la vie privée à ses utilisateurs, alors l'attribut pairwiseId constitue le meilleur choix. Néanmoins, cette opacité complexifie également le support technique, et donc la possibilité d'apporter une assistance efficace à l'utilisateur en cas de problème, et surtout ce luxe de précaution n'a aucun intérêt si d'autres attributs nominatifs sont demandés en parallèle. L'attribut subjectId semble donc un meilleur choix générique, pour une application non commerciale, au sein de la communauté ESR française.

Dans le cas contraire, pour une application cherchant à maximiser la comptabilité avec l'ensemble de la communauté, l'attribut eduPersonPrincipalName offre aujourd'hui un meilleur compromis entre complexité opérationnelle, et réponse au besoin. Et dans ce cas spécifique, il est souhaitable d'utiliser également l'attribut eduPersonPrincipalNamePrior pour gérer un éventuel changement de valeur de l'identifiant.

Les attributs eduPersonUniqueId, qui n'a vraisemblablement jamais été utilisé au sein de notre communauté, et eduPersonTargetedID sont tous les deux obsolètes, et ne devraient plus être utilisés. Les fournisseurs d'identité capable de les générer aujourd'hui devraient encore être capable de le faire demain, mais il sera plus difficile d'exiger des nouveaux fournisseurs d'identité qu'ils le fassent également.

Notre fiche technique sur la génération de ces attributs.

  • federation/documentation/generale/identifiant-utilisateur.txt
  • Dernière modification : 2024/02/28 13:29
  • de ludovic.auxepaules@renater.fr