Understanding SSO to AWS console via SAML 2.0 Part 1: Creating a SAML IdP on AWS using Azure AD

Background:

This a three part guide to understanding and testing out your own SSO solution to AWS console and use a tool to generate temporary credentials via STS.

Part 1: Creating a SAML IdP on AWS using Azure AD

Part 2: Understanding your SAML assertion and STS APIs

Part 3: Creating temporary credentials using SAML assertion using Selenium Chromedriver and Python

To enable SSO to a federated login to AWS console you need either OpenID connect and assume role via Web-identity or via SAML 2.0 from the identity provider. In this post you will be taken on a journey via the SAML 2.0 route.

The following terms will be important to understand:

1. IdP — > Identity provider which stores your user’s identity (usernames, passwords, personal information, etc.) Examples of IdPs and 3rd party IdPs are Microsoft AD, Pingone, Pingfed, Okta, auth0.
2. SSO — > Single sign on, once logged onto an identity provider it will allow you to seamlessly sign on to other services that are integrated to SSO.
3. AWS IAM — > Amazon web services IAM is identity and access management services, that manages users, groups, policies and roles. It also lets you manage Identity providers
4. authN — > Authentication, answers the question: Who am I?
5. authZ — > Authorization, answers the question: What can I do?
6. SAML — > Security assertion markup language, it uses XML as a medium to send authN and authZ information between security systems.
7. urn — > uniform resource name, for describing resources in xml document for the SAML text

SSO Procedure

Trust setup

Before users can start using SSO, your IdP and service provider (AWS) need to trust each other in order to recognize what entities are allowed to login and what the entities are authorized to do. This is called Relying Party Trust. There are many IDPs so for this example we will be describing the scenario of Azure AD integrated Enterprise Application. The Enterprise App is called Amazon Webservices (do not confuse this with AWS) which has a SSO integration using SAML 2.0 leveraging Azure AD as a identity store.

You can use the following step to setup an SSO trust using azure AD:

Step 1: Create an azure AD tenant with a free tier subscription

Step 2: Make sure there is at least one user in Azure Active Directory

Step 3 :Then in the enterprise application sections in the search bar, create an application: Amazon Web Services (AWS)

Step 4: The user access url is the single sign on url as shown below

Step 5: In the single sign on section pick SAML

Step 6: After clicking SAML click the edit option in the first section and click save after verifying that the audience of the SSO SAML is https://signin.aws.amazon.com/saml and then hit save

Step 7: In the user attributes section you want the following claims sent over in the SAML assertion. The following claims have limitations that you can read in the AWS documentation: https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_saml_assertions.html.

The second image with RoleSessionName has the transformation because the UPN (user principal name) by default does not adhere to the RoleSessionName guidelines enforced by AWS so the simplest workaround to get it to work was by using the user given name and user surname joined by underscore.

Step 8: In the next section all you need to do is download the Federation Metadata XML

Step 9: Registering your IDP in AWS, in IAM section of AWS click on identity providers and start to create a Identity provider and make sure to choose SAML. Give the name what ever you want and upload the Federation Metadata XML document that you downloaded in your previous step. After this you will have then created the trust between AWS and your IdP (SSO application in Azure).

Step 10: For managing role retrieval the SSO application for AWS on Azure, you can create a service programatic account that this application will use to fetch SAML based roles. Make the user with the following policy attached:

Step 11: In the provisioning tab make sure it is set to automatic, use the key and secret to retrieve roles as the admin credentials. The clientsecret is the access key and secret token is the secret access key. You can verify a connection test and save.

Step 12: Then make sure provisioning status is turned and then save again. Make sure provisioning status is on and the credentials work!

Step 13: We are now going to jump back into AWS console to create roles for your AD users to be mapped to. We will be creating an admin role and make sure you click on SAML 2.0 Federation for roles. And attach the administrator policy.

Step 14: Verify your role and make sure in your trust relationships you have the trusted entity to be the saml-provider and make sure the condition is set to StringEquals SAML:aud (saml audience url) to https://signin.aws.amazon.com/saml. Wait for some time to sync to azure via the programatic service account previously provisioned.

Step 15: Then in the users and groups section for the basic tier of Azure AD you will only be able to manage users and not groups but you can map the individual users to a role. You should be able to find the roles after waiting for some time for azure to fetch roles using the credentials from the service account you have created above. After the mapping is done your users should then be able to authenticate via SSO link.

Step 16: You can visit [https://docs.microsoft.com/en-us/azure/active-directory/saas-apps/amazon-web-service-tutorial] for much more detailed description on how its setup.

SSO Procedure Detailed Steps

1. You will first attempt to authenticate with your IdP (in our example it will be a Azure Enterprise Application that relies on Azure AD to be our IdP)
2. The IdP will validate the authN credentials of the user
3. If the IdP determines the user a valid entity, it will then proceed to make a SAML assertion passing the different urns required for the SSO configuration. This will send the 3 required urns by AWS to process the user (Role, RoleSessionName, SessionDuration). The IdP will generally send this to you encoded in base64.
4. You will then redirect this assertion as form data to the SAML endpoint on AWS
5. The SAML endpoint will create temporary credentials based on SessionDuration attribute and creates a console login
6. Then the user will be automatically redirected to the console login page

Alice without her friend Bob trying to access the AWS console via SSO

Conclusion

This simple guide will go through on how to setup your own mock SSO using Azure AD but if you want a list of 3rd party SAML providers that have been integrated with AWS as IdPs are with the following link: [ https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_saml_3rd-party.html]

Once you have enabled the trust setup ahead of time, your SAML provider will also map the users/groups to roles and send them along with the SAML assertion which contains the roles that you are authorized to.

The next part (Understanding your SAML assertion and STS APIs) will cover:

1. What happens in more detail from a debugging perspective in terms of network traffic?
2. What is part of your SAML assertion?
3. What services does STS provide you?

Read the next part at: https://medium.com/@tsriharsha/understanding-sso-to-aws-console-via-saml-2-0-442254a73a7