Understanding SSO to AWS console via SAML 2.0 Part 2: Understanding your SAML assertion
Background
I highly recommend all readers to go through part 1: https://medium.com/@tsriharsha/understanding-sso-to-aws-console-via-saml-2-0-558bde48823b
So in the previous post we have enabled SSO for our AWS console via Azure Enterprise App (Amazon Web Services (AWS)) app.
This part of the series will go over how to debug your SAML redirects, unwrapping your SAML assertion and how STS interacts with your SAML 2.0 assertion.
For this tutorial you are going to want:
So far…
You should have an enterprise app that you can find in https://myapps.microsoft.com which will let you seamlessly login to the console after federating with the mapped user.
Your mapping should look similar to following:
Your portal will look similar to below:
After clicking the app link it will go through a few refreshes and redirects to take you to the role selection page or to console depending on if you have more than 1 role or not.
Finding and debugging SAML 2.0 redirects
For this section you will need chrome installed to access developer tools. I will be showing you from the perspective of a mac installation of Chrome browser. You will need the networking section of the tools and I will show you what you should be looking for.
For this you are going to want the app url that you can find in properties of the enterprise app. It will be called User access URL. Also make sure to enable Preserve log in the network log settings because refreshes will remove history and clear the logs.
The SAML 2.0 response form data submitted to https://signin.aws.amazon.com/saml will be a base 64 encoded string so we will dissect it by converting it from base64 to a string. You can use the following python code only utilizing base python libraries.
Lets look at a example of Alice’s SAML assertion.
Three main points to note for the SAML assertion.
First is the Attributes that are being passed on based on the mapping found in the IdP app.
Second is the subject of the SAML request and the audience of this SAML request with conditions on the scope of authentication of the request. As you can see there is a NotBefore and a NotOnOrAfter which is the range when the subject (Alice) of the SAML assertion can be considered a valid authenticated subject. The audience is the SP (service provider) which in our case is AWS.
Third is the validity of this SAML assertion which will link back to the Relying Party Trust that we set up in the first part of the SSO setup. This is essentially the Signature section of the assertion. This section only contains key information in terms of the encryption which is RSA and the hashing algorithm to the encrypted signature which is sha-256.
Another key bit of information is that the response token must be redeemed within 5 minutes of issuance. This is an STS limitation which leads us to our last part which is STS.
Security Token Service
Disclaimer: I am not going to go into great depth of what STS is and how it works outside the scope of SSO with SAML 2.0.
The AWS SAML endpoint will use STS to create a session cookie which contains temporary credentials based on the configuration sent by our claims.
So once the duration runs out your session will expire, forcing you attempt the SSO process again. But still all we have achieved thus far was console access. Thats great for a quick look at the UI but to be a power user you want programatic access but all you have is a federated login user and not a programatic access user. STS is the solution for this again.
If you get the SAML response via network logs in chrome you can run the following AWS cli command. The role arn is the role you wish to assume, the principle arn is the idp provider name, and the saml response is the giant base64 string without the part that says “SAMLResponse:”.
When Alice runs the previous command with the role name S3Master she will receive a response like below. As you can see that the ARN assume is via Alice_Crypto similar to the claim for RoleSessionName we made which was a transformation which joined the givenname with the surname using underscore.
Conclusion
In this part we have manually scavenged network traffic from the IdP portal to fetch the SAMLResponse that gets pushed from IdP redirects to SP (service provider) AWS. We have retrieved the base64 SAML assertion broken it down and understood the claims the IdP sends to the service provider. We have then used that assertion to make create a set of AWS API tokens via STS to retrieve programatic access to AWS APIs.
In the next post we will look at a way of automating this process using:
- Python
- Selenium (Chromedriver)
- Boto3 (interact with AWS API) to fetch credentials
- Click (Command Line Interface building framework written in python)
