Quels sont les différents formats NameID utilisés?

Dans le fichier de métadonnées SAML, plusieurs formats NameID sont définis, par exemple:

urn:mace:shibboleth:1.0:nameIdentifier urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified urn:oasis:names:tc:SAML:2.0:nameid-format:transient 

Quelqu’un peut-il expliquer à quoi cela sert? Quelles sont les différences?

Reportez-vous à la section 8.3 de ce pdf de base SAML de la spécification oasis SAML.

SP et IdP communiquent généralement entre eux sur un sujet. Ce sujet doit être identifié par un identifiant NAME-IDentifier, qui doit être dans un format permettant à l’autre partie de l’identifier facilement en fonction du format.

Tous ceux-ci

 1.urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified [default] 2.urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress 3.urn:oasis:names:tc:SAML:2.0:nameid-format:persistent 4.urn:oasis:names:tc:SAML:2.0:nameid-format:transient 

sont le format des identificateurs de nom.

Le format de nom pour un identifiant transitoire dans SAML 1 est urn: mace: shibboleth: 1.0: nameIdentifier et dans SAML 2 est urn: oasis: noms: tc: SAML: 2.0: nameid-format: transitoire

Transient est pour [section 8.3.8 de SAML Core ]

Indique que le contenu de l’élément est un identifiant avec une sémantique transitoire et DEVRAIT être traité comme une valeur opaque et temporaire par la partie utilisasortingce.

Non spécifié peut être utilisé et cela dépend purement de la mise en œuvre des entités sur leur propre souhait.

À ce sujet, je pense que vous pouvez vous référer à http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-tech-overview-2.0.html .

Voici ma compréhension à ce sujet, avec le cas d’utilisation de la fédération des identités pour donner des détails sur ces concepts:

  • Identificateurs persistants-

Le fournisseur d’identité fournit les identificateurs persistants, ils sont utilisés pour la liaison aux comptes locaux dans les SP, mais ils sont identifiés comme étant le profil utilisateur du service spécifique, chacun seul. Par exemple, les identifiants persistants sont un peu comme: johnForAir, jonhForCar, johnForHotel, ils ne servent qu’à un seul service, car ils doivent être liés à leur identité locale dans le service.

  • Identificateurs transitoires-

Les identificateurs transitoires sont ce que IdP indique au SP que les utilisateurs de la session ont été autorisés à accéder à la ressource sur SP, mais l’identité des utilisateurs n’offre pas réellement SP. Par exemple, l’assertion, tout comme «Anonymity (Idp ne dit pas à SP qui il est), a la permission d’accéder à / ressource sur SP». SP l’a eu et a laissé le navigateur y accéder, mais ne sait toujours pas le vrai nom d’Anonymity.

  • identifiants non spécifiés-

L’explication dans la spécification est “L’interprétation du contenu de l’élément est laissée à des implémentations individuelles”. Ce qui signifie que l’IdP définit le format réel et suppose que SP sait parsingr les données de format fournies par l’IdP. Par exemple, IdP donne un format de données “UserName = XXXXX Country = US”, SP obtient l’assertion et peut l’parsingr et extraire le UserName “XXXXX”.

1 et 2 sont SAML 1.1 car ces URI faisaient partie de la norme OASIS SAML 1.1. La section 8.3 du document PDF lié à la norme OASIS SAML 2.0 explique ceci:

Dans la mesure du possible, un URN existant est utilisé pour spécifier un protocole. Dans le cas des protocoles IETF, l’URN de la RFC la plus récente spécifiant le protocole est utilisé. Les références d’URI créées spécifiquement pour SAML ont l’un des éléments suivants, conformément à la version du jeu de spécifications dans lequel elles ont été introduites pour la première fois:

 urn:oasis:names:tc:SAML:1.0: urn:oasis:names:tc:SAML:1.1: urn:oasis:names:tc:SAML:2.0: 

Il s’agit simplement d’une indication pour le fournisseur de services sur ce qu’il faut attendre de l’identifiant Name retourné par le fournisseur d’identité. Ça peut être:

  1. unspecified
  2. emailAddress – par exemple, john@company.com
  3. X509SubjectName – par exemple CN=john,O=Company Ltd.,C=US
  4. WindowsDomainQualifiedName – par exemple CompanyDomain\John
  5. kerberos – par exemple, john@realm
  6. entity – celui-ci utilisé pour identifier les entités qui fournissent des services basés sur SAML et ressemble à un URI
  7. persistent – il s’agit d’un identificateur opaque spécifique au service qui doit inclure une valeur pseudo-aléatoire et ne doit pas être traçable pour l’utilisateur réel. Il s’agit donc d’une fonction de confidentialité.
  8. transient – identifiant opaque qui doit être traité comme temporaire.