SAML 1.1

El lenguaje de marcado de aserciones de seguridad (SAML) es un estándar XML para el intercambio de datos de autenticación y autorización entre dominios de seguridad. SAML es un producto del Comité Técnico de Servicios de Seguridad de OASIS (organización) .

SAML  1.1 fue ratificado como estándar OASIS en septiembre de 2003. Los aspectos críticos de SAML 1.1 se tratan en detalle en los documentos oficiales SAMLCore ^{[ 1 ]} y SAMLBind ^{[ 2 ]} . Si no está familiarizado con SAML, le recomendamos leer primero el tema introductorio de SAML y, a continuación, el documento SAMLOverview ^{[ 3 ]} de OASIS.

Antes de SAML  1.1, SAML  1.0 fue adoptado como estándar OASIS en noviembre de 2002. Desde entonces, SAML ha experimentado una revisión menor (V1.1) y una revisión mayor (V2.0), siendo este último un protocolo relativamente sencillo.  Sin embargo, SAML 1.0 tiene un interés que va más allá del ámbito histórico, ya que la Iniciativa Federal de Autenticación Electrónica de EE. UU. lo ha adoptado  como su tecnología principal.

Las versiones  1.0 y 1.1 de SAML son similares. Consulte SAMLDiff ^{[ 4 ]} para conocer las diferencias específicas entre ambos estándares. Este artículo se centra en SAML  1.1, ya que es un estándar importante del que dependen muchos otros estándares e implementaciones.

Advertencia: Los implementadores y desplegadores deben tener en cuenta que todos los ejemplos de código de este artículo no son normativos y tienen únicamente fines ilustrativos. Consulte las especificaciones SAML de OASIS para conocer los requisitos normativos.

Las aserciones SAML contienen declaraciones que los proveedores de servicios utilizan para tomar decisiones de control de acceso. Por ejemplo, las declaraciones de autenticación confirman al proveedor de servicios que el usuario se autenticó con el proveedor de identidad en un momento determinado utilizando un método de autenticación específico. En una declaración de autenticación también se puede revelar otra información sobre el usuario. En la siguiente declaración de autenticación, por ejemplo, se confirma al proveedor de servicios la dirección de correo electrónico del usuario:

<saml:Assertion xmlns:saml= "urn:oasis:names:tc:SAML:1.0:assertion" MajorVersion= "1" MinorVersion= "1" AssertionID= "buGxcG4gILg5NlocyLccDz6iXrUa" Issuer= "https://idp.example.org/saml" IssueInstant= "2002-06-19T17:05:37.795Z" > <saml:Conditions NotBefore= "2002-06-19T17:00:37.795Z" NotOnOrAfter= "2002-06-19T17:10:37.795Z" /> <saml:AuthenticationStatement AuthenticationMethod= "urn:oasis:names:tc:SAML:1.0:am:password" AuthenticationInstant= "2002-06-19T17:05:17.706Z" > <saml:Subject> <saml:NameIdentifier Format= "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress" > user@idp.example.org </saml:NameIdentifier> <saml:SubjectConfirmation> <saml:ConfirmationMethod> urn:oasis:names:tc:SAML:1.0:cm:bearer </saml:ConfirmationMethod> </saml:SubjectConfirmation> </saml:Subject> </saml:AuthenticationStatement> </saml:Assertion>

Una dirección de correo electrónico (como en el ejemplo anterior) será suficiente en muchas situaciones. Sin embargo, en algunos casos, se necesita información adicional antes de que un proveedor de servicios pueda tomar una decisión sobre el control de acceso. Por ejemplo, supongamos que los estudiantes tienen acceso a los datos de becas. Una declaración de atributo puede indicar si el usuario tiene o no la afiliación de "estudiante", que el proveedor de servicios utiliza para permitir o denegar el acceso (respectivamente) a la solicitud de becas.

<saml:Assertion xmlns:saml= "urn:oasis:names:tc:SAML:1.0:assertion" MajorVersion= "1" MinorVersion= "1" Issuer= "https://idp.example.org/saml" ... > <saml:Conditions NotBefore= "..." NotAfter= "..." /> <saml:AuthenticationStatement AuthenticationMethod= "..." AuthenticationInstant= "..." > <saml:Subject> ... </saml:Subject> </saml:AuthenticationStatement> <saml:AttributeStatement> <saml:Subject> ... </saml:Subject> <saml:Attribute AttributeName= "urn:mace:dir:attribute-def:eduPersonAffiliation" AttributeNamespace= "urn:mace:shibboleth:1.0:attributeNamespace:uri" > <saml:AttributeValue> miembro </saml:AttributeValue> <saml:AttributeValue> estudiante </saml:AttributeValue> </saml:Attribute> </saml:AttributeStatement> </saml:Assertion>

