Hispanopedia Wiki
Articulo de referencia

SAML 2.0

El Lenguaje de Marcado de Aserciones de Seguridad ( SAML ) 2.0 es una versión del estándar SAML para el intercambio de identidades de autenticación y autorización entre dominios...

Hispanopedia WikiContenido en espanolLectura gratuita

El Lenguaje de Marcado de Aserciones de Seguridad ( SAML ) 2.0 es una versión del estándar SAML para el intercambio de 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 transmitir información sobre una entidad 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 (SSO) basado en web y entre dominios , lo que ayuda a reducir la carga administrativa de distribuir múltiples tokens de autenticación al usuario. 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 ]   

En la creación de SAML 2.0 participaron unas 30 personas de más de 24 empresas y organizaciones.  En particular, y cabe destacar, 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. Así, SAML  2.0 representa la convergencia de SAML 1.1 , Liberty ID-FF  1.2 (archivado el 24 de febrero de 2021 en Wayback Machine) y Shibboleth  1.3 .

Aserciones SAML 2.0

Una aserción es un paquete de información que proporciona cero o más declaraciones realizadas por una autoridad SAML. Las aserciones SAML generalmente se realizan sobre un sujeto, representado por el <Subject>elemento. La especificación SAML 2.0 define tres tipos diferentes de declaraciones de aserción que puede crear una autoridad SAML. Todas las declaraciones definidas por SAML están asociadas a un sujeto. Los tres tipos de declaraciones de aserción se definen de la siguiente manera:

  • Declaración de autenticación: El sujeto de la afirmación fue autenticado por un medio particular en un momento determinado.
  • Declaración de atributos: El sujeto de la aserción está asociado con los atributos proporcionados.
  • Declaración de decisión de autorización: Se ha concedido o denegado la solicitud para permitir que el sujeto de la afirmación acceda al recurso especificado.

Un tipo importante de aserción SAML es la denominada aserción "bearer", utilizada para facilitar el inicio de sesión único (SSO) en navegadores web. Aquí se muestra un ejemplo de una aserción bearer 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 <saml:AuthnStatement>como una aserción de atributo <saml:AttributeStatement>, que presumiblemente el proveedor de servicios utiliza para tomar una decisión de control de acceso. El prefijo saml:representa el espacio de nombres de aserciones SAML V2.0.

Ejemplo de SAML

<saml:Assertion 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" > <saml:Issuer> https://idp.example.org/SAML2 </saml:Issuer> <ds:Signature xmlns:ds= "http://www.w3.org/2000/09/xmldsig#" > ... </ds:Signature> <saml:Subject> <saml:NameID Format= "urn:oasis:names:tc:SAML:2.0:nameid-format:transient" > 3f7b3dcf-1674-4ecd-92c8-1544f346baf8 </saml:NameID> <saml:SubjectConfirmation Method= "urn:oasis:names:tc:SAML:2.0:cm:bearer" > <saml:SubjectConfirmationData InResponseTo= "aaf23196-1773-2113-474a-fe114412ab72" Recipient= "https://sp.example.com/SAML2/SSO/POST" NotOnOrAfter= "2004-12-05T09:27:05Z" /> </saml:SubjectConfirmation> </saml:Subject> <saml:Conditions NotBefore= "2004-12-05T09:17:05Z" NotOnOrAfter= "2004-12-05T09:27:05Z" > <saml:AudienceRestriction> <saml:Audience> https://sp.example.com/SAML2 </saml:Audience> </saml:AudienceRestriction> </saml:Conditions> <saml:AuthnStatement AuthnInstant= "2004-12-05T09:22:00Z" SessionIndex= "b07b804c-7c29-ea16-7300-4f3d6f7928ac" > <saml:AuthnContext> <saml:AuthnContextClassRef> urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport </saml:AuthnContextClassRef> </saml:AuthnContext > </saml :AuthnStatement> <saml:AttributeStatement> <saml:Attribute xmlns:x500= "urn:oasis:names:tc:SAML:2.0:profiles:attribute: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" > <saml:AttributeValue xsi:type= "xs:string" > member </saml:AttributeValue> <saml:AttributeValue xsi:type= "xs:string" > staff </saml:AttributeValue> </saml:Attribute> </saml:AttributeStatement> </saml:Assertion>

Tenga en cuenta que en el ejemplo anterior el <saml:Assertion>elemento contiene los siguientes elementos secundarios:

  • un <saml:Issuer>elemento que contiene el identificador único del proveedor de identidad.
  • un elemento, que contiene una firma digital<ds:Signature> que preserva la integridad (no se muestra) sobre el elemento<saml:Assertion>
  • un <saml:Subject>elemento que identifica al principal autenticado (pero en este caso la identidad del principal está oculta tras un identificador transitorio opaco, por razones de privacidad).
  • un <saml:Conditions>elemento que establece las condiciones bajo las cuales la afirmación debe considerarse válida
  • un <saml:AuthnStatement>elemento que describe el acto de autenticación en el proveedor de identidad.
  • un <saml:AttributeStatement>elemento que afirma un atributo multivalor asociado con el principal autenticado

En otras palabras, la afirmación codifica la siguiente información:

