hacktricks/pentesting-web/saml-attacks/saml-basics.md

{% hint style="success" %}
Learn & practice AWS Hacking:<img src="/.gitbook/assets/arte.png" alt="" data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="/.gitbook/assets/arte.png" alt="" data-size="line">\
Learn & practice GCP Hacking: <img src="/.gitbook/assets/grte.png" alt="" data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<img src="/.gitbook/assets/grte.png" alt="" data-size="line">](https://training.hacktricks.xyz/courses/grte)

<details>

<summary>Support HackTricks</summary>

* Check the [**subscription plans**](https://github.com/sponsors/carlospolop)!
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
* **Share hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.

</details>
{% endhint %}


# SAML Overview

**Security Assertion Markup Language (SAML)** enables identity providers (IdP) to be utilized for sending authorization credentials to service providers (SP), facilitating single sign-on (SSO). This approach simplifies the management of multiple logins by allowing a single set of credentials to be used across multiple websites. It leverages XML for standardized communication between IdPs and SPs, linking the authentication of user identity with service authorization.

## Comparison between SAML and OAuth

- **SAML** is tailored towards providing enterprises with greater control over SSO login security.
- **OAuth** is designed to be more mobile-friendly, uses JSON, and is a collaborative effort from companies like Google and Twitter.

# SAML Authentication Flow

**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/](https://epi052.gitlab.io/notes-to-self/blog/2019-03-07-how-to-test-saml-a-methodology/)**. This is a summary:

The SAML authentication process involves several steps, as illustrated in the schema:

![https://epi052.gitlab.io/notes-to-self/img/saml/saml-flow.jpg](https://epi052.gitlab.io/notes-to-self/img/saml/saml-flow.jpg)

1. **Resource Access Attempt**: The user tries to access a protected resource.
2. **SAML Request Generation**: The SP does not recognize the user and generates a SAML Request.
3. **Redirect to IdP**: The user is redirected to the IdP, with the SAML Request passing through the user's browser.
4. **IdP Receives Request**: The IdP receives the SAML Request.
5. **Authentication at IdP**: The IdP authenticates the user.
6. **User Validation**: The IdP validates the user's legitimacy to access the requested resource.
7. **SAML Response Creation**: The IdP generates a SAML Response containing necessary assertions.
8. **Redirect to SP's ACS URL**: The user is redirected to the SP's Assertion Consumer Service (ACS) URL.
9. **SAML Response Validation**: The ACS validates the SAML Response.
10. **Resource Access Granted**: Access to the initially requested resource is granted.

# SAML Request Example

Consider the scenario where a user requests access to a secure resource at [https://shibdemo-sp1.test.edu/secure/](https://shibdemo-sp1.test.edu/secure/). The SP identifies the lack of authentication and generates a SAML Request:

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

The raw SAML Request looks like this:

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

Key elements of this request include:
- **AssertionConsumerServiceURL**: Specifies where the IdP should send the SAML Response post-authentication.
- **Destination**: The IdP's address to which the request is sent.
- **ProtocolBinding**: Defines the transmission method of SAML protocol messages.
- **saml:Issuer**: Identifies the entity that initiated the request.

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.


# SAML Response Example

You can find a [full SAML response here](https://epi052.gitlab.io/notes-to-self/blog/2019-03-07-how-to-test-saml-a-methodology/). The key components of the response include:

- **ds:Signature**: This section, an XML Signature, ensures the integrity and authenticity of the issuer of the assertion. The SAML response in the example contains two `ds:Signature` elements, one for the message and the other for the assertion.
- **saml:Assertion**: This part holds information about the user's identity and possibly other attributes.
- **saml:Subject**: It specifies the principal subject of all the statements in the assertion.
- **saml:StatusCode**: Represents the status of the operation in response to the corresponding request.
- **saml:Conditions**: Details conditions like the validity timing of the Assertion and the specified Service Provider.
- **saml:AuthnStatement**: Confirms that the IdP authenticated the subject of the Assertion.
- **saml:AttributeStatement**: Contains attributes describing the subject of the Assertion.

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

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:

### Basic Structure of XML Signature
An XML Signature consists of essential elements as shown:

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

Each `Reference` element signifies a specific resource being signed, identifiable by the URI attribute.

### Types of XML Signatures

1. **Enveloped Signature**: This type of signature is a descendant of the resource it signs, meaning the signature is contained within the same XML structure as the signed content.

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

   In an enveloped signature, the `ds:Transform` element specifies that it's enveloped through the `enveloped-signature` algorithm.

2. **Enveloping Signature**: Contrasting with enveloped signatures, enveloping signatures wrap the resource being signed.

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

3. **Detached Signature**: This type is separate from the content it signs. The signature and the content exist independently, but a link between the two is maintained.

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

In conclusion, XML Signatures provide flexible ways to secure XML documents, with each type serving different structural and security needs.


## References
* [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/)

{% hint style="success" %}
Learn & practice AWS Hacking:<img src="/.gitbook/assets/arte.png" alt="" data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="/.gitbook/assets/arte.png" alt="" data-size="line">\
Learn & practice GCP Hacking: <img src="/.gitbook/assets/grte.png" alt="" data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<img src="/.gitbook/assets/grte.png" alt="" data-size="line">](https://training.hacktricks.xyz/courses/grte)

<details>

<summary>Support HackTricks</summary>

* Check the [**subscription plans**](https://github.com/sponsors/carlospolop)!
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
* **Share hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.

</details>
{% endhint %}