SAML Basics
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
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. 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.
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.
For further details check the full post from https://epi052.gitlab.io/notes-to-self/blog/2019-03-07-how-to-test-saml-a-methodology/. This is a summary:
El proceso de autenticación SAML implica varios pasos, como se ilustra en el esquema:
Intento de Acceso a Recurso: 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 a 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 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 Consumidor de Afirmaciones (ACS) del SP.
Validación de la Respuesta SAML: El ACS valida la Respuesta SAML.
Acceso al Recurso Concedido: Se concede acceso al recurso inicialmente solicitado.
Considere 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í:
Key elements of this request include:
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.
Following the SAML Request generation, the SP responds with a 302 redirect, directing the browser to the IdP with the SAML Request encoded in the HTTP response's Location header. The RelayState parameter maintains the state information throughout the transaction, ensuring the SP recognizes the initial resource request upon receiving the SAML Response. The SAMLRequest parameter is a compressed and encoded version of the raw XML snippet, utilizing Deflate compression and base64 encoding.
You can find a full SAML response here. The key components of the response include:
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 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.
Following the SAML Response, the process includes a 302 redirect from the IdP. This leads to a POST request to the Service Provider's Assertion Consumer Service (ACS) URL. The POST request includes RelayState and SAMLResponse parameters. The ACS is responsible for processing and validating the SAML Response.
After the POST request is received and the SAML Response is validated, access is granted to the protected resource initially requested by the user. This is illustrated with a GET request to the /secure/ endpoint and a 200 OK response, indicating successful access to the resource.
XML Signatures are versatile, capable of signing an entire XML tree or specific elements within it. They can be applied to any XML Object, not just Response elements. Below are the key types of XML Signatures:
An XML Signature consists of essential elements as shown:
Cada Reference elemento significa un recurso específico que está siendo firmado, identificable por el atributo URI.
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á envuelta a través del algoritmo enveloped-signature.
Firma Envolvente: A diferencia de las firmas envolventes, las firmas envolventes envuelven el recurso que se está firmando.
Ejemplo:
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:
En conclusión, las Firmas XML proporcionan formas flexibles de asegurar documentos XML, con cada tipo sirviendo a diferentes necesidades estructurales y de seguridad.
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