La aserción ("b07b804c-7c29-ea16-7300-4f3d6f7928ac") fue emitida a las "2004-12-05T09:22:05Z" por el proveedor de identidad ( https://idp.example.org/SAML2 ) con respecto al sujeto (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 <saml:Subject>elemento fue autenticado a las 09:22:00Z del 5 de diciembre de 2004 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 <saml:Subject>elemento tiene los atributos de "personal" y "miembro" en esta institución.

Protocolos SAML 2.0

Los siguientes protocolos se especifican en SAMLCore: [ 1 ]

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 SSO del navegador web son iniciados por el proveedor de identidad (IDP) , es decir, <samlp:Response>se transmite un elemento no solicitado desde el proveedor de identidad al proveedor de servicios (a través del navegador). (El prefijo samlp:indica el espacio de nombres del protocolo SAML).

En SAML  2.0, sin embargo, el flujo comienza en el proveedor de servicios, quien emite una solicitud de autenticación explícita al proveedor de identidad. El Protocolo de Solicitud de Autenticación resultante es una característica nueva e 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, <samlp:AuthnRequest>se transmite un elemento al proveedor de identidad:

<samlp:AuthnRequest xmlns:samlp= "urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml= "urn:oasis:names:tc:SAML:2.0:assertion" ID= "aaf23196-1773-2113-474a-fe114412ab72" Version= "2.0" IssueInstant= "2004-12-05T09:21:59Z" AssertionConsumerServiceIndex= "0" AttributeConsumingServiceIndex= "0" > <saml:Issuer> https://sp.example.com/SAML2 </saml:Issuer> <samlp:NameIDPolicy AllowCreate= "true" Format= "urn:oasis:names:tc:SAML:2.0:nameid-format:transient" /> </samlp:AuthnRequest>

El <samlp:AuthnRequest>elemento mencionado, que solicita implícitamente una aserción que contiene una declaración de autenticación , fue 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 usuario (si es necesario) y emite una respuesta de autenticación, que se transmite de vuelta 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 <samlp:ArtifactResolve>solicitud directamente al emisor del artefacto, quien responde con el mensaje real al que hace referencia el artefacto.

Supongamos, por ejemplo, que un proveedor de identidad envía la siguiente <samlp:ArtifactResolve>solicitud directamente a un proveedor de servicios (a través de un canal secundario):

<samlp:ArtifactResolve 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" > <saml:Issuer> https://idp.example.org/SAML2 </saml:Issuer> <!-- un mensaje de ArtifactResolve DEBE estar firmado --> <ds:Signature xmlns:ds= "http://www.w3.org/2000/09/xmldsig#" > ... </ds:Signature> <samlp:Artifact> AAQAAMh48/1oXIM+sDo7Dh2qMp1HM4IF5DaRNmDj6RdUmllwn9jJHyEgIi8= </samlp:Artifact> </samlp:ArtifactResolve>

En respuesta, el proveedor de servicios devuelve el elemento SAML al que hace referencia el artefacto adjunto. Este protocolo constituye la base del enlace de artefactos HTTP .

Enlaces SAML 2.0

Los enlaces compatibles con SAML  2.0 se describen en la especificación de enlaces (SAMLBind [ 2 ] ):

Para el inicio de sesión único (SSO) mediante navegador web, se suelen utilizar los enlaces HTTP Redirect y HTTP POST. 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 del enlace por parte de una entidad es independiente de la elección del enlace por parte de su socio.

Enlace de redirección HTTP

Los mensajes del protocolo SAML pueden transportarse directamente en la cadena de consulta de la URL de una solicitud HTTP GET. Dado que la longitud de las URL es limitada en la práctica, el enlace HTTP Redirect es adecuado para mensajes cortos, como el <samlp:AuthnRequest>mensaje. Los mensajes más largos (por ejemplo, aquellos que contienen aserciones SAML firmadas o cifradas, como las respuestas SAML) generalmente se transmiten a través de otros enlaces, como el enlace HTTP POST .

Las solicitudes o respuestas SAML transmitidas mediante redirección HTTP tienen un parámetro de cadena de consulta SAMLRequesto SAMLResponse, respectivamente. Antes de enviarse, el mensaje se descomprime (sin encabezado ni suma de verificación), se codifica en base64 y se codifica en URL, en ese orden. Al recibirse, el proceso se revierte para recuperar el mensaje original.

Por ejemplo, al codificar el <samlp:AuthnRequest>mensaje anterior se obtiene:

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 su lectura) puede firmarse para mayor seguridad. En la práctica, todos los datos contenidos en una solicitud <samlp:AuthnRequest>, como Issuerla que incluye el ID del proveedor de servicios (SP ID) y la URL NameIDPolicydel servicio de consumidor de aserciones (SP), han sido acordados previamente entre el proveedor de identidad (IdP) y el proveedor de servicios (SP) (mediante intercambio manual de información o metadatos SAML ). En ese caso, firmar la solicitud no supone una restricción de seguridad. Cuando la <samlp:AuthnRequest>solicitud contiene información que el IdP desconoce de antemano, como la URL del servicio de consumidor de aserciones, se recomienda firmarla 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.... </form>​​

El valor del SAMLRequestparámetro es la codificación base64 de un <samlp:AuthnRequest>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 = "''response''" /> ... </form>​​

El valor del SAMLResponseparámetro es la codificación base64 de un <samlp:Response>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 parte de la página XHTML:

ventana.onload = function ( ) { documento.forms [ 0 ] .submit ( ) ; }​

Esto supone, por supuesto, que el primer elemento del formulario en la página contiene el formelemento que contiene SAMLResponse mencionado anteriormente ( forms[0]).

Enlace de artefactos HTTP

El enlace de artefactos HTTP utiliza el Protocolo de resolución de artefactos y el enlace SAML SOAP (sobre HTTP) para resolver un mensaje SAML por referencia. Consideremos el siguiente ejemplo específico. Supongamos que un proveedor de servicios desea enviar un <samlp:AuthnRequest>mensaje a un proveedor de identidades. Inicialmente, el proveedor de servicios transmite un artefacto al proveedor de identidades mediante una redirección HTTP:

https://idp.example.org/SAML2/SSO/Artifact ?SAMLart= artefacto

A continuación, el proveedor de identidad envía una <samlp:ArtifactResolve>solicitud (como la ArtifactResolveRequest que se mostró anteriormente) directamente al proveedor de servicios a través de un canal secundario. Finalmente, el proveedor de servicios devuelve un <samlp:ArtifactResponse>elemento que contiene el <samlp:AuthnRequest>mensaje referenciado:

<samlp:ArtifactResponse xmlns:samlp= "urn:oasis:names:tc:SAML:2.0:protocol" ID= "_d84a49e5958803dedcff4c984c2b0d95" InResponseTo= "_cce4ee769ed970b501d680f697989d14" Version= "2.0" IssueInstant= "2004-12-05T09:21:59Z" > <!-- un mensaje ArtifactResponse DEBE estar firmado --> <ds:Signature xmlns:ds= "http://www.w3.org/2000/09/xmldsig#" > ... </ds:Signature> <samlp:Status> <samlp:StatusCode Value= "urn:oasis:names:tc:SAML:2.0:status:Success" /> </samlp:Status> <samlp:AuthnRequest xmlns:samlp= "urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml= "urn:oasis:names:tc:SAML:2.0:assertion" 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" > <saml:Issuer> https://sp.example.com/SAML2 </saml:Issuer> <samlp:NameIDPolicy AllowCreate= "false" Format= "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress" /> </samlp:AuthnRequest> </samlp:ArtifactResponse>

Por supuesto, el flujo también puede darse en sentido contrario; es decir, el proveedor de identidad puede emitir un artefacto, y de hecho, esto es más común. Véase, por ejemplo, el ejemplo de perfil de " doble artefacto " más adelante en este tema.

Formato del artefacto

En general, un artefacto SAML  2.0 se define de la siguiente manera (SAMLBind [ 2 ] ):

SAML_artifact := B64 (TypeCode EndpointIndex RemainingArtifact) Código de tipo := Byte1Byte2 EndpointIndex := Byte1Byte2

Así, un  artefacto SAML 2.0 consta de tres componentes: un identificador de dos bytes TypeCode, un identificador de dos bytes EndpointIndexy una secuencia arbitraria de bytes denominada clave RemainingArtifact. Estas tres piezas de información se concatenan y codifican en base64 para generar el artefacto completo.

El TypeCodeidentificador único identifica el formato del artefacto. SAML  2.0 predefine un único artefacto de este tipo, de tipo  0x0004. Este EndpointIndexidentificador es una referencia a un punto final de resolución de artefactos específico gestionado por el emisor del artefacto (que puede ser el IdP o el SP, como se mencionó anteriormente). El identificador RemainingArtifact, que se determina mediante la definición de tipo, es la parte esencial del artefacto.

El formato de un artefacto de tipo  0x0004 se define además de la siguiente manera:

Código de tipo := 0x0004 Artefacto restante := SourceId MessageHandle SourceId := secuencia de 20 bytes MessageHandle := secuencia de 20 bytes

