single sign on - metadatos - ¿Para qué se utiliza el formato NameID diferente?
seo meta tags (4)
1 y 2 son SAML 1.1 porque esos URI eran parte del estándar OASIS SAML 1.1. La Sección 8.3 del PDF vinculado para el estándar OASIS SAML 2.0 explica esto:
Siempre que sea posible, se utiliza una URN existente para especificar un protocolo. En el caso de los protocolos IETF, se utiliza la URN de la RFC más actual que especifica el protocolo. Las referencias de URI creadas específicamente para SAML tienen uno de los siguientes vástagos, de acuerdo con la versión del conjunto de especificaciones en la que se introdujeron por primera vez:
urn:oasis:names:tc:SAML:1.0: urn:oasis:names:tc:SAML:1.1: urn:oasis:names:tc:SAML:2.0:
En el archivo de metadatos SAML hay varios formatos de NameID definidos, por ejemplo:
<NameIDFormat>urn:mace:shibboleth:1.0:nameIdentifier</NameIDFormat>
<NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</NameIDFormat>
<NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</NameIDFormat>
¿Alguien puede explicar para qué se usan? ¿Cuáles son las diferencias?
Consulte la Sección 8.3 de este pdf principal de SAML de la especificación SAML de oasis.
SP y IdP generalmente se comunican entre sí sobre un tema. Ese tema debe identificarse a través de un NAME-IDentifier, que debe estar en algún formato para que sea fácil para la otra parte identificarlo según el Formato.
Todos estos
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
Son formato para los identificadores de nombres.
Transitorio es para [sección 8.3.8 de SAML Core ]
Indica que el contenido del elemento es un identificador con semántica transitoria y DEBE ser tratado como un valor opaco y temporal por la parte que confía.
Sin especificar, se puede usar y depende puramente de la implementación de las entidades en su propio deseo.
Es solo una sugerencia para el Proveedor de servicios sobre qué esperar del NameID devuelto por el Proveedor de identidad. Puede ser:
-
unspecified -
emailAddress, por ejemplo,[email protected] -
X509SubjectName- por ejemplo,CN=john,O=Company Ltd.,C=US -
WindowsDomainQualifiedName, por ejemplo,CompanyDomain/John -
kerberos- ej.john@realm -
entity: se usa para identificar entidades que proporcionan servicios basados en SAML y se parece a un URI -
persistent: este es un identificador opaco específico del servicio que debe incluir un valor pseudoaleatorio y no debe ser rastreable por el usuario real, por lo que esta es una característica de privacidad. -
transient- identificador opaco que debe ser tratado como temporal.
Sobre esto creo que puede hacer referencia a http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-tech-overview-2.0.html .
Estos son mis entendimientos sobre esto, con el Caso de uso de Identity Federation para dar detalles de esos conceptos:
- Identificadores persistentes-
IdP proporciona los identificadores persistentes, se utilizan para vincular a las cuentas locales en los SP, pero se identifican como el perfil de usuario para el servicio específico, cada uno por sí solo. Por ejemplo, los identificadores persistentes son como: johnForAir, jonhForCar, johnForHotel, todos ellos solo para un servicio específico, ya que deben vincularse a su identidad local en el servicio.
- Identificadores transitorios-
Los identificadores transitorios son lo que los IdP le dicen al SP que los usuarios en la sesión han recibido para acceder al recurso en el SP, pero la identidad de los usuarios no se ofrece al SP en realidad. Por ejemplo, la afirmación como "Anonimato (Idp no le dice a SP quién es) tiene permiso para acceder / recurso en SP". SP lo consiguió y dejó que el navegador acceda a él, pero aún no sabe el nombre real de Anonymity.
- identificadores no especificados-
La explicación para ello en la especificación es "La interpretación del contenido del elemento se deja a las implementaciones individuales". Lo que significa que IdP define el formato real para él, y asume que SP sabe cómo analizar los datos de formato que responden desde IdP. Por ejemplo, IdP da un formato de datos "UserName = XXXXX Country = US", SP obtiene la aserción, y puede analizarla y extraer el UserName es "XXXXX".