Los atributos suelen obtenerse de un directorio LDAP , por lo que es fundamental contar con representaciones coherentes de los atributos en todos los dominios de seguridad.

En el ejemplo anterior que muestra cómo un estudiante podría acceder a una solicitud de beca, el proveedor de servicios funciona como punto de aplicación y de decisión de políticas . En algunos casos, puede ser preferible asociar el punto de decisión de políticas con el proveedor de identidad. En este caso, el proveedor de servicios pasa una URI al proveedor de identidad, quien emite una declaración de autorización que determina si se debe permitir o no al usuario acceder al recurso protegido en la URI proporcionada.

<saml:Assertion xmlns:saml= "urn:oasis:names:tc:SAML:1.0:assertion" MajorVersion= "1" MinorVersion= "1" Issuer= "https://idp.example.org/saml" ... > <saml:Conditions ... /> <saml:AuthorizationDecisionStatement Decision= "Permit" Resource= "https://sp.example.com/confidential_report.html" > <saml:Subject> ... </saml:Subject> <saml:Action> leer </saml:Action> </saml:AuthorizationDecisionStatement> </saml:Assertion>

Los tres tipos de declaraciones no son mutuamente excluyentes. Por ejemplo, tanto las declaraciones de autenticación como las de atributos pueden incluirse en una sola aserción (como se muestra arriba). Esto evita la necesidad de realizar viajes de ida y vuelta posteriores entre el proveedor de servicios y el proveedor de identidad.

Un protocolo SAML es un protocolo simple de solicitud-respuesta. Un solicitante SAML envía un Requestelemento SAML a un respondedor:

<samlp:Request xmlns:samlp= "urn:oasis:names:tc:SAML:1.0:protocol" MajorVersion= "1" MinorVersion= "1" RequestID= "aaf23196-1773-2113-474a-fe114412ab72" IssueInstant= "2006-07-17T22:26:40Z" > <!-- insertar otros elementos SAML aquí --> </samlp:Request>

De forma similar, un respondedor SAML devuelve un Responseelemento SAML al solicitante:

<samlp:Response xmlns:samlp= "urn:oasis:names:tc:SAML:1.0:protocol" MajorVersion= "1" MinorVersion= "1" ResponseID= "b07b804c-7c29-ea16-7300-4f3d6f7928ac" InResponseTo= "aaf23196-1773-2113-474a-fe114412ab72" IssueInstant= "2006-07-17T22:26:41Z" > <!-- insertar otros elementos SAML aquí, incluidas las aserciones --> </samlp:Response>

Los enlaces y perfiles necesarios para que se produzca este intercambio de mensajes se detallan en las siguientes secciones.

SAML  1.1 define formalmente un único enlace de protocolo : el enlace SAML SOAP. Una  implementación compatible con SAML 1.1 debe implementar SAML sobre SOAP sobre HTTP (un enlace de protocolo síncrono). Se permiten otros mecanismos de transporte además de HTTP, siempre que se respeten los aspectos independientes del protocolo del enlace SAML SOAP (véase la sección  3.1.2 de SAMLBind ^{[ 2 ]} ).

La vinculación SAML  1.1 con SOAP se basa en la versión  1.1 de SOAP (la numeración es pura coincidencia). Un solicitante SAML encapsula un Requestelemento SAML dentro del cuerpo de un mensaje SOAP. De forma similar, un respondedor SAML devuelve un Responseelemento SAML dentro del cuerpo de un mensaje SOAP recibido. Si se produce un error, el respondedor devuelve un código de error SOAP.

Cualquier marcado SAML debe incluirse en el cuerpo SOAP. SAML  1.1 no define encabezados SOAP específicos de SAML. El solicitante puede insertar los encabezados SOAP que desee (aunque ninguno es obligatorio).

Recordemos que en SOAP  1.1, SOAPActionse debe incluir un encabezado HTTP con cada solicitud HTTP (aunque su valor puede estar vacío). Un solicitante SAML puede proporcionar el siguiente valor al SOAPActionencabezado:

Acción SOAPA: http://www.oasis-open.org/committees/security

Sin embargo, un respondedor SAML no debe depender de este valor.

No se requiere una conexión segura para las solicitudes y respuestas SAML, pero en aquellas situaciones en las que se requiere integridad y confidencialidad del mensaje, se requiere HTTP sobre SSL  3.0 o TLS 1.0 con un certificado del lado del servidor. 

