Demystifying AWS SSO/Azure AD Integration to multiple AWS Accounts

Amazon Web Service is the leading public cloud provider in the world. AWS Identity and Access Management (IAM) is the core of security authentication and authorization service that manages grants to AWS services and resources. The IAM, is a complex and deep identity ecosystem that helps us in many identity security use cases. It has a unique component called Amazon Resource Name (ARN) which represents any resource within AWS cloud. The IAM data structure described in json, which is easy to understand and manipulate even for complex scenarios.

The whole IAM service is a combination of Users, Groups, Roles, Policies & identity providers. Previously all above objects were stored within the AWS ecosystem & authentication and authorization managed by IAM console. This is a nice solution for few AWS accounts or organizations that don’t worry about managing a single truth for their identity. If the organization needs to manage their identity from one single directory, the IAM’s capabilities will not be enough to serve the purpose.

AWS Organization and AWS Single Sign-Om (SSO)

In 2017 Amazon introduced AWS Organization to manage multiple accounts in one place and enforce policies across organization wide. Besides that they launched AWS Single Sign On Service on top of the AWS Organization that has Cloud SSO capabilities allowing organization’s bring existing identity management solutions. AWS SSO enabled Security Assertion Markup Language (SAML) 2.0 based identity integration for central managed identity and access service. The biggest advantage of SSO service is central identity governance & access management. You don’t need to reinvent the wheel among many accounts. AWS SSO is the place for enforcing password policies, session timeout, MFA enforcements etc. The SSO service supports three types of integrations.

1. AWS SSO
   AWS will manage all of users, groups, credentials, MFA, policies & roles assignments in AWS SSO. External applications can be integrated via SAML 2.0 where users always need sign-in to AWS portal to access AWS accounts and external applications.
2. Active Directory
   AWS will provide a managed hosted Microsoft Active directory or AD connector to connect an existing AD to AWS SSO. In this case users, groups & credentials are managed by the active directory. External applications can be integrated via SAML 2.0 where users always need to sign-in to AWS portal to access AWS accounts and external applications.
3. External Identity Provider
   AWS will provide the federation between external identity provider (Idp) solution. AWS will map users & groups into AWS users and groups but users should do authentication by sign-in organization’s identity portal. The SAML integration will take care of brokering authentication tokens from AWS SSO-Idp-AWS SSO. Therefore all users, groups, credentials and MFA authentication are managed by an external identity provider (IdP) and users should sign in in the Idp portal to access AWS accounts and applications.

Which Method is Best for Multiple AWS Accounts Environment?

The main problem here is repeating the same configuration and managing the complexity of the solution. You may see the Managed Active Directory would be easy since the Managed Active Directory feature. But this solution introduces many operational complexity when integrating with on-premise AD. On another hand, if you have a bunch of AWS accounts, the AD integration configuration should repeat among them many times.

Then, what about an external Idp ? When it comes to external Idp, it is not only traditional AD but also any SAML 2.0 based Idp is supported. If you still need to manage everything from your on-premise AD but without much complexity, using the Azure AD with AWS SSO would be the nice & balance solution. Azure AD supports native integration to traditional AD and supports SAML Idp integration with AWS SSO.

Azure AD Integration in to AWS SSO

The integration is pretty straight forward as mentioned in AWS docs. Make exchange of SMAL metadata between Azure AD (Idp) and AWS IAM Identity provider (I will discuss more about configuration in another story which not the scope here). In Azure AD you need to use Amazon Web Service Enterprise Application and download the SAML metadata from SSO configuration. In AWS IAM dashboard select identity provider and then create provider with SAML by uploading the SAML metadata from Azure AD Enterprise application.

This is the simplest way to integrate Azure AD and the user provisioning can be done adding groups & users in the Enterprise application. Further, you can define permission groups here and map them to grant access in AWS IAM. This is quite simple configuration. But here the hidden problem in this solution. You need to do the same configuration over and over among all the AWS accounts. This hasn’t mentioned in the AWS documentation clearly. Therefore engineers will mislead and do this tedious repeatable configuration or may be find some automation way to do the same. The solution works as expected but operationally it is fragile.

I was falling to the same trouble and finally figured it out the best way to overcome this. Instead of choosing IAM Identity Provider & Azure AD Enterprise Application, you need to take below steps.

This is one time configuration even you have thousands of AWS accounts in your AWS organization.

1. Create non gallery Enterprise Application in Azure AD and enable SSO
2. Download the SSO metadata file
3. Go to AWS SSO
4. Select Choose your identity source
5. Select option 3 External identity provider
6. Upload Azure AD SSO SAML metadata file to IdP SAML metadata
7. Download AWS SSO SAMl metadata from AWS SSO SAML metadata
8. Upload the AWS SSO metadata file to Azure AD non gallery app SAML configuration.

Azure AD non gallery application and AWS SSO both support SCIM protocol for automation user provisioning. Therefore you should not add users and groups in the Azure AD application but in the provisioning. Once SCIM configuration is done, you must add users or groups from provisioning. The Azure AD app will synchronize all the users and groups to AWS SSO now. The SCIM configuration is easy and straightforward as explained here.
https://docs.microsoft.com/en-us/azure/active-directory/saas-apps/amazon-web-service-tutorial

AWS SSO Permission Sets

This is a one of critical part in the AWS SSO which is used to provision permissions. Permission sets are nothing but the kind of IAM role that you need to create from the scratch. In AWS SSO there are no any IAM roles or policies. Yes correct, you heard it!. The only possible way is using permission sets. You must create permission sets for each and every access granted through AWS SSO.

You can create a permission set from AWS SSO dashboard, AWS account and the Permission sets. Now you can select AWS accounts one by one and grant Permission sets to users or groups where synced from Azure AD.

Conclusion

AWS became musch mature and allowed to leverage it’s strong IAM with other strong Idp solutions like Microsoft Azure AD. I have created this story as an overview of all possible options in AWS SSO integration.

There are few options that provide the same functionality in different ways in AWS SSO. When it comes to managing hundreds of AWS Accounts from a single source of external identity, I found this is the most optimum way to manage.

My intention here is to discuss the solution rather than explaining how to do it. Therefore I’ll come up with another story for configurations & permission mapping too. I would happy to hear your experience & opinion in this regard. ☁️ 🔑 ☁️