Security Assertion Markup Language 2.0 ( SAML 2.0 ) es una versión del estándar SAML para intercambiar identidades de autenticación y autorización entre dominios de seguridad . SAML 2.0 es un protocolo basado en XML que utiliza tokens de seguridad que contienen aserciones para pasar información sobre un principal (generalmente un usuario final) entre una autoridad SAML, denominada Proveedor de identidad , y un consumidor SAML, denominado Proveedor de servicios . SAML 2.0 permite el inicio de sesión único entre dominios basado en la web (SSO), que ayuda a reducir la sobrecarga administrativa de distribuir múltiples tokens de autenticación al usuario.
Estado | Publicado |
---|---|
Año iniciado | Noviembre de 2003 |
Ultima versión | V2.0 marzo de 2005 |
Versión de vista previa | V2.0 con erratas, mayo de 2019 |
Organización | OASIS |
Comité | Comité Técnico de Servicios de Seguridad de OASIS (SAML) |
Abreviatura | SAML |
Sitio web | Wiki SAML de OASIS |
SAML 2.0 fue ratificado como estándar OASIS en marzo de 2005, reemplazando a SAML 1.1 . Los aspectos críticos de SAML 2.0 se tratan en detalle en los documentos oficiales SAMLCore, [1] SAMLBind, [2] SAMLProf, [3] y SAMLMeta. [4]
Unas 30 personas de más de 24 empresas y organizaciones participaron en la creación de SAML 2.0. En particular, y de manera especial, Liberty Alliance donó su especificación Identity Federation Framework (ID-FF) a OASIS, que se convirtió en la base de la especificación SAML 2.0. Por tanto, SAML 2.0 representa la convergencia de SAML 1.1 , Liberty ID-FF 1.2 y Shibboleth 1.3 .
Afirmaciones de SAML 2.0
Una aserción es un paquete de información que proporciona cero o más declaraciones hechas por una autoridad SAML. Las aserciones SAML generalmente se hacen sobre un tema, representado por el
elemento. La especificación SAML 2.0 define tres tipos diferentes de declaraciones de aserción que pueden ser creadas por una autoridad SAML. Todas las declaraciones definidas por SAML están asociadas con un tema. Los tres tipos de declaraciones definidas son las siguientes:
- Aserción de autenticación: el sujeto de la aserción fue autenticado por un medio particular en un momento particular.
- Aserción de atributo: el sujeto de la aserción está asociado con los atributos proporcionados.
- Aserción de decisión de autorización: se ha concedido o denegado una solicitud para permitir que el sujeto de la aserción acceda al recurso especificado.
Un tipo importante de aserción SAML es la aserción "portadora" que se usa para facilitar el SSO del navegador web. A continuación, se muestra un ejemplo de una afirmación de portador de corta duración emitida por un proveedor de identidad (https://idp.example.org/SAML2) a un proveedor de servicios (https://sp.example.com/SAML2). La aserción incluye tanto una Aserción de autenticación
como una Aserción de atributo
, que presumiblemente el proveedor de servicios usa para tomar una decisión de control de acceso. El prefijo saml:
representa el espacio de nombres de aserción SAML V2.0.
Ejemplo de SAML
xmlns: saml = "urn: oasis: names: tc: SAML: 2.0: assertion" xmlns: xs = "http://www.w3.org/2001/XMLSchema" ID = "_d71a3a8e9fcc45c9e9d248ef7049393fc8f04e5f75" Version = " 2.0 " IssueInstant = " 2004-12-05T09: 22: 05Z " > https://idp.example.org/SAML2 xmlns: ds = " http: / /www.w3.org/2000/09/xmldsig# " > ... Format = " urn: oasis: names: tc: SAML: 2.0: nameid- formato: transitorio " > 3f7b3dcf-1674-4ecd-92c8-1544f346baf8 Method = "urn: oasis: names: tc: SAML: 2.0: cm: bearer" > InResponseTo = "aaf23196-1773-2113-474a-fe114412ab72" Recipient = " https://sp.example.com/SAML2/SSO/POST " NotOnOrAfter = " 2004-12-05T09: 27: 05Z " /> NotBefore = " 2004-12-05T09: 17: 05Z " NotOnOrAfter = " 2004-12-05T09: 27: 05Z " > https://sp.example.com/SAML2 AuthnInstant = "2004-12-05T09: 22: 00Z" SessionIndex = "b07b804c-7c29-ea16-7300-4f3d6f7928ac" > < saml: AuthnContextClassRef> urn: oasis: nombres: tc: SAML: 2.0: ac: classes: PasswordProtectedTransport xmlns: x500 = "urn: oasis: nombres: tc: SAML: 2.0: perfiles: atributo: X500" x500: Encoding = "LDAP" NameFormat = "urn: oasis: names: tc: SAML: 2.0: attrname-format: uri" Name = "urn: oid: 1.3.6.1.4.1.5923.1.1.1.1" FriendlyName = " eduPersonAffiliation " > xsi: type = " xs: string " > miembro xsi: type = " xs: string " > personal
Tenga en cuenta que en el ejemplo anterior, el
elemento contiene los siguientes elementos secundarios:
- un
elemento, que contiene el identificador único del proveedor de identidad - un
elemento, que contiene una firma digital que preserva la integridad (no se muestra) sobre el
elemento - un
elemento, que identifica al principal autenticado (pero en este caso la identidad del principal está oculta detrás de un identificador transitorio opaco, por razones de privacidad) - un
elemento, que da las condiciones bajo las cuales la aserción debe ser considerada válida - un
elemento, que describe el acto de autenticación en el proveedor de identidad - un
elemento, que afirma un atributo de varios valores asociado con el principal autenticado
En palabras, la afirmación codifica la siguiente información:
La afirmación ("b07b804c-7c29-ea16-7300-4f3d6f7928ac") fue emitida en el momento "2004-12-05T09: 22: 05Z" por el proveedor de identidad (https://idp.example.org/SAML2) con respecto al asunto (3f7b3dcf -1674-4ecd-92c8-1544f346baf8) exclusivamente para el proveedor de servicios (https://sp.example.com/SAML2).
La declaración de autenticación, en particular, afirma lo siguiente:
El principal identificado en el
elemento fue autenticado en el momento "2004-12-05T09: 22: 00Z" mediante una contraseña enviada a través de un canal protegido.
Asimismo, la declaración de atributo afirma que:
El director identificado en el
elemento es un miembro del personal de esta institución.
Protocolos SAML 2.0
Los siguientes protocolos se especifican en SAMLCore: [1]
- Protocolo de solicitud y consulta de afirmación
- Protocolo de solicitud de autenticación
- Protocolo de resolución de artefactos
- Protocolo de gestión de identificadores de nombres
- Protocolo de cierre de sesión único
- Protocolo de asignación de identificador de nombre
El más importante de estos protocolos, el Protocolo de solicitud de autenticación, se analiza en detalle a continuación.
Protocolo de solicitud de autenticación
En SAML 1.1, los perfiles de SSO del navegador web son iniciados por el proveedor de identidad (IDP) , es decir, un
elemento no solicitado se transmite desde el proveedor de identidad al proveedor de servicios (a través del navegador). (El prefijo samlp:
denota el espacio de nombres del protocolo SAML).
En SAML 2.0, sin embargo, el flujo comienza en el proveedor de servicios que emite una solicitud de autenticación explícita al proveedor de identidad. El protocolo de solicitud de autenticación resultante es una nueva característica importante de SAML 2.0.
Cuando un principal (o una entidad que actúa en nombre del principal) desea obtener una aserción que contenga una declaración de autenticación,
se transmite un elemento al proveedor de identidad:
xmlns: samlp = "urn: oasis: names: tc: SAML: 2.0: protocol" xmlns: saml = "urn: oasis: names: tc: SAML: 2.0: aserción" ID = "aaf23196-1773-2113 -474a-fe114412ab72 " Version = " 2.0 " IssueInstant = " 2004-12-05T09: 21: 59Z " AssertionConsumerServiceIndex = " 0 " AttributeConsumingServiceIndex = " 0 " > https://sp.example.com/SAML2 AllowCreate = "true" Format = "urn: oasis: names: tc: SAML: 2.0: nameid-format: transient" />
El
elemento anterior , que implícitamente solicita una afirmación que contiene una declaración de autenticación , fue evidentemente emitido por un proveedor de servicios (https://sp.example.com/SAML2) y posteriormente presentado al proveedor de identidad (a través del navegador). El proveedor de identidad autentica al principal (si es necesario) y emite una respuesta de autenticación, que se transmite al proveedor de servicios (nuevamente a través del navegador).
Protocolo de resolución de artefactos
Un mensaje SAML se transmite de una entidad a otra por valor o por referencia . Una referencia a un mensaje SAML se denomina artefacto . El receptor de un artefacto resuelve la referencia enviando una
solicitud directamente al emisor del artefacto, quien luego responde con el mensaje real al que hace referencia el artefacto.
Supongamos, por ejemplo, que un proveedor de identidad envía la siguiente
solicitud directamente a un proveedor de servicios (a través de un canal trasero):
xmlns: samlp = "urn: oasis: names: tc: SAML: 2.0: protocol" xmlns: saml = "urn: oasis: names: tc: SAML: 2.0: assertion" ID = "_cce4ee769ed970b501d680f697989d14" Version = " 2.0 " IssueInstant = " 2004-12-05T09: 21: 58Z " > https://idp.example.org/SAML2 xmlns: ds = "http://www.w3.org/2000/09/xmldsig#" > ... AAQAAMh48 / 1oXIM + sDo7Dh2qMp1HM4IF5DaRNmDj6RdUmllwn9jJHyEgIi8 =
En respuesta, el proveedor de servicios devuelve el elemento SAML al que hace referencia el artefacto adjunto. Este protocolo forma la base del enlace de artefactos HTTP .
Enlaces SAML 2.0
Los enlaces admitidos por SAML 2.0 se describen en la especificación de enlaces (SAMLBind [2] ):
- Enlace SAML SOAP (basado en SOAP 1.1)
- Encuadernación inversa de SOAP (PAOS)
- Enlace de redireccionamiento HTTP
- Enlace HTTP POST
- Enlace de artefactos HTTP
- Enlace SAML URI
Para el SSO del navegador web, el enlace de redireccionamiento HTTP y el enlace HTTP POST se utilizan comúnmente. Por ejemplo, el proveedor de servicios puede usar HTTP Redirect para enviar una solicitud, mientras que el proveedor de identidad usa HTTP POST para transmitir la respuesta. Este ejemplo ilustra que la elección de vinculación de una entidad es independiente de la elección de vinculación de su socio.
Enlace de redireccionamiento HTTP
Los mensajes del protocolo SAML se pueden transportar directamente en la cadena de consulta de URL de una solicitud HTTP GET. Dado que la longitud de las URL es limitada en la práctica, el enlace de redireccionamiento HTTP es adecuado para mensajes cortos, como el
mensaje. Los mensajes más largos (por ejemplo, los que contienen aserciones SAML firmadas o cifradas, como las respuestas SAML) se transmiten normalmente a través de otros enlaces, como el enlace HTTP POST .
Las solicitudes o respuestas de SAML transmitidas a través de HTTP Redirect tienen un parámetro de cadena de consulta SAMLRequest
o SAMLResponse
, respectivamente. Antes de enviarlo, el mensaje se desinfla (sin encabezado ni suma de comprobación), se codifica en base64 y se codifica en URL, en ese orden. Una vez recibido, el proceso se invierte para recuperar el mensaje original.
Por ejemplo, codificar el
mensaje anterior produce:
https://idp.example.org/SAML2/SSO/Redirect?SAMLRequest=fZFfa8IwFMXfBb9DyXvaJtZ1BqsURRC2 Mabbw95ivc5Am3TJrXPffmmLY3% 2FA15Pzuyf33On8XJXBCaxTRmeEhTEJQBdmr% 2FRbRp63K3pL5rPhYOpkVdY ib% 2FCon% 2BC9AYfDQRB4WDvRvWWksVoY6ZQTWlbgBBZik9% 2FfCR7GorYGTWFK8pu6DknnwKL% 2FWEetlxmR8s BHbHJDWZqOKGdsRJM0kfQAjCUJ43KX8s78ctnIz% 2Blp5xpYa4dSo1fjOKGM03i8jSeCMzGevHa2% 2FBK5MNo1F dgN2JMqPLmHc0b6WTmiVbsGoTf5qv66Zq2t60x0wXZ2RKydiCJXh3CWVV1CWJgqanfl0% 2Bin8xutxYOvZL18NK UqPlvZR5el% 2BVhYkAgZQdsA6fWVsZXE63W2itrTQ2cVaKV2CjSSqL1v9P% 2FAXv4C
El mensaje anterior (formateado para facilitar la lectura) puede estar firmado para mayor seguridad. En la práctica, todos los datos contenidos en un
, como el Issuer
que contiene el ID del SP, y NameIDPolicy
, han sido acordados entre IdP y SP de antemano (a través del intercambio de información manual o mediante metadatos SAML ). En ese caso, firmar la solicitud no es una restricción de seguridad. Cuando
contiene información que el IdP no conoce de antemano, como la URL del servicio de afirmación del consumidor, se recomienda firmar la solicitud por motivos de seguridad.
Enlace HTTP POST
En el siguiente ejemplo, tanto el proveedor de servicios como el proveedor de identidad utilizan un enlace HTTP POST. Inicialmente, el proveedor de servicios responde a una solicitud del agente de usuario con un documento que contiene un formulario XHTML:
< form method = "post" action = "https://idp.example.org/SAML2/SSO/POST" ... > < input type = "hidden" name = "SAMLRequest" value = "'' request '' " /> ... otro parámetro de entrada .... formulario >
El valor del SAMLRequest
parámetro es la codificación base64 de un
elemento, que se transmite al proveedor de identidad a través del navegador. El servicio SSO del proveedor de identidad valida la solicitud y responde con un documento que contiene otro formulario XHTML:
< form method = "post" action = "https://sp.example.com/SAML2/SSO/POST" ... > < input type = "hidden" name = "SAMLResponse" value = "'' respuesta '' " /> ... formulario >
El valor del SAMLResponse
parámetro es la codificación base64 de un
elemento, que también se transmite al proveedor de servicios a través del navegador.
Para automatizar el envío del formulario, la siguiente línea de JavaScript puede aparecer en cualquier lugar de la página XHTML:
ventana . onload = function () { document . formas [ 0 ]. enviar (); }
Esto supone, por supuesto, que el primer elemento de formulario en la página contiene el form
elemento que contiene SAMLResponse anterior ( forms[0]
).
Enlace de artefactos HTTP
El enlace de artefactos HTTP utiliza el protocolo de resolución de artefactos y el enlace SAML SOAP (a través de HTTP) para resolver un mensaje SAML por referencia. Considere el siguiente ejemplo específico. Suponga que un proveedor de servicios desea enviar un
mensaje a un proveedor de identidad. Inicialmente, el proveedor de servicios transmite un artefacto al proveedor de identidad a través de un redireccionamiento HTTP:
https://idp.example.org/SAML2/SSO/Artifact?SAMLart= artifact
A continuación, el proveedor de identidad envía una
solicitud (como ArtifactResolveRequest que se mostró anteriormente) directamente al proveedor de servicios a través de un canal de retorno. Finalmente, el proveedor de servicios devuelve un
elemento que contiene el
mensaje al que se hace referencia :
xmlns: samlp = "urn: oasis: names: tc: SAML: 2.0: protocolo" ID = "_d84a49e5958803dedcff4c984c2b0d95" InResponseTo = "_cce4ee769ed970b501d680f697989d14" versión = "2.0" IssueInstant = "2004-12-05T09: 21: 59Z " > xmlns: ds = " http://www.w3.org/2000/09/xmldsig# " > ... Value = "urn: oasis: names: tc: SAML: 2.0: status: Success" /> xmlns: samlp = "urn: oasis: nombres: tc: SAML: 2.0: protocolo " xmlns: saml = " urn: oasis: nombres: tc: SAML: 2.0: aserción " ID = " _306f8ec5b618f361c70b6ffb1480eade " Version = " 2.0 " IssueInstant = " 2004-12-05T09: 21: 59Z " Destination = " https://idp.example.org/SAML2/SSO/Artifact " ProtocolBinding = " urn: oasis: names: tc: SAML: 2.0: bindings: HTTP-Artifact " AssertionConsumerServiceURL = " https: // sp .example.com / SAML2 / SSO / Artifact " > https://sp.example.com/SAML2 AllowCreate = " false " Format = " urn: oasis: n / A mes: tc: SAML: 1.1: nameid-format: emailAddress " />
Por supuesto, el flujo también puede ir en la otra dirección, es decir, el proveedor de identidad puede emitir un artefacto y, de hecho, esto es más común. Consulte, por ejemplo, el ejemplo de perfil de " artefacto doble " más adelante en este tema.
Formato de artefacto
En general, un artefacto SAML 2.0 se define de la siguiente manera (SAMLBind [2] ):
SAML_artifact: = B64 (TypeCode EndpointIndex RemainingArtifact) TypeCode: = Byte1Byte2 EndpointIndex: = Byte1Byte2
Por lo tanto, un artefacto SAML 2.0 consta de tres componentes: una secuencia de bytes de dos bytes TypeCode
, una de dos bytes EndpointIndex
y una arbitraria llamada RemainingArtifact
. Estas tres piezas de información se concatenan y codifican en base64 para producir el artefacto completo.
El TypeCode
identifica de forma exclusiva el formato del artefacto. SAML 2.0 predefine solo uno de esos artefactos, del tipo 0x0004. El EndpointIndex
es una referencia a un punto final de resolución de artefactos particular administrado por el emisor del artefacto (que puede ser el IdP o el SP, como se mencionó anteriormente). El RemainingArtifact
, que está determinado por la definición de tipo, es la "carne" del artefacto.
El formato de un artefacto de tipo 0x0004 se define de la siguiente manera:
TypeCode: = 0x0004 RemainingArtifact: = SourceId MessageHandle SourceId: = secuencia_de_20 bytes MessageHandle: = secuencia_de_20 bytes
Por lo tanto, un artefacto de tipo 0x0004 tiene un tamaño de 44 bytes (sin codificar). El SourceId
es una secuencia arbitraria de bytes, aunque en la práctica, SourceId
es el hash SHA-1 del entityID del emisor. El MessageHandle
es una secuencia aleatoria de bytes que las referencias de un mensaje SAML que el emisor artefacto está dispuesto para producir bajo demanda.
Por ejemplo, considere este artefacto de tipo 0x0004 con codificación hexadecimal:
00040000c878f3fd685c833eb03a3b0e1daa329d47338205e436913660e3e917549a59709fd8c91f2120222f
Si observa de cerca, puede ver el TypeCode
(0x0004) y el EndpointIndex
(0x0000) en la parte frontal del artefacto. Los siguientes 20 bytes son el hash SHA-1 del entityID del emisor (https://idp.example.org/SAML2) seguido de 20 bytes aleatorios. La codificación base64 de estos 44 bytes es lo que ves en el ejemplo de ArtifactResolveRequest anterior.
Perfiles SAML 2.0
En SAML 2.0, como en SAML 1.1, el caso de uso principal sigue siendo el SSO del navegador web, pero el alcance de SAML 2.0 es más amplio que las versiones anteriores de SAML, como se sugiere en la siguiente lista exhaustiva de perfiles:
- Perfiles de SSO
- Perfil de SSO del navegador web
- Perfil de cliente o proxy mejorado (ECP)
- Perfil de descubrimiento del proveedor de identidad
- Perfil de cierre de sesión único
- Perfil de gestión de identificador de nombre
- Perfil de resolución de artefactos
- Consulta de afirmación / perfil de solicitud
- Perfil de asignación de identificador de nombre
- Perfiles de atributos SAML
- Perfil de atributo básico
- Perfil de atributo X.500 / LDAP
- Perfil de atributo UUID
- Perfil de atributo DCE PAC
- Perfil de atributo XACML
Aunque el número de perfiles soportados es bastante grande, la especificación de Perfiles (SAMLProf [3] ) se simplifica ya que los aspectos vinculantes de cada perfil se han factorizado en una especificación de Bindings separada (SAMLBind [2] ).
Perfil de SSO del navegador web
SAML 2.0 especifica un perfil de SSO de navegador web que involucra a un proveedor de identidad (IdP), un proveedor de servicios (SP) y un principal con un agente de usuario HTTP. El proveedor de servicios tiene cuatro enlaces entre los que elegir, mientras que el proveedor de identidad tiene tres, lo que conduce a doce (12) posibles escenarios de implementación. A continuación, describimos tres de esos escenarios de implementación.
Solicitud de redireccionamiento de SP; Respuesta POST del IdP
Este es uno de los escenarios más comunes. El proveedor de servicios envía una solicitud SAML al servicio SSO de IdP mediante el enlace de redireccionamiento HTTP. El proveedor de identidad devuelve la respuesta SAML al servicio del consumidor de afirmaciones de SP mediante el enlace HTTP-POST.
El flujo de mensajes comienza con una solicitud de un recurso seguro en el proveedor de servicios.
1. Solicite el recurso de destino en el SP
El principal (a través de un agente de usuario HTTP) solicita un recurso de destino al proveedor de servicios:
https://sp.example.com/myresource
El proveedor de servicios realiza una verificación de seguridad en nombre del recurso de destino. Si ya existe un contexto de seguridad válido en el proveedor de servicios, omita los pasos 2 a 7.
El proveedor de servicios puede utilizar cualquier tipo de mecanismo para descubrir el proveedor de identidad que se utilizará, por ejemplo, preguntar al usuario, utilizar un IdP preconfigurado, etc.
2. Redirigir al servicio SSO de IdP
El proveedor de servicios genera una SAMLRequest adecuada (y RelayState, si corresponde) y luego redirige el navegador al Servicio de SSO de IdP mediante una redirección HTTP 302 estándar .
Ubicación de redireccionamiento 302 : https://idp.example.org/SAML2/SSO/Redirect?SAMLRequest=request&RelayState=token
El RelayState
token es una referencia opaca a la información de estado mantenida en el proveedor de servicios. El valor del SAMLRequest
parámetro es un valor desinflado, codificado en base64 y codificado en URL de un
elemento:
xmlns: samlp = "urn: oasis: names: tc: SAML: 2.0: protocol" xmlns: saml = "urn: oasis: names: tc: SAML: 2.0: aserción" ID = "identifier_1" Version = " 2.0 " IssueInstant = " 2004-12-05T09: 21: 59Z " AssertionConsumerServiceIndex = " 0 " > https://sp.example.com/SAML2 AllowCreate = " true " Format = " urn: oasis: names: tc: SAML: 2.0: nameid-format: transient " />
La SAMLRequest puede firmarse con la clave de firma del SP. Sin embargo, normalmente esto no es necesario.
3. Solicite el servicio SSO en el IdP
El agente de usuario emite una solicitud GET al servicio SSO en el proveedor de identidad:
GET / SAML2 / SSO / Redirect? SAMLRequest = request & RelayState = token HTTP / 1.1 Host : idp.example.org
donde los valores de los parámetros SAMLRequest
y RelayState
son los mismos que los proporcionados en el redireccionamiento. El servicio SSO en el proveedor de identidad procesa el
elemento (decodificando URL, decodificando base64 e inflando la solicitud, en ese orden) y realiza una verificación de seguridad. Si el usuario no tiene un contexto de seguridad válido, el proveedor de identidad identifica al usuario con cualquier mecanismo (detalles omitidos).
4. Responda con un formulario XHTML
El servicio SSO valida la solicitud y responde con un documento que contiene un formulario XHTML:
< form method = "post" action = "https://sp.example.com/SAML2/SSO/POST" ... > < input type = "hidden" name = "SAMLResponse" value = "response" /> < input type = "hidden" name = "RelayState" value = "token" /> ... < input type = "submit" value = "Submit" /> form >
El valor del RelayState
parámetro se ha conservado del paso 3. El valor del SAMLResponse
parámetro es la codificación base64 del siguiente
elemento:
xmlns: samlp = "urn: oasis: names: tc: SAML: 2.0: protocol" xmlns: saml = "urn: oasis: names: tc: SAML: 2.0: assertion" ID = "identifier_2" InResponseTo = " identifier_1 " Version = " 2.0 " IssueInstant = " 2004-12-05T09: 22: 05Z " Destination = " https://sp.example.com/SAML2/SSO/POST " > https: // idp .example.org / SAML2 Value = "urn: oasis: names: tc: SAML: 2.0: status: Success" /> xmlns: saml = "urn: oasis: names: tc: SAML: 2.0: assertion" ID = "identifier_3" Version = "2.0" IssueInstant = "2004-12-05T09: 22: 05Z" > https://idp.example.org/SAML2 xmlns: ds = "http://www.w3.org/2000 / 09 / xmldsig # " > ... Format = " urn: oasis: names: tc: SAML: 2.0: nameid-format: transient " > 3f7b3dcf-1674-4ecd-92c8-1544f346baf8 Method = "urn: oasis: names: tc: SAML: 2.0: cm: bearer" > InResponseTo = "identifier_1" Recipient = "https: //sp.example. com / SAML2 / SSO / POST " NotOnOrAfter = " 2004-12-05T09: 27: 05Z " /> NotBefore = " 2004-12-05T09: 17: 05Z " NotOnOrAfter = " 2004-12-05T09: 27: 05Z " > https://sp.example.com/SAML2 < / saml: Condiciones> AuthnInstant = "2004-12-05T09: 22: 00Z" SessionIndex = "identifier_3" > urn: oasis: nombres: tc: SAML: 2.0: ac: classes: PasswordProtectedTransport
5. Solicite el Servicio de Atención al Consumidor de Afirmación en el SP
El agente de usuario emite una solicitud POST al Servicio al consumidor de afirmaciones en el proveedor de servicios:
POST / SAML2 / SSO / POST HTTP / 1.1 Host : sp.example.com Content-Type : application / x-www-form-urlencoded Content-Length : nnn SAMLResponse = respuesta & RelayState = token
donde los valores de los parámetros SAMLResponse
y RelayState
se toman del formulario XHTML en el paso 4.
6. Redirigir al recurso de destino
El servicio de consumidor de aserción procesa la respuesta, crea un contexto de seguridad en el proveedor de servicios y redirige al agente de usuario al recurso de destino.
7. Solicite el recurso de destino en el SP nuevamente
El agente de usuario solicita el recurso de destino al proveedor de servicios (nuevamente):
https://sp.example.com/myresource
8. Responder con el recurso solicitado
Dado que existe un contexto de seguridad, el proveedor de servicios devuelve el recurso al agente de usuario.
Solicitud SP POST; Respuesta POST de IdP
Esta es una implementación relativamente simple del perfil SSO del navegador web SAML 2.0 (SAMLProf [3] ) donde tanto el proveedor de servicios (SP) como el proveedor de identidad (IdP) utilizan el enlace HTTP POST.
El flujo de mensajes comienza con una solicitud de un recurso seguro en el SP.
1. Solicite el recurso de destino en el SP
El principal (a través de un agente de usuario HTTP) solicita un recurso de destino al proveedor de servicios:
https://sp.example.com/myresource
El proveedor de servicios realiza una verificación de seguridad en nombre del recurso de destino. Si ya existe un contexto de seguridad válido en el proveedor de servicios, omita los pasos 2 a 7.
2. Responda con un formulario XHTML
El proveedor de servicios responde con un documento que contiene un formulario XHTML:
< form method = "post" action = "https://idp.example.org/SAML2/SSO/POST" ... > < input type = "hidden" name = "SAMLRequest" value = "request" /> < input type = "hidden" name = "RelayState" value = "token" /> ... < input type = "submit" value = "Submit" /> form >
El RelayState
token es una referencia opaca a la información de estado mantenida en el proveedor de servicios. El valor del SAMLRequest
parámetro es la codificación base64 del siguiente
elemento:
xmlns: samlp = "urn: oasis: names: tc: SAML: 2.0: protocol" xmlns: saml = "urn: oasis: names: tc: SAML: 2.0: aserción" ID = "identifier_1" Version = " 2.0 " IssueInstant = " 2004-12-05T09: 21: 59Z " AssertionConsumerServiceIndex = " 0 " > https://sp.example.com/SAML2 AllowCreate = " true " Format = " urn: oasis: names: tc: SAML: 2.0: nameid-format: transient " />
Antes de que el
elemento se inserte en el formulario XHTML, primero se codifica en base64.
3. Solicite el servicio SSO en el IdP
El agente de usuario emite una solicitud POST al servicio SSO en el proveedor de identidad:
POST / SAML2 / SSO / POST HTTP / 1.1 Host : idp.example.org Content-Type : application / x-www-form-urlencoded Content-Length : nnnSAMLRequest = solicitud y RelayState = token
donde los valores de los parámetros SAMLRequest
y RelayState
se toman del formulario XHTML en el paso 2. El servicio SSO procesa el
elemento (decodificando URL, decodificando base64 e inflando la solicitud, en ese orden) y realiza una verificación de seguridad. Si el usuario no tiene un contexto de seguridad válido, el proveedor de identidad identifica al usuario (se omiten los detalles).
4. Responda con un formulario XHTML
El servicio SSO valida la solicitud y responde con un documento que contiene un formulario XHTML:
< form method = "post" action = "https://sp.example.com/SAML2/SSO/POST" ... > < input type = "hidden" name = "SAMLResponse" value = "response" /> < input type = "hidden" name = "RelayState" value = "token" /> ... < input type = "submit" value = "Submit" /> form >
El valor del RelayState
parámetro se ha conservado del paso 3. El valor del SAMLResponse
parámetro es la codificación base64 del siguiente
elemento:
xmlns: samlp = "urn: oasis: names: tc: SAML: 2.0: protocol" xmlns: saml = "urn: oasis: names: tc: SAML: 2.0: assertion" ID = "identifier_2" InResponseTo = " identifier_1 " Version = " 2.0 " IssueInstant = " 2004-12-05T09: 22: 05Z " Destination = " https://sp.example.com/SAML2/SSO/POST " > https: // idp .example.org / SAML2 Value = "urn: oasis: names: tc: SAML: 2.0: status: Success" /> xmlns: saml = "urn: oasis: names: tc: SAML: 2.0: assertion" ID = "identifier_3" Version = "2.0" IssueInstant = "2004-12-05T09: 22: 05Z" > https://idp.example.org/SAML2 xmlns: ds = "http://www.w3.org/2000 / 09 / xmldsig # " > ... Format = " urn: oasis: names: tc: SAML: 2.0: nameid-format: transient " > 3f7b3dcf-1674-4ecd-92c8-1544f346baf8 Method = "urn: oasis: names: tc: SAML: 2.0: cm: bearer" > InResponseTo = "identifier_1" Recipient = "https: //sp.example. com / SAML2 / SSO / POST " NotOnOrAfter = " 2004-12-05T09: 27: 05Z " /> NotBefore = " 2004-12-05T09: 17: 05Z " NotOnOrAfter = " 2004-12-05T09: 27: 05Z " > https://sp.example.com/SAML2 < / saml: Condiciones> AuthnInstant = "2004-12-05T09: 22: 00Z" SessionIndex = "identifier_3" > urn: oasis: nombres: tc: SAML: 2.0: ac: classes: PasswordProtectedTransport
5. Solicite el Servicio de Atención al Consumidor de Afirmación en el SP
El agente de usuario emite una solicitud POST al servicio de consumidor de aserción en el proveedor de servicios:
POST / SAML2 / SSO / POST HTTP / 1.1 Host : sp.example.com Content-Type : application / x-www-form-urlencoded Content-Length : nnn SAMLResponse = respuesta & RelayState = token
donde los valores de los parámetros SAMLResponse
y RelayState
se toman del formulario XHTML en el paso 4.
6. Redirigir al recurso de destino
El servicio de consumidor de aserción procesa la respuesta, crea un contexto de seguridad en el proveedor de servicios y redirige al agente de usuario al recurso de destino.
7. Solicite el recurso de destino en el SP nuevamente
El agente de usuario solicita el recurso de destino al proveedor de servicios (nuevamente):
https://sp.example.com/myresource
8. Responder con el recurso solicitado
Dado que existe un contexto de seguridad, el proveedor de servicios devuelve el recurso al agente de usuario.
Artefacto de redireccionamiento SP; Artefacto de redireccionamiento de IdP
Esta es una implementación compleja del perfil SSO del navegador web SAML 2.0 (SAMLProf [3] ) donde tanto el proveedor de servicios (SP) como el proveedor de identidad (IdP) utilizan el enlace de artefacto HTTP. Ambos artefactos se envían a sus respectivos puntos finales a través de HTTP GET.
El flujo de mensajes comienza con una solicitud de un recurso seguro en el SP:
1. Solicite el recurso de destino en el SP
El principal (a través de un agente de usuario HTTP) solicita un recurso de destino al proveedor de servicios:
https://sp.example.com/myresource
El proveedor de servicios realiza una verificación de seguridad en nombre del recurso de destino. Si ya existe un contexto de seguridad válido en el proveedor de servicios, omita los pasos 2 a 11.
2. Redirigir al servicio de inicio de sesión único (SSO) en el IdP
El proveedor de servicios redirige al agente de usuario al servicio de inicio de sesión único (SSO) en el proveedor de identidad. Se añaden un RelayState
parámetro y un SAMLart
parámetro a la URL de redireccionamiento.
3. Solicite el servicio SSO en el IdP
El agente de usuario solicita el servicio SSO en el proveedor de identidad:
https://idp.example.org/SAML2/SSO/Artifact?SAMLart= artifact_1 & RelayState = token
donde token
es una referencia opaca a la información de estado mantenida en el proveedor de servicios y artifact_1
es un artefacto SAML, ambos emitidos en el paso 2.
4. Solicite el Servicio de Resolución de Artefactos en el SP
El servicio SSO elimina la referencia del artefacto enviando un
elemento vinculado a un mensaje SAML SOAP al servicio de resolución de artefactos en el proveedor del servicio:
xmlns: samlp = "urn: oasis: names: tc: SAML: 2.0: protocol" xmlns: saml = "urn: oasis: names: tc: SAML: 2.0: aserción" ID = "identifier_1" Version = " 2.0 " IssueInstant = " 2004-12-05T09: 21: 58Z " Destination = " https://sp.example.com/SAML2/ArtifactResolution " > https://idp.example.org/SAML2 < / saml: Issuer> xmlns: ds = "http://www.w3.org/2000/09/xmldsig#" > ... '' artifact_1 ''
donde el valor del
elemento es el artefacto SAML transmitido en el paso 3.
5. Responda con una SAML AuthnRequest
El servicio de resolución de artefactos en el proveedor de servicios devuelve un
elemento (que contiene un
elemento) vinculado a un mensaje SAML SOAP al servicio SSO en el proveedor de identidad:
xmlns: samlp = "urn: oasis: names: tc: SAML: 2.0: protocol" ID = "identifier_2" InResponseTo = "identifier_1" Version = "2.0" IssueInstant = "2004-12-05T09: 21: 59Z " > xmlns: ds = " http://www.w3.org/2000/09/xmldsig# " > ... Value = "urn: oasis: names: tc: SAML: 2.0: status: Success" /> xmlns: samlp = "urn: oasis: nombres: tc: SAML: 2.0: protocolo " xmlns: saml = " urn: oasis: nombres: tc: SAML: 2.0: aserción " ID = " identifier_3 " Versión = " 2.0 " IssueInstant = " 2004-12-05T09: 21: 59Z " Destination = " https://idp.example.org/SAML2/SSO/Artifact " ProtocolBinding = " urn: oasis: names: tc: SAML: 2.0: bindings: HTTP-Artifact " AssertionConsumerServiceURL = " https: // sp .example.com / SAML2 / SSO / Artifact " > https://sp.example.com/SAML2 AllowCreate = " false " Format = " urn: oasis: nombres: tc: SAML: 1.1: nombreid-formato: emailAddress " /> uest>
El servicio SSO procesa el
elemento y realiza una verificación de seguridad. Si el usuario no tiene un contexto de seguridad válido, el proveedor de identidad identifica al usuario (se omiten los detalles).
6. Redirigir al Servicio al consumidor de afirmaciones
El servicio SSO en el proveedor de identidad redirige al agente de usuario al servicio de consumidor de aserción en el proveedor de servicios. El RelayState
parámetro anterior y un nuevo SAMLart
parámetro se añaden a la URL de redireccionamiento.
7. Solicite el Servicio de Atención al Consumidor de Afirmación en el SP
El agente de usuario solicita el servicio de consumidor de aserción al proveedor de servicios:
https://sp.example.com/SAML2/SSO/Artifact?SAMLart= artifact_2 & RelayState = token
donde token
es el valor del token del paso 3 y artifact_2
es el artefacto SAML emitido en el paso 6.
8. Solicite el servicio de resolución de artefactos en el IdP
El servicio de consumidor de aserción elimina la referencia del artefacto enviando un
elemento vinculado a un mensaje SAML SOAP al servicio de resolución de artefactos en el proveedor de identidad:
xmlns: samlp = "urn: oasis: names: tc: SAML: 2.0: protocol" xmlns: saml = "urn: oasis: names: tc: SAML: 2.0: assertion" ID = "identifier_4" Version = " 2.0 " IssueInstant = " 2004-12-05T09: 22: 04Z " Destination = " https://idp.example.org/SAML2/ArtifactResolution " > https://sp.example.com/SAML2 < / saml: Issuer> xmlns: ds = "http://www.w3.org/2000/09/xmldsig#" > ... '' artifact_2 ''
donde el valor del
elemento es el artefacto SAML transmitido en el paso 7.
9. Responda con una afirmación SAML
El servicio de resolución de artefactos en el proveedor de identidad devuelve un
elemento (que contiene un
elemento) vinculado a un mensaje SAML SOAP al servicio de consumidor de aserción en el proveedor de servicios:
xmlns: samlp = "urn: oasis: names: tc: SAML: 2.0: protocol" ID = "identifier_5" InResponseTo = "identifier_4" Version = "2.0" IssueInstant = "2004-12-05T09: 22: 05Z " > xmlns: ds = " http://www.w3.org/2000/09/xmldsig# " > ... Value = "urn: oasis: names: tc: SAML: 2.0: status: Success" /> xmlns: samlp = "urn: oasis: nombres: tc: SAML: 2.0: protocolo " xmlns: saml = " urn: oasis: nombres: tc: SAML: 2.0: aserción " ID = " identifier_6 " InResponseTo = " identifier_3 " Versión = " 2.0 " IssueInstant = " 2004-12 -05T09: 22: 05Z " Destino = " https://sp.example.com/SAML2/SSO/Artifact " > https://idp.example.org/SAML2 < ds: Signature xmlns: ds = "http://www.w3.org/2000/09/xmldsig#" > ... Value = "urn: oasis : names: tc: SAML: 2.0: status: Success " /> xmlns: saml = " urn: oasis: names: tc: SAML: 2.0 : aserción " ID = " identifier_7 " Version = " 2.0 " IssueInstant = " 2004-12-05T09: 22: 05Z " > https://idp.example.org/SAML2 < ! - se requiere un elemento Subject -> Format = "urn: oasis: names: tc: SAML: 1.1: nameid-format: emailAddress" > [email protected] Method = "urn: oasis: names: tc: SAML: 2.0: cm: bearer" > InResponseTo = "identifier_3" Recipient = "https: //sp.example. com / SAML2 / SSO / Artifact " NotOnOrAfter = " 2004-12-05T09: 27: 05Z " /> NotBefore = " 2004-12-05T09: 17: 05Z " NotOnOrAfter = " 2004-12-05T09: 27: 05Z " > https://sp.example.com/SAML2 < / saml: Condiciones> AuthnInstant = "2004-12-05T09: 22: 00Z" SessionIndex = "identifier_7" > urn: oasis: nombres: tc: SAML: 2.0: ac: classes: PasswordProtectedTransport
10. Redirigir al recurso de destino
El servicio de consumidor de aserción procesa la respuesta, crea un contexto de seguridad en el proveedor de servicios y redirige al agente de usuario al recurso de destino.
11. Solicite el recurso de destino en el SP nuevamente
El agente de usuario solicita el recurso de destino al proveedor de servicios (nuevamente):
https://sp.example.com/myresource
12. Responder con el recurso solicitado
Dado que existe un contexto de seguridad, el proveedor de servicios devuelve el recurso al agente de usuario.
Perfil de descubrimiento del proveedor de identidad
El perfil de descubrimiento de proveedores de identidad de SAML 2.0 presenta los siguientes conceptos:
- Dominio común
- Cookie de dominio común
- Servicio de escritura de cookies de dominio común
- Servicio de lectura de cookies de dominio común
Como ejemplo hipotético de un dominio común , supongamos que Example UK (example.co.uk) y Example Deutschland (example.de) pertenecen a la organización virtual Example Global Alliance (example.com). En este ejemplo, el dominio example.com es el dominio común. Tanto Example UK como Example Deutschland tienen presencia en este dominio (uk.example.com y de.example.com, respectivamente).
La cookie de dominio común es una cookie de navegador segura cuyo ámbito es el dominio común. Para cada usuario del navegador, esta cookie almacena una lista histórica de los IdP visitados recientemente. El nombre y el valor de la cookie se especifican en el perfil de descubrimiento de IdP (SAMLProf [3] ).
Después de un acto de autenticación exitoso, el IdP solicita el Servicio de escritura de cookies de dominio común . Este servicio agrega el identificador único del IdP a la cookie de dominio común. El SP, cuando recibe una solicitud no autenticada de un recurso protegido, solicita al Servicio de lectura de cookies de dominio común que descubra el IdP utilizado más recientemente por el usuario del navegador.
Consulta de afirmación / perfil de solicitud
El perfil de consulta / solicitud de afirmación es un perfil general que se adapta a numerosos tipos de las llamadas consultas que utilizan los siguientes elementos de SAML 2.0:
- el
elemento, que se utiliza para solicitar una aserción dado su identificador único (ID
) - el
elemento, que es un punto de extensión abstracto que permite definir nuevas consultas SAML basadas en sujetos - el
elemento, que se utiliza para solicitar aserciones de autenticación existentes sobre un tema determinado de una autoridad de autenticación - el
elemento, que se utiliza para solicitar atributos sobre un tema determinado de una autoridad de atributos - el
elemento, que se utiliza para solicitar una decisión de autorización de un tercero de confianza
El enlace SAML SOAP se usa a menudo junto con consultas.
Consulta de atributo SAML
La consulta de atributos es quizás el tipo más importante de consulta SAML. A menudo, un solicitante, que actúa en nombre del principal, consulta a un proveedor de identidad en busca de atributos. A continuación, damos un ejemplo de una consulta emitida por un principal directamente:
xmlns: saml = "urn: oasis: names: tc: SAML: 2.0: assertion" xmlns: samlp = "urn: oasis: names: tc: SAML: 2.0: protocol" ID = "aaf23196-1773-2113 -474a-fe114412ab72 " Version = " 2.0 " IssueInstant = " 2006-07-17T20: 31: 40Z " > Format = " urn: oasis: names: tc: SAML: 1.1: nameid-format: X509SubjectName " > CN = trscavo @ uiuc.edu, OU = Usuario, O = NCSA-TEST, C = US Format = "urn: oasis: names: tc: SAML: 1.1: nameid-format: X509SubjectName" > CN = trscavo @ uiuc.edu, OU = Usuario, O = NCSA-TEST, C = US NameFormat = "urn: oasis: names: tc: SAML: 2.0: attrname-format: uri" Name = "urn: oid: 2.5.4.42" FriendlyName = "givenName" > NameFormat = "urn: oasis: names: tc: SAML: 2.0: attrname-format: uri" Name = "urn: oid: 1.3.6.1.4.1.1466.115. 121.1.26 " FriendlyName = " mail " >
Tenga en cuenta que Issuer
es el Subject
en este caso. Esto a veces se denomina autoconsulta de atributos . Un proveedor de identidad puede devolver la siguiente aserción, envuelta en un
elemento (no se muestra):
xmlns: saml = "urn: oasis: names: tc: SAML: 2.0: assertion" xmlns: xs = "http://www.w3.org/2001/XMLSchema" xmlns: xsi = "http: / /www.w3.org/2001/XMLSchema-instance " xmlns: ds = " http://www.w3.org/2000/09/xmldsig# " ID = " _33776a319493ad607b7ab3e689482e45 " Version = " 2.0 " IssueInstant = " 2006- 07-17T20: 31: 41Z " > https://idp.example.org/SAML2 ... Format = "urn: oasis: names: tc: SAML: 1.1: nameid-format: X509SubjectName" > CN = trscavo @ uiuc.edu, OU = Usuario, O = NCSA-TEST, C = US Method = "urn: oasis: names: tc: SAML: 2.0: cm: holder-of-key" > < ! - certificado X.509 del director -> MIICiDCCAXACCQDE + 9eiWrm62jANBgkqhkiG9w0BAQQFADBFMQswCQYDVQQGEwJV UzESMBAGA1UEChMJTkNTQS1URVNUMQ0wCwYDVQQLEwRVc2VyMRMwEQYDVQQDEwpT UC1TZXJ2aWNlMB4XDTA2MDcxNzIwMjE0MVoXDTA2MDcxODIwMjE0MVowSzELMAkG A1UEBhMCVVMxEjAQBgNVBAoTCU5DU0EtVEVTVDENMAsGA1UECxMEVXNlcjEZMBcG A1UEAwwQdHJzY2F2b0B1aXVjLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEAv9QMe4lRl3XbWPcflbCjGK9gty6zBJmp + tsaJINM0VaBaZ3t + tSXknelYife nCc2O3yaX76aq53QMXy + 5wKQYe8Rzdw28Nv3a73wfjXJXoUhGkvERcscs9EfIWcC g2bHOg8uSh + Fbv3lHih4lBJ5MCS2buJfsR7dlr / xsadU2RcCAwEAATANBgkqhkiG 9w0BAQQFAAOCAQEAdyIcMTob7TVkelfJ7 + I1j0LO24UlKvbLzd2OPvcFTCv6fVHx Ejk0QxaZXJhreZ6 + rIdiMXrEzlRdJEsNMxtDW8 ++ sVp6avoB5EX1y3ez + CEAIL4g cjvKZUR4dMryWshWIBHKFFul + r7urUgvWI12KbMeE9KP + kiiiiTskLcKgFzngw1J selmHhTcTCrcDocn5yO2 + d3dog52vSOtVFDBsBuvDixO2hv679JR6Hlqjtk4GExp E9iVI0wdPE038uQIJJTXlhsMMLvUGVh / c0ReJBn92Vj4dI / yy6PtY / 8ncYLYNkjg oVN0J / ymOktn9lTlFyTiuY4OuJsZRO1 + zWLy9g == NotBefore = "2006-07-17T20: 31: 41Z" NotOnOrAfter = "2006-07-18T20: 21: 41Z" > AuthnInstant = "2006-07- 17T20: 31: 41Z " > urn: oasis: nombres: tc: SAML: 2.0: ac: clases: TLSClient xmlns: x500 = "urn: oasis: nombres: tc: SAML: 2.0: perfiles: atributo: X500" x500: Encoding = "LDAP" NameFormat = "urn: oasis: names: tc: SAML: 2.0: attrname-format: uri" Name = "urn: oid: 2.5.4.42" FriendlyName = "givenName" > xsi : type = "xs: string" > Tom xmlns: x500 = "urn: oasis: nombres: tc: SAML: 2.0: perfiles: atributo: X500" x500 : Encoding = "LDAP" NameFormat = "urn: oasis: names: tc: SAML: 2.0: attrname-format: uri" Name = "urn: oid: 1.3.6.1.4.1.1466.115.121.1.26" FriendlyName = "correo " > xsi: type = " xs: string " > [email protected]
A diferencia de la BearerAssertion mostrada anteriormente, esta aserción tiene una vida útil más larga correspondiente a la vida útil del certificado X.509 que el principal utilizó para autenticarse ante el proveedor de identidad. Además, dado que la aserción está firmada, el usuario puede enviar esta aserción a una parte que confía, y siempre que el usuario pueda probar la posesión de la clave privada correspondiente (de ahí el nombre "poseedor de la clave"), la parte que confía puede tenga la seguridad de que la afirmación es auténtica.
Metadatos SAML 2.0
Literalmente, los metadatos son lo que hace que SAML funcione (o funcione bien). Algunos usos importantes de los metadatos incluyen:
- Un proveedor de servicios se prepara para transmitir un
elemento a un proveedor de identidad a través del navegador. ¿Cómo sabe el proveedor de servicios del proveedor de identidad es auténtico y no un proveedor de identidad del mal tratando de phishing contraseña del usuario? El proveedor de servicios consulta su lista de proveedores de identidad confiables en metadatos antes de emitir una solicitud de autenticación. - En el escenario anterior, ¿cómo sabe el proveedor de servicios a dónde enviar al usuario con la solicitud de autenticación? El proveedor de servicios busca una ubicación de punto final preestablecida del proveedor de identidad de confianza en los metadatos .
- Un proveedor de identidad recibe un
elemento de un proveedor de servicios a través del navegador. ¿Cómo sabe el proveedor de identidad que el proveedor de servicios es auténtico y no un proveedor de servicios malvado que intenta recopilar información de identificación personal sobre el usuario? El proveedor de identidad consulta su lista de proveedores de servicios de confianza en metadatos antes de emitir una respuesta de autenticación. - En el escenario anterior, ¿cómo cifra el proveedor de identidad la aserción SAML para que el proveedor de servicios de confianza (y solo el proveedor de servicios de confianza) pueda descifrar la aserción? El proveedor de identidad utiliza el certificado de cifrado del proveedor de servicios en los metadatos para cifrar la afirmación.
- Continuando con el escenario anterior, ¿cómo sabe el proveedor de identidad a dónde enviar al usuario con la respuesta de autenticación? El proveedor de identidad busca una ubicación de punto final preestablecida del proveedor de servicios de confianza en los metadatos .
- ¿Cómo sabe el proveedor de servicios que la respuesta de autenticación provino de un proveedor de identidad confiable? El proveedor de servicios verifica la firma en la aserción utilizando la clave pública del proveedor de identidad a partir de los metadatos .
- ¿Cómo sabe el proveedor de servicios dónde resolver un artefacto recibido de un proveedor de identidad de confianza? El proveedor de servicios busca la ubicación del punto final preestablecido del servicio de resolución de artefactos del proveedor de identidad a partir de los metadatos .
Los metadatos garantizan una transacción segura entre un proveedor de identidad y un proveedor de servicios. Antes de los metadatos, la información de confianza se codificaba en la implementación de forma patentada. Ahora, los metadatos estándar facilitan el intercambio de información de confianza. SAML 2.0 proporciona un formato de metadatos interoperable bien definido que las entidades pueden aprovechar para iniciar el proceso de confianza.
Metadatos del proveedor de identidad
Un proveedor de identidad publica datos sobre sí mismo en un
elemento:
entityID = "https://idp.example.org/SAML2" validUntil = "2013-03-22T23: 00: 00Z" xmlns: md = "urn: oasis: nombres: tc: SAML: 2.0: metadatos " xmlns: saml = " urn: oasis: names: tc: SAML: 2.0: assertion " xmlns: ds = " http://www.w3.org/2000/09/xmldsig# " > xml: lang = "en" > Alguna organización sin fines de lucro de Nueva York xml: lang = "en" > Alguna organización sin fines de lucro xml: lang = "en" > https://www.example.org/ < / md: OrganizationURL> contactType = "technical" > Soporte técnico de SAML mailto: [email protected] < / md: EmailAddress>
Tenga en cuenta los siguientes detalles sobre este descriptor de entidad:
- El
entityID
atributo es el identificador único de la entidad. - El
validUntil
atributo da la fecha de vencimiento de los metadatos. - El
elemento (que se ha omitido por simplicidad) contiene una firma digital que asegura la autenticidad e integridad de los metadatos. - La organización identificada en el
elemento es "responsable de la entidad" descrita por el descriptor de entidad (sección 2.3.2 de SAMLMeta [4] ). - La información de contacto en el
elemento identifica un contacto técnico responsable de la entidad. Son posibles múltiples contactos y tipos de contactos. Consulte la sección 2.3.2.2 de SAMLMeta. [4]
Por definición, un proveedor de identidad administra un servicio SSO que admite el perfil SSO del navegador web SAML especificado en SAMLProf. [3] Véase, por ejemplo, el proveedor de identidad descrito en el
elemento que se muestra en la siguiente sección.
Metadatos del servicio SSO
El servicio SSO en el proveedor de identidad se describe en un
elemento:
protocolSupportEnumeration = "urn: oasis: names: tc: SAML: 2.0: protocol" > use = "signing" > ... isDefault = "true" index = "0" Binding = "urn: oasis: names: tc: SAML: 2.0: bindings: SOAP" Location = "https://idp.example.org/SAML2/ ArtifactResolution " /> urn: oasis: names: tc: SAML: 1.1: nameid-format: emailAddress urn: oasis: names: tc: SAML: 2.0: nameid -format: transient Binding = "urn: oasis: names: tc: SAML: 2.0: bindings: HTTP-Redirect" Location = "https://idp.example.org/SAML2/ SSO / Redirect " /> Binding = " urn: oasis: names: tc: SAML: 2.0: bindings: HTTP-POST " Location = " https://idp.example.org/SAML2/SSO/POST " /> Binding = "urn: oasis: names: tc: SAML: 2.0: bindings: HTTP-Artifact" Location = "https://idp.example.org/SAML2/Artifact" /> NameFormat = "urn: oasis: nombres: tc : SAML: 2.0: attrname-format: uri " Name = " urn: oid: 1.3.6.1.4.1.5923.1.1.1.1 " FriendlyName = " eduPersonAffiliation " > miembro estudiante facultad empleado personal AttributeValue> Atributo>
El elemento de metadatos anterior describe el servicio SSO en el proveedor de identidad. Tenga en cuenta los siguientes detalles sobre este elemento:
- El software del proveedor de identidad está configurado con una clave de firma SAML privada y / o una clave TLS de canal secundario privado. La clave pública correspondiente se incluye en el
elemento de los metadatos de IdP. El material clave se ha omitido del descriptor clave por brevedad. - El
Binding
atributo del
elemento indica que el enlace SAML SOAP (SAMLBind [2] ) debe utilizarse para la resolución de artefactos. - El
Location
atributo del
elemento se utiliza en el paso 8 del perfil de " artefacto doble ". - El valor del
index
atributo del
elemento se utiliza comoEndpointIndex
en la construcción de un artefacto SAML tipo 0x0004. - Los
elementos indican qué formatos de identificador de nombre SAML (SAMLCore [1] ) admite el servicio SSO. - Los
Binding
atributos de los
elementos son URI estándar especificados en la especificación de enlace SAML 2.0 (SAMLBind [2] ). - El
Location
atributo del
elemento que admite el enlace HTTP POST se utiliza en el paso 2 del perfil " POST doble ". - El
Location
atributo del
elemento que admite el enlace de artefacto HTTP se utiliza en el paso 2 del perfil de " artefacto doble ". - El
elemento describe un atributo que el proveedor de identidad está dispuesto a afirmar (sujeto a la política). Los
elementos enumeran los posibles valores que puede tomar el atributo.
Como se señaló al principio de esta sección, Location
un proveedor de servicios utiliza los valores de los atributos para enrutar mensajes SAML, lo que minimiza la posibilidad de que un proveedor de identidad deshonesto orquesta un ataque de intermediario .
Metadatos del proveedor de servicios
Al igual que el proveedor de identidad, un proveedor de servicios publica datos sobre sí mismo en un
elemento:
entityID = "https://sp.example.com/SAML2" validUntil = "2013-03-22T23: 00: 00Z" xmlns: md = "urn: oasis: nombres: tc: SAML: 2.0: metadatos " xmlns: saml = " urn: oasis: names: tc: SAML: 2.0: assertion " xmlns: ds = " http://www.w3.org/2000/09/xmldsig# " > xml: lang = "en" > Algún proveedor comercial de California xml: lang = "en" > Algún proveedor comercial xml: lang = "en" > https://www.example.com/ contactType = "technical" > Soporte técnico de SAML mailto: [email protected]
Tenga en cuenta los siguientes detalles sobre este descriptor de entidad:
- El
entityID
atributo es el identificador único de la entidad. - El
validUntil
atributo da la fecha de vencimiento de los metadatos. - El
elemento (que se ha omitido por simplicidad) contiene una firma digital que asegura la autenticidad e integridad de los metadatos. - La organización identificada en el
elemento es "responsable de la entidad" descrita por el descriptor de entidad (sección 2.3.2 de SAMLMeta [4] ). - La información de contacto en el
elemento identifica un contacto técnico responsable de la entidad. Son posibles múltiples contactos y tipos de contactos. Consulte la sección 2.3.2.2 de SAMLMeta. [4]
Por definición, un proveedor de servicios administra un servicio de consumidor de aserción que admite el perfil SSO del navegador web SAML especificado en SAMLProf. [3] Véase, por ejemplo, el proveedor de servicios descrito en el
elemento que se muestra en la siguiente sección.
Afirmación de metadatos de servicio al consumidor
El servicio de consumidor de aserción está contenido en un
elemento:
protocolSupportEnumeration = "urn: oasis: names: tc: SAML: 2.0: protocol" > use = "signing" > ... use = "encryption" > ... isDefault = "true" index = "0" Binding = "urn : oasis: nombres: tc: SAML: 2.0: enlaces: SOAP " Location = " https://sp.example.com/SAML2/ArtifactResolution " /> urn: oasis: nombres: tc: SAML: 1.1 : nameid-format: emailAddress urn: oasis: names: tc: SAML: 2.0: nameid-format: transitorio isDefault = "true" index = "0" Binding = "urn: oasis: names: tc: SAML: 2.0: bindings: HTTP-POST" Location = "https://sp.example.com/SAML2/SSO/POST" /> index = "1" Binding = "urn: oasis: names: tc: SAML: 2.0: bindings: HTTP-Artifact" Location = "https://sp.example.com/SAML2/Artifact" /> isDefault = "verdadero" índice = " 1 " > xml: lang = " en " > Portal de proveedores de servicios NameFormat = " urn: oasis: names: tc: SAML: 2.0: attrname-format: uri " Nombre = "urn: oid: 1.3.6.1.4.1.5923.1.1.1.1" FriendlyName = "eduPersonAffiliation" >
Tenga en cuenta los siguientes detalles sobre el
elemento de metadatos:
- El software del proveedor de servicios está configurado con una clave de firma SAML privada y / o una clave TLS de canal secundario privado. La clave pública correspondiente se incluye en el
elemento de los metadatos del SP. El material clave se ha omitido del descriptor clave por brevedad. - Asimismo, el software del proveedor de servicios está configurado con una clave de descifrado SAML privada. Se incluye una clave de cifrado SAML pública en el
elemento de los metadatos del SP. El material clave se ha omitido del descriptor clave por brevedad. - El
index
atributo de un
elemento se usa como el valor delAssertionConsumerServiceIndex
atributo en un
elemento. - Los
Binding
atributos de los
elementos son URI estándar especificados en la especificación de enlace SAML 2.0 (SAMLBind [2] ). - El
Location
atributo del
elemento que admite el enlace HTTP POST (index="0"
) se utiliza en el paso 4 del perfil " POST doble ". - El
Location
atributo del
elemento que admite el enlace de artefacto HTTP (index="1"
) se utiliza en el paso 6 del perfil de " artefacto doble ". - El
proveedor de identidad utiliza el
elemento para formular un elemento que se envía al proveedor de servicios junto con el SSO del navegador web. - El
index
atributo del
elemento se usa como el valor delAttributeConsumingServiceIndex
atributo en un
elemento.
Como se señaló al principio de esta sección, los valores de los Location
atributos son utilizados por un proveedor de identidad para enrutar mensajes SAML, lo que minimiza la posibilidad de que un proveedor de servicios deshonesto orquesta un ataque de intermediario .
Agregados de metadatos
En los ejemplos anteriores,
se muestra que cada elemento está firmado digitalmente. En la práctica, sin embargo, varios
elementos se agrupan bajo un
elemento con una única firma digital en todo el agregado:
validUntil = "2013-03-22T23: 00: 00Z" xmlns: md = "urn: oasis: names: tc: SAML: 2.0: metadata" xmlns: saml = "urn: oasis: names: tc: SAML : 2.0: aserción " xmlns: ds = " http://www.w3.org/2000/09/xmldsig# " > entityID = " https://idp.example.org/SAML2 " > ... entityID = "https://sp.example.com/SAML2" > ...
Tenga en cuenta los siguientes detalles sobre el
elemento anterior :
- La firma digital (que se ha omitido por brevedad) cubre todo el conjunto.
- El
validUntil
atributo XML se ha elevado al elemento principal, lo que implica que la fecha de vencimiento se aplica a cada elemento secundario. - Las declaraciones de espacios de nombres XML se han elevado al elemento principal para evitar declaraciones de espacios de nombres redundantes.
Por lo general, los agregados de metadatos son publicados por terceros de confianza llamados federaciones que garantizan la integridad de todos los metadatos en el agregado. Tenga en cuenta que los agregados de metadatos pueden ser muy grandes, compuestos por cientos o incluso miles de entidades por agregado.
Ver también
- Lenguaje de marcado de afirmación de seguridad
- SAML 1.1
- Metadatos SAML
- Productos y servicios basados en SAML
- Conexión OpenID
Referencias
Referencias primarias:
- ^ a b c S. Cantor y col. Afirmaciones y protocolos para el lenguaje de marcado de afirmaciones de seguridad (SAML) V2.0 de OASIS - Compuesto de erratas. Borrador de trabajo 07, 8 de septiembre de 2015. ID de documento sstc-saml-core-errata-2.0-wd-07 http://www.oasis-open.org/committees/download.php/56776/sstc-saml-core-errata -2.0-wd-07.pdf
- ^ a b c d e f g S. Cantor et al. Enlaces para el lenguaje de marcado de afirmaciones de seguridad (SAML) V2.0 de OASIS - Compuesto de erratas. Borrador de trabajo 06, 8 de septiembre de 2015. ID de documento sstc-saml-bindings-errata-2.0-wd-06 https://www.oasis-open.org/committees/download.php/56779/sstc-saml-bindings-errata -2.0-wd-06.pdf
- ^ a b c d e f g J. Hughes y col. Perfiles para el lenguaje de marcado de afirmaciones de seguridad (SAML) V2.0 de OASIS - Compuesto de erratas. Borrador de trabajo 07, 8 de septiembre de 2015. ID de documento sstc-saml-profiles-errata-2.0-wd-07 https://www.oasis-open.org/committees/download.php/56782/sstc-saml-profiles-errata -2.0-wd-07.pdf
- ^ a b c d e S. Cantor y col. Metadatos para OASIS Security Assertion Markup Language (SAML) V2.0 - Compuesto de erratas. Borrador de trabajo 05, 8 de septiembre de 2015. ID de documento sstc-saml-metadata-errata-2.0-wd-05 https://www.oasis-open.org/committees/download.php/56785/sstc-saml-metadata-errata -2.0-wd-05.pdf
Referencias secundarias:
- P. Mishra y col. Requisitos de conformidad para el lenguaje de marcado de afirmaciones de seguridad (SAML) V2.0 de OASIS - Compuesto de erratas. Borrador de trabajo 04, 1 de diciembre de 2009. ID de documento sstc-saml-conformance-errata-2.0-wd-04 https://www.oasis-open.org/committees/download.php/35393/sstc-saml-conformance-errata -2.0-wd-04-diff.pdf
- N. Ragouzis et al., Descripción técnica de Security Assertion Markup Language (SAML) V2.0. Borrador del Comité OASIS, marzo de 2008. ID de documento sstc-saml-tech-overview-2.0-cd-02 http://www.oasis-open.org/committees/download.php/27819/sstc-saml-tech-overview- 2.0-cd-02.pdf
- P. Madsen et al., SAML V2.0 Executive Overview. Borrador del Comité OASIS, abril de 2005. ID de documento sstc-saml-tech-overview-2.0-cd-01-2col http://www.oasis-open.org/committees/download.php/13525/sstc-saml-exec- descripción general-2.0-cd-01-2col.pdf
- J. Kemp y col. Contexto de autenticación para el lenguaje de marcado de afirmación de seguridad (SAML) V2.0 de OASIS. Estándar OASIS, marzo de 2005. ID de documento saml-authn-context-2.0-os http://docs.oasis-open.org/security/saml/v2.0/saml-authn-context-2.0-os.pdf
- F. Hirsch y col. Consideraciones de seguridad y privacidad para OASIS Security Assertion Markup Language (SAML) V2.0. Estándar OASIS, marzo de 2005. ID de documento saml-sec-consider-2.0-os http://docs.oasis-open.org/security/saml/v2.0/saml-sec-consider-2.0-os.pdf
- J. Hodges y col. Glosario del lenguaje de marcado de afirmaciones de seguridad (SAML) V2.0 de OASIS. Estándar OASIS, marzo de 2005. ID de documento saml-glossary-2.0-os http://docs.oasis-open.org/security/saml/v2.0/saml-glossary-2.0-os.pdf
Referencias obsoletas:
- P. Mishra y col. Requisitos de conformidad para el lenguaje de marcado de afirmaciones de seguridad (SAML) V2.0 de OASIS. Estándar OASIS, marzo de 2005. ID de documento saml-conformance-2.0-os http://docs.oasis-open.org/security/saml/v2.0/saml-conformance-2.0-os.pdf
- S. Cantor y col. Afirmaciones y protocolos para el lenguaje de marcado de aserción de seguridad (SAML) V2.0 de OASIS. Estándar OASIS, marzo de 2005. ID de documento saml-core-2.0-os http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf
- S. Cantor y col. Enlaces para el lenguaje de marcado de aserción de seguridad de OASIS (SAML) V2.0. Estándar OASIS, marzo de 2005. ID de documento saml-bindings-2.0-os http://docs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf
- S. Cantor y col. Perfiles para el lenguaje de marcado de afirmaciones de seguridad (SAML) V2.0 de OASIS. Estándar OASIS, marzo de 2005. ID de documento saml-profiles-2.0-os http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf
- S. Cantor y col. Metadatos para el lenguaje de marcado de afirmaciones de seguridad (SAML) V2.0 de OASIS. Estándar OASIS, marzo de 2005. ID de documento saml-metadata-2.0-os http://docs.oasis-open.org/security/saml/v2.0/saml-metadata-2.0-os.pdf