Un respondedor SAML puede devolver una respuesta "403 Prohibido" cuando se niega a responder a un solicitante SAML. Un respondedor debe devolver una respuesta "500 Error Interno del Servidor" en caso de un error SOAP (también debe incluirse un elemento de error SOAP). De lo contrario, se devuelve una respuesta "200 OK", incluso en presencia de un error de procesamiento SAML. Dicha respuesta incluirá un Statuselemento SAML en el cuerpo SOAP.

En general, los perfiles describen los casos de uso y los intercambios de mensajes necesarios para transferir finalmente las aserciones de un proveedor de identidad a un proveedor de servicios. SAML  1.1 especifica dos perfiles de SSO para navegadores web :

1. Perfil del navegador/PUBLICACIÓN
2. Perfil del navegador/artefacto

El perfil Browser/POST se basa en una operación de "envío" que transmite una aserción de SSO por valor a través del navegador mediante HTTP POST. Decimos que el proveedor de identidad "envía" la aserción al proveedor de servicios.

El perfil de navegador/artefacto emplea un mecanismo de "extracción". Básicamente, el perfil pasa una aserción de SSO del proveedor de identidad al proveedor de servicios por referencia (a través del navegador mediante redirección HTTP), que posteriormente se desreferencia mediante un intercambio de canal secundario (es decir, el proveedor de servicios "extrae" la aserción del proveedor de identidad mediante SAML sobre SOAP sobre HTTP).

Estos perfiles admiten el inicio de sesión único (SSO) entre dominios . La especificación no define ningún perfil adicional. En particular, SAML  1.1 no admite un perfil para proteger un mensaje de servicio web ni un perfil de cierre de sesión único.

Ambos perfiles SAML  1.1 comienzan en el servicio de transferencia entre sitios , que es administrado por el proveedor de identidad. La especificación no define cómo el usuario llega inicialmente al servicio de transferencia. Consulte las secciones  4.1 y 4.2 de SAMLOverview ^{[ 3 ]} para ver posibles escenarios. En la práctica, un cliente que accede a un recurso seguro en un proveedor de servicios será redirigido al servicio de transferencia entre sitios del proveedor de identidad, pero SAML  1.1 no describe la secuencia precisa de pasos necesarios para lograrlo. (Consulte la sección  4.3 de SAMLOverview ^{[ 3 ]} para obtener algunas ideas generales al respecto). Este escenario se aborda en detalle en SAML  2.0.

Tras acceder al servicio de transferencia entre sitios, el usuario es transferido al servicio de consumidor de aserciones del proveedor de servicios. La forma exacta en que se transfiere el usuario desde el servicio de transferencia entre sitios al servicio de consumidor de aserciones depende del perfil utilizado. En el caso del perfil Navegador/Artefacto, se utiliza una redirección; en el caso del perfil Navegador/POST, el cliente realiza una solicitud POST (con o sin intervención del usuario).

Para agilizar el procesamiento por parte del servicio de consumidor de aserciones, se especifican dos URL separadas:

1. URL del consumidor de aserciones (perfil de navegador/POST)
2. URL del receptor de artefactos (Navegador/Perfil de artefacto)

Estas y otras ubicaciones de puntos finales pueden registrarse en archivos de metadatos. La forma exacta en que el proveedor de identidad obtiene un archivo de metadatos de confianza, o determina de otro modo las ubicaciones de puntos finales de confianza de un proveedor de servicios en particular, queda fuera del alcance de SAML  1.1.

Cabe destacar que un proveedor de identidad SAML  1.1 que cumpla con el estándar debe ofrecer un servicio de transferencia entre sitios. Del mismo modo, un  proveedor de servicios SAML 1.1 debe ofrecer un servicio de consumidor de aserciones.

https://idp.example.org/TransferService?TARGET=target​​

GET /TransferService?TARGET=target HTTP / 1.1 Host : idp.example.org

HTTP / 1.1 200 OK Content-Type : text/html Content-Length : nnnn ... < form method = "post" action = "https://sp.example.com/ACS/POST" ... > < input type = "hidden" name = "TARGET" value = "target" /> < input type = "hidden" name = "SAMLResponse" value = "''response''" /> ... < input type = "submit" value = " Enviar" / > </form> ... 