Así, un  artefacto de tipo 0x0004 tiene un tamaño de 44  bytes (sin codificar). Es SourceIduna secuencia arbitraria de bytes, aunque en la práctica, SourceIdes el hash SHA-1 del entityID del emisor. Es MessageHandleuna secuencia aleatoria de bytes que hace referencia a un mensaje SAML que el emisor del artefacto está dispuesto a generar bajo demanda.

Por ejemplo, considere este artefacto de tipo 0x0004 codificado en hexadecimal  :

00040000c878f3fd685c833eb03a3b0e1daa329d47338205e436913660e3e917549a59709fd8c91f2120222f

Si observa con atención, podrá ver los caracteres TypeCode(0x0004) y EndpointIndex(0x0000) al inicio del artefacto. Los siguientes 20  bytes corresponden al 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 la que se muestra en el ejemplo ArtifactResolveRequest anterior.

Perfiles SAML 2.0

En SAML  2.0, al igual que en SAML 1.1, el caso de uso  principal sigue siendo el inicio de sesión único (SSO) del navegador web, pero el alcance de SAML 2.0 es más amplio que el de las versiones anteriores de SAML, como se sugiere en la siguiente lista exhaustiva de perfiles: 

Aunque el número de perfiles admitidos es bastante grande, la especificación Profiles (SAMLProf [ 3 ] ) se simplifica ya que los aspectos de enlace de cada perfil se han factorizado en una especificación Bindings separada (SAMLBind [ 2 ] ).

Perfil SSO del navegador web

SAML  2.0 especifica un perfil de inicio de sesión único (SSO) para navegadores web que involucra un proveedor de identidad (IdP), un proveedor de servicios (SP) y una entidad principal que utiliza un agente de usuario HTTP. El proveedor de servicios dispone de cuatro enlaces para elegir, mientras que el proveedor de identidad dispone de tres, lo que da lugar a doce posibles escenarios de implementación. A continuación, describimos tres de estos escenarios.

Solicitud de redirección del 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 del IdP mediante el enlace HTTP-Redirect. El proveedor de identidad devuelve la respuesta SAML al servicio de consumidor de aserciones del SP mediante el enlace HTTP-POST.

Inicio de sesión único (SSO) en navegador web SAML 2.0 (redirección del proveedor de servicios/respuesta POST del proveedor de identidad)

El flujo de mensajes comienza con una solicitud de un recurso seguro al proveedor de servicios.

1. Solicite el recurso objetivo en el SP.

El usuario 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 comprobació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 del IdP

El proveedor de servicios genera una solicitud SAML (y un RelayState, si corresponde) adecuada y, a continuación, redirige el navegador al servicio SSO del IdP mediante una redirección HTTP 302 estándar.

Redirección 302 Ubicación: https://idp.example.org/SAML2/SSO/Redirect?SAMLRequest=request&RelayState=token

El RelayStatetoken es una referencia opaca a la información de estado mantenida en el proveedor de servicios. El valor del SAMLRequestparámetro es un valor deflactado, codificado en base64 y codificado en URL de un <samlp:AuthnRequest>elemento:

<samlp:AuthnRequest xmlns:samlp= "urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml= "urn:oasis:names:tc:SAML:2.0:assertion" ID= "identifier_1" Version= "2.0" IssueInstant= "2004-12-05T09:21:59Z" AssertionConsumerServiceIndex= "0" > <saml:Issuer> https://sp.example.com/SAML2 </saml:Issuer> <samlp:NameIDPolicy AllowCreate= "true" Format= "urn:oasis:names:tc:SAML:2.0:nameid-format:transient" /> </samlp:AuthnRequest>

La solicitud SAML puede firmarse utilizando la clave de firma del proveedor de servicios. Sin embargo, normalmente esto no es necesario.

3. Solicita el servicio SSO en el IdP.

El agente de usuario realiza una solicitud GET al servicio SSO del proveedor de identidad:

GET /SAML2/SSO/Redirect?SAMLRequest=request&RelayState=token HTTP / 1.1 Host : idp.example.org

donde los valores de los SAMLRequestparámetros RelayStateson los mismos que los proporcionados en la redirección. El servicio SSO del proveedor de identidad procesa el <samlp:AuthnRequest>elemento (mediante decodificación de URL, decodificación base64 e inflación de la solicitud, en ese orden) y realiza una comprobación de seguridad. Si el usuario no tiene un contexto de seguridad válido, el proveedor de identidad lo identifica 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 RelayStateparámetro se ha conservado desde el paso  3. El valor del SAMLResponseparámetro es la codificación base64 del siguiente <samlp:Response>elemento:

<samlp:Response 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" > <saml:Issuer> https://idp.example.org/SAML2 </saml:Issuer> <samlp:Status> <samlp:StatusCode Value= "urn:oasis:names:tc:SAML:2.0:status:Success" /> </samlp:Status> <saml:Assertion xmlns:saml= "urn:oasis:names:tc:SAML:2.0:assertion" ID= "identifier_3" Version= "2.0" IssueInstant= "2004-12-05T09:22:05Z" > <saml:Issuer> https://idp.example.org/SAML2 </saml:Issuer> <!-- una aserción POSTed DEBE estar firmada --> <ds:Signature xmlns:ds= "http://www.w3.org/2000/09/xmldsig#" > ... </ds:Signature> <saml:Subject> <saml:NameID Format= "urn:oasis:names:tc:SAML:2.0:nameid-format:transient" > 3f7b3dcf-1674-4ecd-92c8-1544f346baf8 </saml:NameID> <saml:SubjectConfirmation Method= "urn:oasis:names:tc:SAML:2.0:cm:bearer" > <saml:SubjectConfirmationData InResponseTo= "identifier_1" Recipient= "https://sp.example.com/SAML2/SSO/POST" NotOnOrAfter= "2004-12-05T09:27:05Z" /> </saml:SubjectConfirmation> </saml:Subject> <saml:Conditions NotBefore= "2004-12-05T09:17:05Z" NotOnOrAfter= "2004-12-05T09:27:05Z" > <saml:AudienceRestriction> <saml:Audience> https://sp.example.com/SAML2 </saml:Audience> </saml:AudienceRestriction> </saml:Conditions> <saml:AuthnStatement AuthnInstant= "2004-12-05T09:22:00Z" SessionIndex= "identifier_3" > <saml:AuthnContext> <saml:AuthnContextClassRef> urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport </saml:AuthnContextClassRef> </saml:AuthnContext> </saml:AuthnStatement> </saml:Assertion> </saml:Response>

5. Solicite el Servicio de Atención al Consumidor de Reclamaciones en el SP

El agente de usuario envía una solicitud POST al Servicio de Consumidor de Aserciones del 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 = response & RelayState = token

donde los valores de los parámetros SAMLResponsey RelayStatese toman del formulario XHTML en el paso  4.

6. Redirigir al recurso de destino

El servicio de consumidor de aserciones procesa la respuesta, crea un contexto de seguridad en el proveedor de servicios y redirige al agente de usuario al recurso de destino.

7. Solicitar nuevamente el recurso objetivo en el SP.

El agente de usuario solicita el recurso de destino al proveedor de servicios (de nuevo):

https://sp.example.com/myresource

8. Responda con el recurso solicitado.

Dado que existe un contexto de seguridad, el proveedor de servicios devuelve el recurso al agente de usuario.

