<summary><strong>Aprende hacking en AWS de cero a héroe con</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* Si quieres ver a tu **empresa anunciada en HackTricks** o **descargar HackTricks en PDF**, consulta los [**PLANES DE SUSCRIPCIÓN**](https://github.com/sponsors/carlospolop)!
* Consigue el [**merchandising oficial de PEASS & HackTricks**](https://peass.creator-spring.com)
* Descubre [**La Familia PEASS**](https://opensea.io/collection/the-peass-family), nuestra colección de [**NFTs**](https://opensea.io/collection/the-peass-family) exclusivos
* **Únete al** 💬 [**grupo de Discord**](https://discord.gg/hRep4RUj7f) o al [**grupo de Telegram**](https://t.me/peass) o **sigue** a **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Comparte tus trucos de hacking enviando PRs a los repositorios de GitHub de** [**HackTricks**](https://github.com/carlospolop/hacktricks) y [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).
Security Assertion Markup Language (SAML) es un estándar abierto que permite a los proveedores de identidad (IdP) pasar credenciales de autorización a los proveedores de servicios (SP). Lo que significa ese tecnicismo es que puedes **usar un conjunto de credenciales para iniciar sesión en muchos sitios web diferentes**. Es mucho más sencillo gestionar un inicio de sesión por usuario que gestionar inicios de sesión separados para el correo electrónico, software de gestión de relaciones con clientes (CRM), Active Directory, etc.
Las transacciones SAML utilizan Extensible Markup Language (XML) para comunicaciones estandarizadas entre el proveedor de identidad y los proveedores de servicios. SAML es el enlace entre la autenticación de la identidad de un usuario y la autorización para usar un servicio. (De [aquí](https://www.varonis.com/blog/what-is-saml/))
OAuth es un estándar un poco más reciente que fue co-desarrollado por Google y Twitter para facilitar los inicios de sesión en Internet. OAuth utiliza una metodología similar a SAML para compartir información de inicio de sesión. **SAML ofrece más control** a las empresas para mantener sus inicios de sesión SSO más seguros, mientras que **OAuth es mejor en dispositivos móviles y utiliza JSON**.
2. Paso 2 - El servidor donde reside ese recurso (Proveedor de Servicios) no nos conoce, por lo que genera una **Solicitud SAML** para enviar al Proveedor de Identidad. Sería como llegar a Alemania sin nuestro pasaporte y ser enviado de vuelta a EE.UU. para obtener nuestro pasaporte antes de poder entrar al país.
3. Paso 3 - Después de generar la Solicitud SAML, el SP nos **redirige** al IdP. Nota: La Solicitud SAML pasa por nuestro navegador en el camino hacia el IdP.
5. Paso 4a (no mostrado) - El IdP proporciona algún medio de autenticación; un formulario de inicio de sesión o algo similar.
6. Paso 4b (no mostrado) - El IdP nos valida como un usuario legítimo que debería tener permiso para acceder al recurso incluido como parte de la Solicitud SAML
7. Paso 5 - El IdP crea una **Respuesta SAML**. La Respuesta SAML contiene las Afirmaciones SAML necesarias para el SP. La Afirmación generalmente incluye la siguiente información como mínimo: Indicación de que la Afirmación proviene del IdP correcto, un atributo **NameID** que especifica quién es el usuario y una firma digital. La Respuesta SAML también pasa por nuestro navegador.
8. Paso 6 - El IdP nos **redirige** a la URL del Servicio de Consumo de Afirmaciones (ACS) del SP. El ACS es simplemente la URL en la que el SP espera recibir afirmaciones SAML.
Vamos a examinar más de cerca los pasos 2 y 3 mencionados anteriormente. Haremos una solicitud al Proveedor de Servicios de ejemplo para el recurso ubicado en [https://shibdemo-sp1.test.edu/secure/](https://shibdemo-sp1.test.edu/secure/), que como su nombre indica, es contenido que requiere que estemos autenticados para ver.
* **AssertionConsumerServiceURL**: Identifica dónde el IdP debe enviar la Respuesta SAML después de la autenticación
* **Destination**: Indica la dirección a la que se debe enviar la solicitud (IdP)
* **ProtocolBinding**: Acompaña típicamente al atributo AssertionConsumerServiceURL; define el mecanismo por el cual se transmitirán los mensajes del protocolo SAML
* **saml:Issuer**: Identifica la entidad que generó el mensaje de solicitud
Hemos resaltado los elementos más pertinentes de la solicitud arriba, pero los detalles sobre cualquiera de los otros elementos se pueden ver en la [especificación principal](https://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf). La solicitud anterior se resume así: "Hola, por favor autentica al usuario que envió este mensaje y luego que el mismo usuario me contacte cuando hayan terminado".
Con la Solicitud SAML creada, el SP ahora responde a nuestra solicitud GET para `/secure/` con un **redireccionamiento 302**. El 302 dirige nuestro navegador hacia el IdP. La Solicitud SAML se codifica en el encabezado **Location** de la respuesta HTTP como parte del 302.
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>302 Found</title>
</head><body>
<h1>Found</h1>
<p>The document has moved <ahref="https://shibdemo-idp.test.edu/idp/profile/SAML2/Redirect/SSO?SAMLRequest=fZJdT4MwFIb%2FCuk9FNgmWzNIcLtwyXRkoBfemFKO0gRa7Cl%2B%2FHvZmDoTs8u2b5%2B350mXyNumY2lva7WH1x7QOh9to5AdD2LSG8U0R4lM8RaQWcHy9HbLQs9nndFWC90QJ0UEY6VWK62wb8HkYN6kgPv9Nia1tR0ySrGWZQWtdrELPDs0eVD1NB92S92ArT1ETQ%2FwkGa7vCDOeshIxQ%2Fcfyiy6n4pw4IOz3mWDZwQe6ikAWFpnu%2BIs1nH5ElUHKJgHk7mJV%2BI0I%2F4ZCZEJCK%2F9KdX3B9iiD1sFFqubExCP1i4%2FsQNwiL02WzKZvNH4mSnqa%2BlqqR6uayoHEPIbooic8exHsDgcaQhQJLlQTQ7Fpsz9Zex%2FNs3SS7bxR%2B7S3pWNLZ27G4gb9aZbqT4dNKm0e8rA9xCTAJCk%2FHK39%2BRfAE%3D&RelayState=ss%3Amem%3A39430bdac29d44586c326f12b4cb3345ffa47137a374e37cba0877e0fc79ea91">here</a>.</p>
<hr>
<address>Apache/2.2.3 (CentOS) Server at shibdemo-sp1.test.edu Port 443</address>
El parámetro **RelayState** enviado junto con la solicitud SAML es información de estado enviada por el SP al IdP para que el SP sepa quién solicitó inicialmente el recurso cuando la respuesta SAML regresa. La respuesta SAML debe contener el mismo valor de RelayState.
El parámetro **SAMLRequest** es una versión **comprimida** y **codificada** del mismo fragmento de xml en bruto que vimos anteriormente. SAML utiliza el algoritmo de compresión [Deflate](https://en.wikipedia.org/wiki/DEFLATE) y luego codifica el resultado en base64.
Vamos a omitir el paso por el cual el usuario se autentica en el IdP y saltar directamente a los pasos 5 y 6 de lo que se discutió en el [Flujo de Autenticación SAML](https://epi052.gitlab.io/notes-to-self/blog/2019-03-07-how-to-test-saml-a-methodology/#saml-authentication-workflow). Solo ten en cuenta que lo **que vamos a ver ocurre después de que el usuario se autentica en el IdP.**
* **ds:Signature**: Una [Firma XML](https://www.w3.org/TR/xmldsig-core1/#sec-KeyInfo) que protege la integridad y autentica al emisor de la afirmación; la afirmación SAML PUEDE estar firmada pero no es obligatorio. El ejemplo anterior contiene dos elementos ds:Signature. La razón es que uno es la firma del mensaje; el otro es la firma de la Afirmación.
* **saml:Assertion**: Contiene información sobre la identidad del usuario y potencialmente otros atributos del usuario.
* **saml:Conditions**: Especifica cosas como el tiempo en que una Afirmación es válida y que la Afirmación está dirigida a un Proveedor de Servicios en particular.
* **saml:AuthnStatement**: Declara que el IdP autenticó al Sujeto de la Afirmación.
* **saml:AttributeStatement**: Contiene Atributos que describen al Sujeto de la Afirmación.
Ahora que nos hemos autenticado con el IdP y este ha generado la Respuesta SAML anterior, responde a nuestra autenticación con otro redireccionamiento 302.
El 302 finalmente nos lleva a realizar una solicitud POST a la URL del Servicio de Consumo de Aserciones (Assertion Consumer Service, ACS) del Proveedor de Servicios. El cuerpo del POST contiene los parámetros RelayState y SAMLResponse. Recuerda que el ACS procesa y valida la Respuesta SAML.
¡Casi hemos terminado de cubrir todos los conceptos básicos que necesitamos para avanzar hacia las pruebas reales! El último elemento que necesitamos abordar son las Firmas XML. Curiosamente, las Firmas XML pueden usarse para **firmar un árbol XML completo o elementos específicos** dentro del árbol. Ya vimos anteriormente que se utilizaron dos Firmas XML separadas en nuestra Respuesta SAML de ejemplo. Cada firma era responsable de una parte diferente de la Respuesta. En esta sección, veremos las diferentes formas en que una Firma XML puede incorporarse en un documento XML. Algo a tener en cuenta es que, aunque nuestros ejemplos utilizan el elemento Response como el recurso a firmar, las Firmas XML se pueden aplicar a cualquier Objeto, incluyendo los elementos Assertion.
De especial interés para nosotros es que cada recurso a firmar tiene su propio elemento Reference. El atributo URI del elemento Reference denota qué recurso está firmado por esa Signature en particular. Examinando nuestro ejemplo anterior, podemos ver esto en la práctica.
Lo que vimos en nuestro ejemplo anterior es conocido como una **firma envuelta**. Una firma envuelta es una firma que es descendiente del recurso que está firmando. Podemos ver eso detallado para nosotros en el elemento ds:Transform de nuestro ejemplo.
Finalmente, existen las **firmas desconectadas**. Una firma desconectada no envuelve ni está envuelta por el recurso a firmar. En cambio, es completamente separada del recurso firmado.
La mayor parte del contenido fue copiado de [https://epi052.gitlab.io/notes-to-self/blog/2019-03-07-how-to-test-saml-a-methodology/](https://epi052.gitlab.io/notes-to-self/blog/2019-03-07-how-to-test-saml-a-methodology/)
<summary><strong>Aprende hacking en AWS de cero a héroe con</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* Si quieres ver tu **empresa anunciada en HackTricks** o **descargar HackTricks en PDF** revisa los [**PLANES DE SUSCRIPCIÓN**](https://github.com/sponsors/carlospolop)!
* Consigue el [**merchandising oficial de PEASS & HackTricks**](https://peass.creator-spring.com)
* Descubre [**La Familia PEASS**](https://opensea.io/collection/the-peass-family), nuestra colección de [**NFTs**](https://opensea.io/collection/the-peass-family) exclusivos
* **Únete al** 💬 [**grupo de Discord**](https://discord.gg/hRep4RUj7f) o al [**grupo de telegram**](https://t.me/peass) o **sígueme** en **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Comparte tus trucos de hacking enviando PRs a los repositorios de github** [**HackTricks**](https://github.com/carlospolop/hacktricks) y [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).