<samlp:Response xmlns:samlp= "urn:oasis:names:tc:SAML:1.0:protocol" MajorVersion= "1" MinorVersion= "1" ResponseID= "_P1YaA+Q/wSM/t/8E3R8rNhcpPTM=" IssueInstant= "2002-06-19T17:05:37.795Z" > <ds:Signature xmlns:ds= "http://www.w3.org/2000/09/xmldsig#" > ... </ds:Signature> <samlp:Status> <samlp:StatusCode Value= "samlp:Success" /> </samlp:Status> <saml:Assertion xmlns:saml= "urn:oasis:names:tc:SAML:1.0:assertion" MajorVersion= "1" MinorVersion= "1" AssertionID= "buGxcG4gILg5NlocyLccDz6iXrUa" Issuer= "https://idp.example.org/saml" IssueInstant= "2002-06-19T17:05:37.795Z" > <saml:Conditions NotBefore= "2002-06-19T17:00:37.795Z" NotOnOrAfter= "2002-06-19T17:10:37.795Z" /> <saml:AuthenticationStatement AuthenticationMethod= "urn:oasis:names:tc:SAML:1.0:am:password" AuthenticationInstant= "2002-06-19T17:05:17.706Z" > <saml:Subject> <saml:NameIdentifier Format= "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress" > user@idp.example.org </saml:NameIdentifier> <saml:SubjectConfirmation> <saml:ConfirmationMethod> urn:oasis:names:tc:SAML:1.0:cm:bearer </saml:ConfirmationMethod> </saml:SubjectConfirmation> </saml:Subject> </saml:AuthenticationStatement> </saml:Assertion> </saml:Response>

POST /ACS/POST HTTP / 1.1 Host : sp.example.com Content-Type : application/x-www-form-urlencoded Content-Length : nnnn TARGET=target&SAMLResponse=response

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

https://idp.example.org/TransferService?TARGET=target​​

GET /TransferService?TARGET=target HTTP / 1.1 Host : idp.example.org

HTTP / 1.1 302 Encontrado Ubicación : https://sp.example.com/ACS/Artifact?TARGET=target&SAMLart=artifact

https://sp.example.com/ACS/Artifact ?TARGET= objetivo &SAMLart= artefacto

GET /ACS/Artifact?TARGET=target&SAMLart=artifact HTTP / 1.1 Host : sp.example.com

POST /ArtifactResolutionService HTTP/1.1 Host: idp.example.org Tipo de contenido: texto/xml Longitud del contenido: nnn SOAPAction: http://www.oasis-open.org/committees/security <SOAP-ENV:Envelope xmlns:SOAP-ENV= "http://schemas.xmlsoap.org/soap/envelope/" > <SOAP-ENV:Header/> <SOAP-ENV:Body> <samlp:Request xmlns:samlp= "urn:oasis:names:tc:SAML:1.0:protocol" MajorVersion= "1" MinorVersion= "1" RequestID= "_192.168.16.51.1024506224022" IssueInstant= "2002-06-19T17:03:44.022Z" > <samlp:AssertionArtifact> artifact </samlp:AssertionArtifact> </samlp:Request> </SOAP-ENV:Body> </SOAP-ENV:Envelope>

HTTP/1.1 200 OK Tipo de contenido: texto/xml Content-Length: nnnn <SOAP-ENV:Envelope xmlns:SOAP-ENV= "http://schemas.xmlsoap.org/soap/envelope/" > <SOAP-ENV:Header/> <SOAP-ENV:Body> <samlp:Response xmlns:samlp= "urn:oasis:names:tc:SAML:1.0:protocol" MajorVersion= "1" MinorVersion= "1" ResponseID= "_P1YaA+Q/wSM/t/8E3R8rNhcpPTM=" InResponseTo= "_192.168.16.51.1024506224022" IssueInstant= "2002-06-19T17:05:37.795Z" > <samlp:Status> <samlp:StatusCode Value= "samlp:Success" /> </samlp:Status> <saml:Assertion xmlns:saml= "urn:oasis:names:tc:SAML:1.0:assertion" MajorVersion= "1" MinorVersion= "1" AssertionID= "buGxcG4gILg5NlocyLccDz6iXrUa" Issuer= "https://idp.example.org/saml" IssueInstant= "2002-06-19T17:05:37.795Z" > <saml:Conditions NotBefore= "2002-06-19T17:00:37.795Z" NotOnOrAfter= "2002-06-19T17:10:37.795Z" /> <saml:AuthenticationStatement AuthenticationMethod= "urn:oasis:names:tc:SAML:1.0:am:password" AuthenticationInstant= "2002-06-19T17:05:17.706Z" > <saml:Subject> <saml:NameIdentifier Format= "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress" > user@idp.example.org </saml:NameIdentifier> <saml:SubjectConfirmation> <saml:ConfirmationMethod> urn:oasis:names:tc:SAML:1.0:cm:artifact </saml:ConfirmationMethod> </saml:SubjectConfirmation> </saml:Subject> </saml:AuthenticationStatement> </saml:Assertion> </samlp:Response> </SOAP-ENV:Body> </SOAP-ENV:Envelope>

• SAML
• SAML 2.0
• Productos y servicios basados ​​en SAML