Solicitud POST del SP; Respuesta POST del IdP

Se trata de una implementación relativamente sencilla del  perfil SSO del navegador web SAML 2.0 (SAMLProf [ 3 ] ) en la que tanto el proveedor de servicios (SP) como el proveedor de identidad (IdP) utilizan el enlace HTTP POST.

SSO (POST) del navegador web SAML 2.0

El flujo de mensajes comienza con una solicitud de un recurso seguro en el proveedor de servicios (SP).

1. Solicite el recurso objetivo en el SP.

El usuario 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 comprobació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 RelayStatetoken es una referencia opaca a la información de estado que mantiene el proveedor de servicios. El valor del SAMLRequestparámetro es la codificación base64 del siguiente <samlp:AuthnRequest>elemento:

<samlp:AuthnRequest xmlns:samlp= "urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml= "urn:oasis:names:tc:SAML:2.0:assertion" ID= "identifier_1" Version= "2.0" IssueInstant= "2004-12-05T09:21:59Z" AssertionConsumerServiceIndex= "0" > <saml:Issuer> https://sp.example.com/SAML2 </saml:Issuer> <samlp:NameIDPolicy AllowCreate= "true" Format= "urn:oasis:names:tc:SAML:2.0:nameid-format:transient" /> </samlp:AuthnRequest>

Antes de insertar el <samlp:AuthnRequest>elemento en el formulario XHTML, primero se codifica en base64.

3. Solicita el servicio SSO en el IdP.

El agente de usuario envía una solicitud POST al servicio SSO del 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 SAMLRequestparámetros RelayStatese toman del formulario XHTML en el paso  2. El servicio SSO procesa el <samlp:AuthnRequest>elemento (mediante decodificación URL, decodificación base64 e inflación de la solicitud, en ese orden) y realiza una comprobación de seguridad. Si el usuario no tiene un contexto de seguridad válido, el proveedor de identidad lo identifica (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 RelayStateparámetro se ha conservado desde el paso  3. El valor del SAMLResponseparámetro es la codificación base64 del siguiente <samlp:Response>elemento:

<samlp:Response 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" > <saml:Issuer> https://idp.example.org/SAML2 </saml:Issuer> <samlp:Status> <samlp:StatusCode Value= "urn:oasis:names:tc:SAML:2.0:status:Success" /> </samlp:Status> <saml:Assertion xmlns:saml= "urn:oasis:names:tc:SAML:2.0:assertion" ID= "identifier_3" Version= "2.0" IssueInstant= "2004-12-05T09:22:05Z" > <saml:Issuer> https://idp.example.org/SAML2 </saml:Issuer> <!-- una aserción POSTed DEBE estar firmada --> <ds:Signature xmlns:ds= "http://www.w3.org/2000/09/xmldsig#" > ... </ds:Signature> <saml:Subject> <saml:NameID Format= "urn:oasis:names:tc:SAML:2.0:nameid-format:transient" > 3f7b3dcf-1674-4ecd-92c8-1544f346baf8 </saml:NameID> <saml:SubjectConfirmation Method= "urn:oasis:names:tc:SAML:2.0:cm:bearer" > <saml:SubjectConfirmationData InResponseTo= "identifier_1" Recipient= "https://sp.example.com/SAML2/SSO/POST" NotOnOrAfter= "2004-12-05T09:27:05Z" /> </saml:SubjectConfirmation> </saml:Subject> <saml:Conditions NotBefore= "2004-12-05T09:17:05Z" NotOnOrAfter= "2004-12-05T09:27:05Z" > <saml:AudienceRestriction> <saml:Audience> https://sp.example.com/SAML2 </saml:Audience> </saml:AudienceRestriction> </saml:Conditions> <saml:AuthnStatement AuthnInstant= "2004-12-05T09:22:00Z" SessionIndex= "identifier_3" > <saml:AuthnContext> <saml:AuthnContextClassRef> urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport </saml:AuthnContextClassRef> </saml:AuthnContext> </saml:AuthnStatement> </saml:Assertion> </saml:Response>

5. Solicite el Servicio de Atención al Consumidor de Reclamaciones en el SP

El agente de usuario envía una solicitud POST al servicio de consumidor de aserciones del 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 = response & RelayState = token

donde los valores de los parámetros SAMLResponsey RelayStatese toman del formulario XHTML en el paso  4.

6. Redirigir al recurso de destino

El servicio de consumidor de aserciones procesa la respuesta, crea un contexto de seguridad en el proveedor de servicios y redirige al agente de usuario al recurso de destino.

7. Solicitar nuevamente el recurso objetivo en el SP.

El agente de usuario solicita el recurso de destino al proveedor de servicios (de nuevo):

https://sp.example.com/myresource

8. Responda con el recurso solicitado.

Dado que existe un contexto de seguridad, el proveedor de servicios devuelve el recurso al agente de usuario.

Artefacto de redirección del SP; artefacto de redirección del IdP

Se trata de una implementación compleja del  perfil SSO para navegador web SAML 2.0 (SAMLProf [ 3 ] ), donde tanto el proveedor de servicios (SP) como el proveedor de identidad (IdP) utilizan el enlace de artefactos HTTP. Ambos artefactos se entregan a sus respectivos puntos finales mediante HTTP GET.

Inicio de sesión único (SSO) para navegadores web SAML 2.0 (Artefacto)

El flujo de mensajes comienza con una solicitud de un recurso seguro en el SP:

1. Solicite el recurso objetivo en el SP.

El usuario 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 comprobació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) del proveedor de identidad. Se añaden un RelayStateparámetro y otro parámetro a la URL de redirección.SAMLart

3. Solicita el servicio SSO en el IdP.

El agente de usuario solicita el servicio SSO al proveedor de identidad:

https://idp.example.org/SAML2/SSO/Artifact ?SAMLart= artefacto_1 &RelayState= token

donde tokenes una referencia opaca a la información de estado mantenida en el proveedor de servicios y artifact_1es un artefacto SAML, ambos emitidos en el paso  2.

4. Solicite el Servicio de Resolución de Artefactos en el SP.

El servicio SSO desreferencia el artefacto enviando un <samlp:ArtifactResolve>elemento vinculado a un mensaje SAML SOAP al servicio de resolución de artefactos del proveedor de servicios:

<samlp:ArtifactResolve xmlns:samlp= "urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml= "urn:oasis:names:tc:SAML:2.0:assertion" ID= "identifier_1" Version= "2.0" IssueInstant= "2004-12-05T09:21:58Z" Destination= "https://sp.example.com/SAML2/ArtifactResolution" > <saml:Issuer> https://idp.example.org/SAML2 </saml:Issuer> <!-- un mensaje de ArtifactResolve DEBE estar firmado --> <ds:Signature xmlns:ds= "http://www.w3.org/2000/09/xmldsig#" > ... </ds:Signature> <samlp:Artifact> ''artifact_1'' </samlp:Artifact> </samlp:ArtifactResolve>

donde el valor del <samlp:Artifact>elemento es el artefacto SAML transmitido en el paso 3.

5. Responda con una solicitud de autenticación SAML.

