Il s'agit d'un identifiant utilisateur opaque, persistent (constant d'une session à une autre) et spécifique à un couple SP/IdP, appellé PersistentID dans la norme SAML2.
Il peut être transmis de deux façons différentes à un fournisseur de service:
La différence entre les deux notions est présentée ici, et des exemples concrets de syntaxe sont donnés ici.
Cet identifiant peut être généré de deux manières différentes:
La première stratégie, basée sur un connecteur Computed ID, est plus simple à mettre en place, mais nécessite plus d'effort s'il est nécessaire de retrouver l'utilisateur correspondant, et ne permet pas non plus de révoquer les identifiants.
La seconde stratégie, basée sur un connecteur Stored ID, est plus complexe à mettre en œuvre, car elle nécessite la présence d'une base de donnée, mais offre en contrepartie plus de possibilités de manipulation des identifiants.
Cet identifiant est constitué d'un triplet de 3 valeurs:
Si ces trois éléments sont bien transmis séparément dans la réponse de l'IdP (cf les exemples de syntaxe précédents), ils sont présentés sous la forme d'une valeur unique par le SP à l'application sous-jacente, à savoir une chaine formée par la concaténation des trois éléments séparés par un caractère de délimitation, typiquement un point d'exclamation.
Par exemple, une valeur transmise ainsi par l'IdP:
<saml2:NameID xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion" Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent" NameQualifier="https://idp.example.org/idp/shibboleth" SPNameQualifier="https://sp.example.org/shibboleth"> 84e411ea-7daa-4a57-bbf6-b5cc52981b73 </saml2:NameID>
Sera passée à l'application sous la forme habituelle clé/valeur:
persistent-id = https://idp.example.org/idp/shibboleth!https://sp.example.org/shibboleth!84e411ea-7daa-4a57-bbf6-b5cc52981b73
Ce mécanisme d'extraction des attributs par le SP est défini dans le fichier attribute-map.xml, et permet notamment de rendre transparent pour l'application sous-jacente la façon dont cet identifiant est effectivement transmis (NameID ou attribut SAML).
La stratégie Computed ID consiste à produire la valeur opaque en passant à une fonction de hachage la concaténation de 3 éléments:
Cette solution offre un atout de taille, à savoir qu'il n'y a pas besoin de stocker le résultat, puisqu'il peut être reproduit de manière identique à chaque utilisation. En revanche, elle présente également plusieurs inconvénients:
La stratégie alternative Stored ID consiste à produire une valeur aléatoire lors du premier accès à un fournisseur de service, puis à la stocker dans une base de données. Cette stratégie corrige les deux problèmes précédents, mais en contrepartie exige la présence d'une brique technique supplémentaire, une base de données relationnelle. Ceci apporte d'une part une fragilité supplémentaire, et d'autre part une complexité supplémentaire dans le cas d'une configuration tolérante aux pannes, puisqu'il faut alors la partager ou la répliquer entre les différentes instances de l'IdP.
Pour faciliter les évolutions, l'algorithme utilisé pour générer la première valeur opaque dans le cas de la stratégie Stored ID est le même que pour la stratégie Computed ID. Il est ainsi tout a fait possible de commencer par une stratégie simple, puis d'évoluer vers une stratégie plus complexe lorsque le besoin apparait, sans perturber l'existant. Ce n'est que lorsqu'un identifiant est révoqué qu'un autre algorithme sera utilisé pour le calcul du nouvel identifiant.
Plus de détails sont disponibles ici.
