saml-basics.md (9212B)
1 --- 2 title: "SAML Basics" 3 section: "Web Pentesting" 4 sectionSlug: "pentesting-web" 5 sourcePath: "src/pentesting-web/saml-attacks/saml-basics.md" 6 sourceUrl: "https://github.com/HackTricks-wiki/hacktricks/blob/188de82beb54e70956b2952367a0af91d26758b8/src/pentesting-web/saml-attacks/saml-basics.md" 7 sha: "188de82beb54e70956b2952367a0af91d26758b8" 8 isIndex: false 9 modified: true 10 license: "CC-BY-NC-4.0" 11 --- 12 13 # SAML Basics 14 15 ## SAML Overview 16 17 **Security Assertion Markup Language (SAML)** is an XML-based framework for exchanging assertions between an identity provider (IdP) and a service provider (SP). Assertions can carry authentication, attribute, and authorization-decision statements; the SAML 2.0 Web Browser SSO profile is commonly used to establish an SP session after the IdP authenticates the user.<sup>[[2]](#references)</sup> 18 19 ### Comparison between SAML and OAuth 20 21 - **SAML 2.0** defines assertions, protocols, bindings, and profiles, including browser SSO. Messages and assertions are XML. 22 - **OAuth 2.0** is an authorization framework for delegated access; it is not an authentication protocol and does not require JSON tokens. **OpenID Connect** adds an identity layer and authentication semantics on top of OAuth 2.0.<sup>[[3]](#references)[[4]](#references)</sup> 23 24 ## SAML Authentication Flow 25 26 **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:<sup>[[1]](#references)</sup> 27 28 The flow below is the common **SP-initiated Web Browser SSO** profile using an HTTP-Redirect `AuthnRequest` and an HTTP-POST `Response`; SAML also supports other bindings and IdP-initiated flows.<sup>[[2]](#references)</sup> 29 30  31 32 1. **Resource Access Attempt**: The user tries to access a protected resource. 33 2. **SAML Request Generation**: The SP does not recognize the user and generates a SAML Request. 34 3. **Redirect to IdP**: The user is redirected to the IdP, with the SAML Request passing through the user's browser. 35 4. **IdP Receives Request**: The IdP receives the SAML Request. 36 5. **Authentication at IdP**: The IdP authenticates the user. 37 6. **User Validation**: The IdP validates the user's legitimacy to access the requested resource. 38 7. **SAML Response Creation**: The IdP generates a SAML Response containing necessary assertions. 39 8. **Redirect to SP's ACS URL**: The user is redirected to the SP's Assertion Consumer Service (ACS) URL. 40 9. **SAML Response Validation**: The ACS validates the SAML Response. 41 10. **Resource Access Granted**: Access to the initially requested resource is granted. 42 43 ## SAML Request Example 44 45 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: 46 47 ```text 48 GET /secure/ HTTP/1.1 49 Host: shibdemo-sp1.test.edu 50 ... 51 ``` 52 53 The raw SAML Request looks like this: 54 55 ```xml 56 <?xml version="1.0"?> 57 <samlp:AuthnRequest ... 58 </samlp:AuthnRequest> 59 ``` 60 61 Key elements of this request include: 62 63 - **AssertionConsumerServiceURL**: Specifies where the IdP should send the SAML Response post-authentication. 64 - **Destination**: The IdP's address to which the request is sent. 65 - **ProtocolBinding**: Defines the transmission method of SAML protocol messages. 66 - **saml:Issuer**: Identifies the entity that initiated the request. 67 68 Following request generation, the SP responds with a **302 redirect** to the IdP. For the HTTP-Redirect binding, `SAMLRequest` is DEFLATE-compressed, base64-encoded, and URL-encoded in the `Location` query string. `RelayState` is opaque state returned by the IdP; the SP must bind or validate it before using it as a post-login destination to avoid open redirects or state confusion.<sup>[[1]](#references)[[2]](#references)</sup> 69 70 ## SAML Response Example 71 72 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:<sup>[[1]](#references)</sup> 73 74 - **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. 75 - **saml:Assertion**: This part holds information about the user's identity and possibly other attributes. 76 - **saml:Subject**: It specifies the principal subject of all the statements in the assertion. 77 - **saml:StatusCode**: Represents the status of the operation in response to the corresponding request. 78 - **saml:Conditions**: Details conditions like the validity timing of the Assertion and the specified Service Provider. 79 - **saml:AuthnStatement**: Confirms that the IdP authenticated the subject of the Assertion. 80 - **saml:AttributeStatement**: Contains attributes describing the subject of the Assertion. 81 82 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. 83 84 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.<sup>[[1]](#references)</sup> 85 86 ## XML Signatures 87 88 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:<sup>[[1]](#references)</sup> 89 90 ### Basic Structure of XML Signature 91 92 An XML Signature has the following simplified structure; `KeyInfo` is optional, `Object` may repeat, and `SignedInfo` contains one or more `Reference` elements.<sup>[[5]](#references)</sup> 93 94 ```xml 95 <Signature> 96 <SignedInfo> 97 <CanonicalizationMethod /> 98 <SignatureMethod /> 99 <Reference> 100 <Transforms /> 101 <DigestMethod /> 102 <DigestValue /> 103 </Reference> 104 ... 105 </SignedInfo> 106 <SignatureValue /> 107 <KeyInfo /> 108 <Object /> 109 </Signature> 110 ``` 111 112 Each `Reference` element signifies a specific resource being signed, identifiable by the URI attribute. 113 114 ### Types of XML Signatures 115 116 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. 117 118 Example: 119 120 ```xml 121 <samlp:Response ... ID="..." ... > 122 ... 123 <ds:Signature> 124 <ds:SignedInfo> 125 ... 126 <ds:Reference URI="#..."> 127 ... 128 </ds:Reference> 129 </ds:SignedInfo> 130 </ds:Signature> 131 ... 132 </samlp:Response> 133 ``` 134 135 In an enveloped signature, the `ds:Transform` element specifies that it's enveloped through the `enveloped-signature` algorithm. 136 137 2. **Enveloping Signature**: The signed data is stored inside an `Object` element within the `Signature`, and a `Reference` identifies that object.<sup>[[5]](#references)</sup> 138 139 Example: 140 141 ```xml 142 <ds:Signature> 143 <ds:SignedInfo> 144 ... 145 <ds:Reference URI="#..."> 146 ... 147 </ds:Reference> 148 </ds:SignedInfo> 149 <ds:Object Id="signed-object"> 150 <samlp:Response ... ID="..." ... >...</samlp:Response> 151 </ds:Object> 152 </ds:Signature> 153 ``` 154 155 3. **Detached Signature**: The signed content is outside the `Signature` element, either as a sibling in the same XML document or as an external resource identified by the reference URI.<sup>[[5]](#references)</sup> 156 157 Example: 158 159 ```xml 160 <samlp:Response ... ID="..." ... > 161 ... 162 </samlp:Response> 163 <ds:Signature> 164 <ds:SignedInfo> 165 ... 166 <ds:Reference URI="#..."> 167 ... 168 </ds:Reference> 169 </ds:SignedInfo> 170 </ds:Signature> 171 ``` 172 173 SAML implementations most commonly encounter enveloped signatures on the `Response` and/or `Assertion`. Validation must verify both the cryptographic signature and that the application consumes the exact element referenced by `SignedInfo`; merely finding a valid `Signature` somewhere in the document is insufficient. 174 175 ## References 176 177 - [1] [How to test SAML: a methodology](https://epi052.gitlab.io/notes-to-self/blog/2019-03-07-how-to-test-saml-a-methodology/) 178 - [2] [OASIS - SAML V2.0 Technical Overview](https://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-tech-overview-2.0.html) 179 - [3] [RFC 6749 - The OAuth 2.0 Authorization Framework](https://www.rfc-editor.org/rfc/rfc6749) 180 - [4] [OpenID Connect Core 1.0](https://openid.net/specs/openid-connect-core-1_0.html) 181 - [5] [W3C - XML Signature Syntax and Processing Version 1.1](https://www.w3.org/TR/xmldsig-core/)