El servicio de resolución de artefactos del proveedor de servicios devuelve un <samlp:ArtifactResponse>elemento (que contiene un <samlp:AuthnRequest>elemento) vinculado a un mensaje SAML SOAP al servicio SSO del proveedor de identidad:

<samlp:ArtifactResponse 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" > <!-- un mensaje ArtifactResponse DEBE estar firmado --> <ds:Signature xmlns:ds= "http://www.w3.org/2000/09/xmldsig#" > ... </ds:Signature> <samlp:Status> <samlp:StatusCode Value= "urn:oasis:names:tc:SAML:2.0:status:Success" /> </samlp:Status> <samlp:AuthnRequest xmlns:samlp= "urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml= "urn:oasis:names:tc:SAML:2.0:assertion" ID= "identifier_3" 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" > <saml:Issuer> https://sp.example.com/SAML2 </saml:Issuer> <samlp:NameIDPolicy AllowCreate= "false" Format= "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress" /> </samlp:AuthnRequest> </samlp:ArtifactResponse>

El servicio SSO procesa el <samlp:AuthnRequest>elemento y realiza una comprobación de seguridad. Si el usuario no tiene un contexto de seguridad válido, el proveedor de identidad lo identifica (detalles omitidos).

6. Redirigir al Servicio de Atención al Cliente de Reclamaciones

El servicio SSO del proveedor de identidad redirige al agente de usuario al servicio de consumidor de aserciones del proveedor de servicios. El RelayStateparámetro anterior y un nuevo SAMLartparámetro se añaden a la URL de redirección.

7. Solicite el Servicio de Atención al Consumidor de Reclamaciones en el SP

El agente de usuario solicita el servicio de consumidor de aserciones al proveedor de servicios:

https://sp.example.com/SAML2/SSO/Artifact ?SAMLart= artefacto_2 &RelayState= token

¿Dónde tokenestá el valor del token del paso  3 y artifact_2cuál 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 aserciones desreferencia el artefacto enviando un <samlp:ArtifactResolve>elemento vinculado a un mensaje SAML SOAP al servicio de resolución de artefactos en el proveedor de identidad:

<samlp:ArtifactResolve 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" > <saml:Issuer> https://sp.example.com/SAML2 </saml:Issuer> <!-- un mensaje de ArtifactResolve DEBE estar firmado --> <ds:Signature xmlns:ds= "http://www.w3.org/2000/09/xmldsig#" > ... </ds:Signature> <samlp:Artifact> ''artifact_2'' </samlp:Artifact> </samlp:ArtifactResolve>

donde el valor del <samlp:Artifact>elemento es el artefacto SAML transmitido en el paso  7.

9. Responda con una aserción SAML.

El servicio de resolución de artefactos en el proveedor de identidad devuelve un <samlp:ArtifactResponse>elemento (que contiene un <samlp:Response>elemento) vinculado a un mensaje SAML SOAP al servicio consumidor de aserciones en el proveedor de servicios:

<samlp:ArtifactResponse 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" > <!-- un mensaje ArtifactResponse DEBE estar firmado --> <ds:Signature xmlns:ds= "http://www.w3.org/2000/09/xmldsig#" > ... </ds:Signature> <samlp:Status> <samlp:StatusCode Value= "urn:oasis:names:tc:SAML:2.0:status:Success" /> </samlp:Status> <samlp:Response xmlns:samlp= "urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml= "urn:oasis:names:tc:SAML:2.0:assertion" ID= "identifier_6" InResponseTo= "identifier_3" Version= "2.0" IssueInstant= "2004-12-05T09:22:05Z" Destination= "https://sp.example.com/SAML2/SSO/Artifact" > <saml:Issuer> https://idp.example.org/SAML2 </saml:Issuer> <ds:Signature xmlns:ds= "http://www.w3.org/2000/09/xmldsig#" > ... </ds:Signature> <samlp:Status> <samlp:StatusCode Value= "urn:oasis:names:tc:SAML:2.0:status:Success" /> </samlp:Status> <saml:Assertion xmlns:saml= "urn:oasis:names:tc:SAML:2.0:assertion" ID= "identifier_7" Version= "2.0" IssueInstant= "2004-12-05T09:22:05Z" > <saml:Issuer> https://idp.example.org/SAML2 </saml:Issuer> <!-- Se requiere un elemento Subject --> <saml:Subject> <saml:NameID Format= "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress" > user@mail.example.org </saml:NameID> <saml:SubjectConfirmation Method= "urn:oasis:names:tc:SAML:2.0:cm:bearer" > <saml:SubjectConfirmationData InResponseTo= "identifier_3" Recipient= "https://sp.example.com/SAML2/SSO/Artifact" NotOnOrAfter= "2004-12-05T09:27:05Z" /> </saml:SubjectConfirmation> </saml:Asunto> <saml:Conditions NotBefore= "2004-12-05T09:17:05Z" NotOnOrAfter= "2004-12-05T09:27:05Z" > <saml:AudienceRestriction> <saml:Audience> https://sp.example.com/SAML2 </saml:Audience></saml:AudienceRestriction> </saml:Conditions> <saml:AuthnStatement AuthnInstant= "2004-12-05T09:22:00Z" SessionIndex= "identifier_7" > <saml:AuthnContext> <saml:AuthnContextClassRef> urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport </saml:AuthnContextClassRef> </saml:AuthnContext> </saml:AuthnStatement> </saml:Assertion> </samlp:Response> </samlp:ArtifactResponse>

10. Redirigir al recurso de destino

El servicio de consumidor de aserciones procesa la respuesta, crea un contexto de seguridad en el proveedor de servicios y redirige al agente de usuario al recurso de destino.

11. Solicitar nuevamente el recurso objetivo en el SP.

El agente de usuario solicita el recurso de destino al proveedor de servicios (de nuevo):

https://sp.example.com/myresource

12. Responda 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 proveedor de identidad SAML  2.0 introduce los siguientes conceptos:

  • Dominio común
  • Cookie de dominio común
  • Servicio de redacción de cookies de dominio común
  • Servicio de lectura de cookies de dominio común

Como ejemplo hipotético de 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 con ámbito en el dominio común. Para cada usuario del navegador, esta cookie almacena un historial de los IdP visitados recientemente. El nombre y el valor de la cookie se especifican en el perfil de descubrimiento de IdP (SAMLProf [ 3 ] ).

Tras una autenticación exitosa, el proveedor de identidad (IdP) solicita al servicio de escritura de cookies de dominio común (CDS) . Este servicio añade el identificador único del IdP a la cookie de dominio común. Cuando el proveedor de servicios (SP) recibe una solicitud no autenticada para un recurso protegido, solicita al servicio de lectura de cookies de dominio común ( CDS) para descubrir el IdP utilizado más recientemente por el usuario del navegador.

Perfil de consulta/solicitud de aserción

