SAML Basics
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 varios sitios web. Utiliza 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 para 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:
Intento de acceso a recursos: El usuario intenta acceder a un recurso protegido.
Generación de solicitud SAML: El SP no reconoce al usuario y genera una solicitud SAML.
Redirección al IdP: El usuario es redirigido al IdP, con la solicitud SAML pasando a través del navegador del usuario.
IdP recibe la solicitud: El IdP recibe la solicitud SAML.
Autenticación en el IdP: El IdP autentica al usuario.
Validación del usuario: El IdP valida la legitimidad del usuario para acceder al recurso solicitado.
Creación de respuesta SAML: El IdP genera una respuesta SAML que contiene las afirmaciones necesarias.
Redirección a la URL ACS del SP: El usuario es redirigido a la URL del Servicio de Consumidor de Afirmaciones (ACS) del SP.
Validación de la respuesta SAML: El ACS valida la respuesta SAML.
Acceso a recursos concedido: Se concede acceso al recurso solicitado inicialmente.
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:
La solicitud SAML en bruto se ve así:
Los elementos clave de esta solicitud incluyen:
AssertionConsumerServiceURL: Especifica a dónde debe enviar el IdP la Respuesta SAML 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 mensajes del protocolo SAML.
saml:Issuer: Identifica la entidad que inició la solicitud.
Después de generar la Solicitud SAML, el SP responde con una redirección 302, dirigiendo el navegador al IdP con la Solicitud SAML codificada en el encabezado Location de la respuesta HTTP. El parámetro RelayState mantiene la información de estado durante la transacción, asegurando que el SP reconozca la solicitud de recurso inicial al recibir la Respuesta SAML. El parámetro SAMLRequest es una versión comprimida y codificada del fragmento XML sin procesar, utilizando compresión Deflate y codificación base64.
Ejemplo de Respuesta SAML
Puedes encontrar una respuesta SAML completa aquí. Los componentes clave de la respuesta incluyen:
ds:Signature: Esta sección, una Firma XML, garantiza la integridad y autenticidad del emisor de la afirmación. La respuesta SAML en el ejemplo contiene dos elementos
ds:Signature, uno para el mensaje y 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 Afirmación y el Proveedor de Servicios especificado.
saml:AuthnStatement: Confirma que el IdP autenticó al sujeto de la Afirmación.
saml:AttributeStatement: Contiene atributos que describen al sujeto de la Afirmación.
Después de la Respuesta SAML, el proceso incluye una redirección 302 desde el IdP. Esto lleva a una solicitud POST a la URL del Servicio de Consumidor de Afirmaciones (ACS) del Proveedor de Servicios. La solicitud POST incluye los parámetros RelayState y SAMLResponse. El ACS es responsable de procesar y validar la Respuesta SAML.
Después de recibir la solicitud POST y validar la Respuesta SAML, se otorga acceso al recurso protegido solicitado inicialmente por el usuario. Esto se ilustra con una solicitud GET al punto final /secure/ y una respuesta 200 OK, indicando un 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. Se pueden aplicar a cualquier Objeto XML, no solo a elementos de Respuesta. A continuación se muestran los tipos clave de Firmas XML:
Estructura Básica de la Firma XML
Una Firma XML consta de elementos esenciales como se muestra:
Cada elemento Reference significa un recurso específico que está siendo firmado, identificable por el atributo URI.
Tipos de Firmas XML
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:
En una firma envolvente, el elemento ds:Transform especifica que está envuelto a través del algoritmo enveloped-signature.
Firma Envolvente: A diferencia de las firmas envolventes, las firmas envolventes envuelven el recurso que está siendo firmado.
Ejemplo:
Firma Desvinculada: Este tipo está separado del contenido que firma. La firma y el contenido existen de forma independiente, pero se mantiene un enlace entre los dos.
Ejemplo:
En conclusión, las Firmas XML proporcionan formas flexibles de asegurar documentos XML, con cada tipo sirviendo diferentes necesidades estructurales y de seguridad.
Referencias
Última actualización
