SAML Basics
- Do you work in a cybersecurity company? Do you want to see your company advertised in HackTricks? or do you want to have access to the latest version of the PEASS or download HackTricks in PDF? Check the SUBSCRIPTION PLANS!
Security Assertion Markup Language (SAML) is an open standard that allows identity providers (IdP) to pass authorization credentials to service providers (SP). What that jargon means is that you can use one set of credentials to log into many different websites. It’s much simpler to manage one login per user than it is to manage separate logins to email, customer relationship management (CRM) software, Active Directory, etc.
SAML transactions use Extensible Markup Language (XML) for standardized communications between the identity provider and service providers. SAML is the link between the authentication of a user’s identity and the authorization to use a service. (From here)
OAuth is a slightly newer standard that was co-developed by Google and Twitter to enable streamlined internet logins. OAuth uses a similar methodology as SAML to share login information. SAML provides more control to enterprises to keep their SSO logins more secure, whereas OAuth is better on mobile and uses JSON.

saml-flow
- 1.Step 1 - We try to access some protected resource
- 2.Step 2 - The server where that resource resides (Service Provider) doesn’t know us, so it generates a SAML Request to be sent to the Identity Provider. This would be like showing up to Germany without our passport and getting sent back to the US to get our passport before being able to get into the country.
- 3.Step 3 - After generating the SAML Request, the SP redirects us to the IdP. Note: The SAML Request passes through our browser on the way to the IdP.
- 4.Step 4 - The IdP receives the SAML Request
- 5.Step 4a (not pictured) - The IdP provides some means of authentication; a login form or something similar.
- 6.Step 4b (not pictured) - The IdP validates us as a legitimate user that should be allowed to access the resource included as part of the SAML Request
- 7.Step 5 - The IdP creates a SAML Response. The SAML Response contains the SAML Assertions necessary for the SP. The Assertion usually includes the following information at a minimum: Indication that the Assertion is from the correct IdP, a NameID attribute specifying who the user is, and a digital signature. The SAML Response also passes through our browser.
- 8.Step 6 - The IdP redirects us to the SP’s Assertion Consumer Service (ACS) URL. The ACS is simply the URL on which the SP expects to receive SAML assertions.
- 9.Step 7 - The ACS validates the SAML Response.
- 10.Step 8 - We are allowed to access the resource we originally requested.
Let’s take a closer look at steps 2 and 3 outlined above. We’ll make a request to the example Service Provider for the resource located at https://shibdemo-sp1.test.edu/secure/, which as its name implies, is content that requires us to be authenticated to view.
shibdemo-sp1.test.edu is a local virtualized instance of an IdP and SP for testing, not an actual site
GET /secure/ HTTP/1.1
Host: shibdemo-sp1.test.edu
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:65.0) Gecko/20100101 Firefox/65.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: https://shibdemo-sp1.test.edu/
Connection: close
Upgrade-Insecure-Requests: 1
The SP generates a SAML Request because we’re not authenticated. We can see the raw SAML Request below.
<?xml version="1.0"?>
<samlp:AuthnRequest
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
AssertionConsumerServiceURL="https://shibdemo-sp1.test.edu/Shibboleth.sso/SAML2/POST"
Destination="https://shibdemo-idp.test.edu/idp/profile/SAML2/Redirect/SSO"
ID="_cdae718238ba9c207a35cc7c70b046a0"
IssueInstant="2019-03-12T20:54:58Z"
ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
Version="2.0">
<saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">https://shibdemo-sp1.test.edu/shibboleth</saml:Issuer>
<samlp:NameIDPolicy AllowCreate="1"/>
</samlp:AuthnRequest>
- AssertionConsumerServiceURL: Identifies where the IdP should send the SAML Response to after authentication
- Destination: Indicates the address to which the request should be sent (IdP)
- ProtocolBinding: Typically accompanies the AssertionConsumerServiceURL attribute; defines the mechanism by which SAML protocol messages will be transmitted
- saml:Issuer: Identifies the entity that generated the request message
We’ve outlined the more pertinent elements of the request above, but details about any of the other elements can be viewed in the core specification. The request above goes something like this: “Hey, please authenticate the user that sent this message to you and then have that same user hit me up when you two are done”.
With the SAML Request created, the SP now replies to our GET request for
/secure/
with a 302 redirect. The 302 directs our browser to head over to the IdP. The SAML Request is encoded into the HTTP response’s Location header as part of the 302.HTTP/1.1 302 Found
Date: Tue, 12 Mar 2019 20:54:58 GMT
Server: Apache/2.2.3 (CentOS)
Expires: Wed, 01 Jan 1997 12:00:00 GMT
Cache-Control: private,no-store,no-cache,max-age=0
Location: 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
Content-Length: 897
Connection: close
Content-Type: text/html; charset=iso-8859-1