El perfil de consulta/solicitud de aserción es un perfil general que admite numerosos tipos de consultas que utilizan los siguientes  elementos de SAML 2.0:

  • el <samlp:AssertionIDRequest>elemento, que se utiliza para solicitar una aserción dado su identificador único ( ID)
  • el <samlp:SubjectQuery>elemento, que es un punto de extensión abstracto que permite definir nuevas consultas SAML basadas en el sujeto
  • El <samlp:AuthnQuery>elemento, que se utiliza para solicitar a una Autoridad de Autenticación las aserciones de autenticación existentes sobre un sujeto determinado.
  • El <samlp:AttributeQuery>elemento, que se utiliza para solicitar atributos sobre un tema determinado a una Autoridad de Atributos.
  • el <samlp:AuthzDecisionQuery>elemento que se utiliza para solicitar una decisión de autorización a un tercero de confianza

El enlace SAML SOAP se utiliza a menudo junto con consultas.

consulta de atributos SAML

La consulta de atributos es quizás el tipo de consulta SAML más importante. A menudo, un solicitante, actuando en nombre del principal, consulta a un proveedor de identidad para obtener atributos. A continuación, se muestra un ejemplo de una consulta realizada directamente por un principal:

<samlp:AttributeQuery 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" > <saml:Issuer Format= "urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName" > CN=trscavo@example.com,OU=User,O=NCSA-TEST,C=US </saml:Issuer> <saml:Subject> <saml:NameID Format= "urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName" > CN=trscavo@example.com,OU=User,O=NCSA-TEST,C=US </saml:NameID> </saml:Subject> <saml:Attribute NameFormat= "urn:oasis:names:tc:SAML:2.0:attrname-format:uri" Name= "urn:oid:2.5.4.42" FriendlyName= "givenName" > </saml:Attribute> <saml:Attribute 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" > </saml:Attribute> </samlp:AttributeQuery>

Tenga en cuenta que en este caso Issueres el . A veces se le llama autoconsulta de atributo . Un proveedor de identidad podría devolver la siguiente aserción, envuelta en un elemento (no se muestra):Subject<samlp:Response>

<saml:Assertion 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" > <saml:Issuer> https://idp.example.org/SAML2 </saml:Issuer> <ds:Signature> ... </ds:Signature> <saml:Subject> <saml:NameID Format= "urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName" > CN=trscavo@example.com,OU=User,O=NCSA-TEST,C=US </saml:NameID> <saml:SubjectConfirmation Method= "urn:oasis:names:tc:SAML:2.0:cm:holder-of-key" > <saml:SubjectConfirmationData> <ds:KeyInfo> <ds:X509Data> <!-- Certificado X.509 del principal --> <ds:X509Certificate> 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== </ds:X509Certificate> </ds:X509Data> </ds:KeyInfo> </saml:SubjectConfirmationData> </saml:SubjectConfirmation> </saml:Subject> <!-- la duración de la aserción está restringida por el certificado X.509 del principal --> <saml:Conditions NotBefore= "2006-07-17T20:31:41Z" NotOnOrAfter= "2006-07-18T20:21:41Z" > </saml:Conditions> <saml:AuthnStatement AuthnInstant= "2006-07-17T20:31:41Z" > <saml:AuthnContext> <saml:AuthnContextClassRef> urn:oasis:names:tc:SAML:2.0:ac:classes:TLSClient </saml:AuthnContextClassRef> </saml:AuthnContext > </saml :AuthnStatement> <saml:AttributeStatement> <saml:Attribute xmlns:x500= "urn:oasis:names:tc:SAML:2.0:profiles:attribute:X500" x500:Encoding= "LDAP" NameFormat= "urn:oasis:names:tc:SAML:2.0:attrname-format:uri" Name= "urn:oid:2.5.4.42" FriendlyName= "givenName" > <saml:AttributeValue xsi:type= "xs:string" > Tom </saml:AttributeValue> </saml:Attribute> <saml:Attribute xmlns:x500= "urn:oasis:names:tc:SAML:2.0:profiles:attribute: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= "mail" > <saml:AttributeValue xsi:type= "xs:string" > trscavo@example.org </saml:AttributeValue> </saml:Attribute> </saml:AttributeStatement> </saml:Assertion>

A diferencia de la aserción Bearer mostrada anteriormente, esta aserción tiene una vigencia mayor, correspondiente a la del certificado X.509 que el usuario utilizó para autenticarse ante el proveedor de identidad. Además, dado que la aserción está firmada, el usuario puede enviarla a una parte confiable y, siempre que pueda demostrar que posee la clave privada correspondiente (de ahí el nombre de "titular de la clave"), la parte confiable puede tener la seguridad de que la aserció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 <samlp:AuthnRequest>elemento a un proveedor de identidad a través del navegador. ¿Cómo sabe el proveedor de servicios que el proveedor de identidad es auténtico y no un proveedor malicioso que intenta robar la contraseña del usuario mediante phishing ? El proveedor de servicios consulta su lista de proveedores de identidad de confianza en los 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 <samlp:AuthnRequest>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 malintencionado que intenta obtener información personal del usuario? El proveedor de identidad consulta su lista de proveedores de servicios de confianza en los 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 este) pueda descifrarla? El proveedor de identidad utiliza el certificado de cifrado del proveedor de servicios, incluido en los metadatos, para cifrar la aserción.
  • Siguiendo con el escenario anterior, ¿cómo sabe el proveedor de identidad 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 proviene de un proveedor de identidades de confianza? El proveedor de servicios verifica la firma de la aserción utilizando la clave pública del proveedor de identidades que se encuentra en los metadatos .
  • ¿Cómo sabe el proveedor de servicios dónde resolver un artefacto recibido de un proveedor de identidades de confianza? El proveedor de servicios busca la ubicación del punto final preestablecido del servicio de resolución de artefactos del proveedor de identidades a partir de los metadatos .

Los metadatos garantizan una transacción segura entre un proveedor de identidad y un proveedor de servicios. Antes de la llegada de los metadatos, la información de confianza se codificaba en la implementación de forma propietaria. Ahora, el intercambio de información de confianza se facilita mediante metadatos estándar. SAML  2.0 proporciona un formato de metadatos interoperable y bien definido que las entidades pueden utilizar para iniciar el proceso de confianza.

Metadatos del proveedor de identidad

Un proveedor de identidad publica datos sobre sí mismo en un <md:EntityDescriptor>elemento:

<md:EntityDescriptor entityID= "https://idp.example.org/SAML2" 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:assertion" xmlns:ds= "http://www.w3.org/2000/09/xmldsig#" > <!-- insertar elemento ds:Signature (omitido) --> <!-- insertar elemento md:IDPSSODescriptor (abajo) --> <md:Organization> <md:OrganizationName xml:lang= "en" > Alguna organización sin fines de lucro de Nueva York </md:OrganizationName> <md:OrganizationDisplayName xml:lang= "en" > Alguna organización sin fines de lucro </md:OrganizationDisplayName> <md:OrganizationURL xml:lang= "en" > https://www.example.org/ </md:OrganizationURL> </md:Organization> <md:ContactPerson contactType= "technical" > <md:SurName> Soporte técnico SAML </md:SurName> <md:EmailAddress> mailto:saml-support@example.org </md:EmailAddress> </md:ContactPerson> </md:EntityDescriptor>

