Visión General de SAML

Security Assertion Markup Language (SAML) permite que los proveedores de identidad (IdP) se utilicen para enviar credenciales de autorización a los proveedores de servicios (SP), facilitando el inicio de sesión único (SSO). Este enfoque simplifica la gestión de múltiples inicios de sesión al permitir que un solo conjunto de credenciales se utilice en múltiples sitios web. Aprovecha XML para la comunicación estandarizada entre IdPs y SPs, vinculando la autenticación de la identidad del usuario con la autorización del servicio.

Comparación entre SAML y OAuth

• SAML está diseñado para proporcionar a las empresas un mayor control sobre la seguridad del inicio de sesión SSO.
• OAuth está diseñado para ser más amigable con dispositivos móviles, utiliza JSON y es un esfuerzo colaborativo de empresas como Google y Twitter.

Flujo de Autenticación SAML

Para más detalles, consulta la publicación completa en https://epi052.gitlab.io/notes-to-self/blog/2019-03-07-how-to-test-saml-a-methodology/. Este es un resumen:

El proceso de autenticación SAML implica varios pasos, como se ilustra en el esquema:

1. Intento de Acceso a Recurso: El usuario intenta acceder a un recurso protegido.
2. Generación de Solicitud SAML: El SP no reconoce al usuario y genera una Solicitud SAML.
3. Redirección a IdP: El usuario es redirigido al IdP, con la Solicitud SAML pasando a través del navegador del usuario.
4. IdP Recibe la Solicitud: El IdP recibe la Solicitud SAML.
5. Autenticación en IdP: El IdP autentica al usuario.
6. Validación del Usuario: El IdP valida la legitimidad del usuario para acceder al recurso solicitado.
7. Creación de Respuesta SAML: El IdP genera una Respuesta SAML que contiene las afirmaciones necesarias.
8. Redirección a la URL ACS del SP: El usuario es redirigido a la URL del Servicio Consumidor de Afirmaciones (ACS) del SP.
9. Validación de la Respuesta SAML: El ACS valida la Respuesta SAML.
10. Acceso al Recurso Concedido: Se concede acceso al recurso inicialmente solicitado.

Ejemplo de Solicitud SAML

Considera el escenario en el que un usuario solicita acceso a un recurso seguro en https://shibdemo-sp1.test.edu/secure/. El SP identifica la falta de autenticación y genera una Solicitud SAML:

GET /secure/ HTTP/1.1
Host: shibdemo-sp1.test.edu
...

La solicitud SAML en bruto se ve así:

<?xml version="1.0"?>
<samlp:AuthnRequest ...
</samlp:AuthnRequest>

Elementos clave de esta solicitud incluyen:

• AssertionConsumerServiceURL: Especifica dónde el IdP debe enviar la SAML Response después de la autenticación.
• Destination: La dirección del IdP a la que se envía la solicitud.
• ProtocolBinding: Define el método de transmisión de los mensajes del protocolo SAML.
• saml:Issuer: Identifica la entidad que inició la solicitud.

Tras la generación de la SAML Request, el SP responde con un 302 redirect, dirigiendo el navegador al IdP con la SAML Request codificada en el encabezado Location de la respuesta HTTP. El parámetro RelayState mantiene la información de estado a lo largo de la transacción, asegurando que el SP reconozca la solicitud de recurso inicial al recibir la SAML Response. El parámetro SAMLRequest es una versión comprimida y codificada del fragmento XML en bruto, utilizando compresión Deflate y codificación base64.

Ejemplo de SAML Response

Puedes encontrar una respuesta SAML completa aquí. Los componentes clave de la respuesta incluyen:

• ds:Signature: Esta sección, una Firma XML, asegura la integridad y autenticidad del emisor de la afirmación. La SAML response en el ejemplo contiene dos elementos ds:Signature, uno para el mensaje y el otro para la afirmación.
• saml:Assertion: Esta parte contiene información sobre la identidad del usuario y posiblemente otros atributos.
• saml:Subject: Especifica el sujeto principal de todas las declaraciones en la afirmación.
• saml:StatusCode: Representa el estado de la operación en respuesta a la solicitud correspondiente.
• saml:Conditions: Detalla condiciones como el tiempo de validez de la Assertion y el Service Provider especificado.
• saml:AuthnStatement: Confirma que el IdP autenticó al sujeto de la Assertion.
• saml:AttributeStatement: Contiene atributos que describen al sujeto de la Assertion.

Tras la SAML Response, el proceso incluye un 302 redirect desde el IdP. Esto lleva a una solicitud POST a la URL del Assertion Consumer Service (ACS) del Service Provider. La solicitud POST incluye los parámetros RelayState y SAMLResponse. El ACS es responsable de procesar y validar la SAML Response.

Después de que se recibe la solicitud POST y se valida la SAML Response, se concede acceso al recurso protegido solicitado inicialmente por el usuario. Esto se ilustra con una solicitud GET al endpoint /secure/ y una respuesta 200 OK, indicando acceso exitoso al recurso.

Firmas XML

Las Firmas XML son versátiles, capaces de firmar un árbol XML completo o elementos específicos dentro de él. Pueden aplicarse a cualquier Objeto XML, no solo a elementos de Respuesta. A continuación se presentan los tipos clave de Firmas XML:

Estructura Básica de la Firma XML

Una Firma XML consiste en elementos esenciales como se muestra:

<Signature>
<SignedInfo>
<CanonicalizationMethod />
<SignatureMethod />
<Reference>
<Transforms />
<DigestMethod />
<DigestValue />
</Reference>
...
</SignedInfo>
<SignatureValue />
<KeyInfo />
<Object />
</Signature>

Cada elemento Reference significa un recurso específico que está siendo firmado, identificable por el atributo URI.

Tipos de Firmas XML

1. Firma Envolvente: Este tipo de firma es un descendiente del recurso que firma, lo que significa que la firma está contenida dentro de la misma estructura XML que el contenido firmado.

Ejemplo:

<samlp:Response ... ID="..." ... >
...
<ds:Signature>
<ds:SignedInfo>
...
<ds:Reference URI="#...">
...
</ds:Reference>
</ds:SignedInfo>
</ds:Signature>
...
</samlp:Response>

En una firma envolvente, el elemento ds:Transform especifica que está envuelta a través del algoritmo enveloped-signature.

2. Firma Envolvente: A diferencia de las firmas envolventes, las firmas envolventes envuelven el recurso que se está firmando.

Ejemplo:

<ds:Signature>
<ds:SignedInfo>
...
<ds:Reference URI="#...">
...
</ds:Reference>
</ds:SignedInfo>
<samlp:Response ... ID="..." ... >
...
</samlp:Response>
</ds:Signature>

3. Firma Desprendida: Este tipo es independiente del contenido que firma. La firma y el contenido existen de manera independiente, pero se mantiene un vínculo entre ambos.

Ejemplo:

<samlp:Response ... ID="..." ... >
...
</samlp:Response>
<ds:Signature>
<ds:SignedInfo>
...
<ds:Reference URI="#...">
...
</ds:Reference>
</ds:SignedInfo>
</ds:Signature>

En conclusión, las Firmas XML proporcionan formas flexibles de asegurar documentos XML, con cada tipo sirviendo a diferentes necesidades estructurales y de seguridad.

Referencias

• https://epi052.gitlab.io/notes-to-self/blog/2019-03-07-how-to-test-saml-a-methodology/