Tenga en cuenta los siguientes detalles sobre este descriptor de entidad:

  • El entityIDatributo es el identificador único de la entidad.
  • Este validUntilatributo indica la fecha de caducidad de los metadatos.
  • El <ds:Signature>elemento (que se ha omitido por simplicidad) contiene una firma digital que garantiza la autenticidad e integridad de los metadatos.
  • La organización identificada en el <md:Organization>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 <md:ContactPerson>elemento identifica a un contacto técnico responsable de la entidad. Es posible incluir varios contactos y tipos de contacto. Consulte la sección  2.3.2.2 de SAMLMeta. [ 4 ]

Por definición, un proveedor de identidades administra un servicio SSO que admite el perfil SSO de navegador web SAML especificado en SAMLProf. [ 3 ] Véase, por ejemplo, el proveedor de identidades descrito en el <md:IDPSSODescriptor>elemento que se muestra en la siguiente sección.

metadatos del servicio SSO

El servicio SSO del proveedor de identidad se describe en un <md:IDPSSODescriptor>elemento:

<md:IDPSSODescriptor protocolSupportEnumeration= "urn:oasis:names:tc:SAML:2.0:protocol" > <md:KeyDescriptor use= "signing" > <ds:KeyInfo> ... </ds:KeyInfo> </md:KeyDescriptor> <md:ArtifactResolutionService isDefault= "true" index= "0" Binding= "urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location= "https://idp.example.org/SAML2/ArtifactResolution" /> <md:NameIDFormat> urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress </md:NameIDFormat> <md:NameIDFormat> urn:oasis:names:tc:SAML:2.0:nameid-format:transient </md:NameIDFormat> <md:SingleSignOnService Binding= "urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location= "https://idp.example.org/SAML2/SSO/Redirect" /> <md:SingleSignOnService Binding= "urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location= "https://idp.example.org/SAML2/SSO/POST" /> <md:SingleSignOnService Binding= "urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" Location= "https://idp.example.org/SAML2/Artifact" /> <saml:Attribute 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" > <saml:AttributeValue> member </saml:AttributeValue> <saml:AttributeValue> student </saml:AttributeValue> <saml:AttributeValue> faculty </saml:AttributeValue> <saml:AttributeValue> employee </saml:AttributeValue> <saml:AttributeValue> staff </saml:AttributeValue> </saml:Attribute> </md:IDPSSODescriptor>

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 de retorno privada. La clave pública correspondiente se incluye en el <md:KeyDescriptor use="signing">elemento de metadatos del IdP. El material de la clave se ha omitido del descriptor de clave por brevedad.
  • El Bindingatributo del elemento indica que se debe utilizar <md:ArtifactResolutionService>el enlace SAML SOAP (SAMLBind [ 2 ] ) para la resolución de artefactos.
  • El Locationatributo del <md:ArtifactResolutionService>elemento se utiliza en el paso  8 del perfil " doble artefacto ".
  • El valor del indexatributo del <md:ArtifactResolutionService>elemento se utiliza como EndpointIndexen la construcción de un  artefacto SAML de tipo 0x0004.
  • Los <md:NameIDFormat>elementos indican qué formatos de identificador de nombre SAML (SAMLCore [ 1 ] ) admite el servicio SSO.
  • Los Bindingatributos de los <md:SingleSignOnService>elementos son URI estándar especificados en la  especificación de enlace SAML 2.0 (SAMLBind [ 2 ] ).
  • El Locationatributo del <md:SingleSignOnService>elemento que admite el enlace HTTP POST se utiliza en el paso  2 del perfil " double POST ".
  • El Locationatributo del <md:SingleSignOnService>elemento que admite la vinculación de artefactos HTTP se utiliza en el paso  2 del perfil " doble artefacto ".
  • El <saml:Attribute>elemento describe un atributo que el proveedor de identidad está dispuesto a afirmar (sujeto a la política). Los <saml:AttributeValue>elementos enumeran los posibles valores que puede tomar el atributo.

Como se indicó al principio de esta sección, los valores de los Locationatributos son utilizados por un proveedor de servicios para enrutar los mensajes SAML, lo que minimiza la posibilidad de que un proveedor de identidad malintencionado orqueste 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 <md:EntityDescriptor>elemento:

<md:EntityDescriptor entityID= "https://sp.example.com/SAML2" 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:assertion" xmlns:ds= "http://www.w3.org/2000/09/xmldsig#" > <!-- insertar elemento ds:Signature (omitido) --> <!-- insertar elemento md:SPSSODescriptor (ver abajo) --> <md:Organization> <md :OrganizationName xml:lang= "en" > Some Commercial Vendor of California </md:OrganizationName> <md:OrganizationDisplayName xml:lang= "en" > Algún proveedor comercial </md:OrganizationDisplayName> <md:OrganizationURL xml:lang= "en" > https://www.example.com/ </md:OrganizationURL> </md:Organization> <md:ContactPerson contactType= "technical" > <md:SurName> Soporte técnico SAML </md:SurName> <md:EmailAddress> mailto:saml-support@example.com </md:EmailAddress> </md:ContactPerson> </md:EntityDescriptor>

Tenga en cuenta los siguientes detalles sobre este descriptor de entidad:

  • El entityIDatributo es el identificador único de la entidad.
  • Este validUntilatributo indica la fecha de caducidad de los metadatos.
  • El <ds:Signature>elemento (que se ha omitido por simplicidad) contiene una firma digital que garantiza la autenticidad e integridad de los metadatos.
  • La organización identificada en el <md:Organization>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 <md:ContactPerson>elemento identifica a un contacto técnico responsable de la entidad. Es posible incluir varios contactos y tipos de contacto. Consulte la sección  2.3.2.2 de SAMLMeta. [ 4 ]

Por definición, un proveedor de servicios administra un servicio de consumidor de aserciones que admite el perfil SAML Web Browser SSO especificado en SAMLProf. [ 3 ] Véase, por ejemplo, el proveedor de servicios descrito en el <md:SPSSODescriptor>elemento que se muestra en la siguiente sección.

metadatos del servicio al consumidor de la afirmación

El servicio de consumidor de aserciones está contenido en un <md:SPSSODescriptor>elemento:

<md:SPSSODescriptor protocolSupportEnumeration= "urn:oasis:names:tc:SAML:2.0:protocol" > <md:KeyDescriptor use= "signing" > <ds:KeyInfo> ... </ds:KeyInfo> </md:KeyDescriptor> <md:KeyDescriptor use= "encryption" > <ds:KeyInfo> ... </ds:KeyInfo> </md:KeyDescriptor> <md:ArtifactResolutionService isDefault= "true" index= "0" Binding= "urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location= "https://sp.example.com/SAML2/ArtifactResolution" /> <md:NameIDFormat> urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress </md:NameIDFormat> <md:NameIDFormat> urn:oasis:names:tc:SAML:2.0:nameid-format:transient </md:NameIDFormat> <md:AssertionConsumerService isDefault= "true" index= "0" Binding= "urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location= "https://sp.example.com/SAML2/SSO/POST" /> <md:AssertionConsumerService index= "1" Binding= "urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" Location= "https://sp.example.com/SAML2/Artifact" /> <md:AttributeConsumingService isDefault= "true" index= "1" > <md:ServiceName xml:lang= "en" > Portal del proveedor de servicios </md:ServiceName> <md:RequestedAttribute 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" > </md:RequestedAttribute> </md:AttributeConsumingService> </md:SPSSODescriptor>

Tenga en cuenta los siguientes detalles sobre el <md:SPSSODescriptor>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 de retorno privada. La clave pública correspondiente se incluye en el <md:KeyDescriptor use="signing">elemento de metadatos del proveedor de servicios. El material de la clave se ha omitido del descriptor de clave por brevedad.
  • Asimismo, el software del proveedor de servicios está configurado con una clave de descifrado SAML privada. En los metadatos del proveedor de servicios se incluye una clave de cifrado SAML pública <md:KeyDescriptor use="encryption">. El contenido de la clave se ha omitido del descriptor de clave por brevedad.
  • El indexatributo de un <md:AssertionConsumerService>elemento se utiliza como valor del AssertionConsumerServiceIndexatributo en un <samlp:AuthnRequest>elemento.
  • Los Bindingatributos de los <md:AssertionConsumerService>elementos son URI estándar especificados en la  especificación de enlace SAML 2.0 (SAMLBind [ 2 ] ).
  • El Locationatributo del <md:AssertionConsumerService>elemento que admite el enlace HTTP POST ( index="0") se utiliza en el paso  4 del perfil " double POST ".
  • El Locationatributo del <md:AssertionConsumerService>elemento que admite el enlace HTTP Artifact ( index="1") se utiliza en el paso  6 del perfil " double artifact ".
  • <md:AttributeConsumingService>El proveedor de identidad utiliza este elemento para formular otro <saml:AttributeStatement>elemento que se envía al proveedor de servicios junto con el inicio de sesión único (SSO) del navegador web.
  • El indexatributo del <md:AttributeConsumingService>elemento se utiliza como valor del AttributeConsumingServiceIndexatributo en un <samlp:AuthnRequest>elemento.

Como se indicó al principio de esta sección, los valores de los Locationatributos son utilizados por un proveedor de identidad para enrutar los mensajes SAML, lo que minimiza la posibilidad de que un proveedor de servicios malintencionado orqueste un ataque de intermediario .

Agregados de metadatos

En los ejemplos anteriores, <md:EntityDescriptor>se muestra que cada elemento está firmado digitalmente. Sin embargo, en la práctica, varios <md:EntityDescriptor>elementos se agrupan bajo un <md:EntitiesDescriptor>elemento con una única firma digital para todo el conjunto:

<md:EntitiesDescriptor 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:assertion" xmlns:ds= "http://www.w3.org/2000/09/xmldsig#" > <!-- insertar elemento ds:Signature (omitido) --> <md:EntityDescriptor entityID= "https://idp.example.org/SAML2" > ... </md:EntityDescriptor> <md:EntityDescriptor entityID= "https://sp.example.com/SAML2" > ... </md:EntityDescriptor> </md:EntitiesDescriptor>

Tenga en cuenta los siguientes detalles sobre el <md:EntitiesDescriptor>elemento mencionado anteriormente:

  • La firma digital (que se ha omitido por brevedad) cubre la totalidad del conjunto.
  • El validUntilatributo XML se ha elevado al nivel del elemento padre, lo que implica que la fecha de caducidad se aplica a cada elemento hijo.
  • Las declaraciones de espacio de nombres XML se han elevado al elemento padre para evitar declaraciones de espacio de nombres redundantes.

Por lo general, los agregados de metadatos son publicados por terceros de confianza, denominados federaciones, que garantizan la integridad de todos los metadatos que contienen. Cabe destacar que los agregados de metadatos pueden ser muy grandes, compuestos por cientos o incluso miles de entidades.

Véase también

Referencias

Referencias principales:

  1. 1 2 3 S. Cantor et al. Aserciones y protocolos para el lenguaje de marcado de aserciones de seguridad (SAML) V2.0 de OASIS  – Errata Composite. Borrador de trabajo 07, 8 de septiembre de 2015. ID del 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
  2. 1 2 3 4 5 6 7 S. Cantor et al. Enlaces para el lenguaje de marcado de aserciones de seguridad (SAML)  V2.0 de OASIS – Errata Composite. Borrador de trabajo 06, 8 de septiembre de 2015. ID del 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
  3. 1 2 3 4 5 6 7 J. Hughes et al. Perfiles para el lenguaje de marcado de aserciones de seguridad (SAML)  V2.0 de OASIS – Errata Composite. Borrador de trabajo 07, 8 de septiembre de 2015. ID del 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
  4. 1 2 3 4 5 S. Cantor et al. Metadatos para el lenguaje de marcado de aserciones de seguridad (SAML) V2.0 de OASIS  – Errata Composite. Borrador de trabajo 05, 8 de septiembre de 2015. ID del 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 et al. Requisitos de conformidad para el lenguaje de marcado de aserciones de seguridad (SAML)  V2.0 de OASIS – Errata compuesta. Borrador de trabajo 04, 1 de diciembre de 2009. ID del 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 del lenguaje de marcado de aserciones de seguridad (SAML)  V2.0. Borrador del Comité OASIS, marzo de 2008. ID del 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., Resumen ejecutivo de SAML  V2.0. Borrador del Comité OASIS, abril de 2005. ID del documento  sstc-saml-tech-overview-2.0-cd-01-2col http://www.oasis-open.org/committees/download.php/13525/sstc-saml-exec-overview-2.0-cd-01-2col.pdf
  • J.  Kemp et al. Contexto de autenticación para el lenguaje de marcado de aserciones de seguridad (SAML)  V2.0 de OASIS. Estándar OASIS, marzo de 2005. ID del 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 et al. Consideraciones de seguridad y privacidad para el lenguaje de marcado de aserciones de seguridad (SAML)  V2.0 de OASIS. Estándar OASIS, marzo de 2005. ID del 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 et al. Glosario del lenguaje de marcado de aserciones de seguridad (SAML)  V2.0 de OASIS. Estándar OASIS, marzo de 2005. ID del 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 et al. Requisitos de conformidad para el lenguaje de marcado de aserciones de seguridad (SAML)  V2.0 de OASIS. Estándar OASIS, marzo de 2005. ID del documento:  saml-conformance-2.0-os http://docs.oasis-open.org/security/saml/v2.0/saml-conformance-2.0-os.pdf
  • S.  Cantor et al. Aserciones y protocolos para el lenguaje de marcado de aserciones de seguridad (SAML)  V2.0 de OASIS. Estándar OASIS, marzo de 2005. ID del documento:  saml-core-2.0-os http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf
  • S.  Cantor et al. Enlaces para el lenguaje de marcado de aserciones de seguridad (SAML)  V2.0 de OASIS. Estándar OASIS, marzo de 2005. ID del documento:  saml-bindings-2.0-os http://docs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf
  • S.  Cantor et al. Perfiles para el lenguaje de marcado de aserciones de seguridad (SAML)  V2.0 de OASIS. Estándar OASIS, marzo de 2005. ID del documento:  saml-profiles-2.0-os http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf
  • S.  Cantor et al. Metadatos para el lenguaje de marcado de aserciones de seguridad (SAML)  V2.0 de OASIS. Estándar OASIS, marzo de 2005. ID del documento:  saml-metadata-2.0-os http://docs.oasis-open.org/security/saml/v2.0/saml-metadata-2.0-os.pdf