Single Sign-On with AWS and Azure: Integrating AWS Identity with Azure Active Directory

This step-by-step guide explains how to integrate AWS identity with Azure AD. Such integration would help administrators to focus on managing single sign-on, that is, a single source of truth for user identities in Azure AD while having the convenience of configuring access to all AWS accounts and apps centrally.

Author
Recent Posts

Mohamed Wali

Mohamed is a cloud infrastructure expert with experience in engineering and implementation in AWS and Azure. He currently works as a Cloud Infrastructure Architect at Amazon Web Services.

Enable AWS Single Sign-On

In the AWS master account console, search for AWS Single Sign-On (SSO) and open it. You are redirected to a new console from which you can enable AWS SSO by clicking on Enable AWS SSO.

Enabling AWS SSO with Azure AD

Once enabled, you can navigate to AWS SSO settings, where you can change the identity source.

Changing the identity source

Choose the External identity provider option and then click Download metadata file.

Create an enterprise application in Azure AD

The next step is to create an enterprise application in Azure AD for AWS Single Sign-On. To do so, perform the following steps:

Navigate to the Azure portal and search for Enterprise Applications.
On the All Applications blade, click New application.
Search for AWS Single Sign-on.
Click it and specify a name for the application in the new blade that is opened.
Click Create.

Creating AWS Single Sign on Enterprise Application in Azure AD

Once the application is created, navigate to Single sign-on and choose SAML.

Selecting SAML as the SSO method

Then, click Upload metadata file to upload the metadata file that you downloaded earlier.

Uploading the AWS SSO SAML metadata file

Once it is uploaded, save the automatically populated SAML configuration.

Saving the SAML configuration imported from the AWS SSO SAML metadata file

Once saved, scroll down to the SAML Signing Certificate section and download Federation Metadata XML.

Downloading the Enterprise Application Federation Metadata XML file

Configure Auto-Provisioning

Switch back to the last AWS SSO page we had opened, and upload the Federation Metadata XML.

Uploading the Enterprise Application Federation Metadata XML file

Once uploaded, click Next: Review, which will take you to another page where you can review the consequences of your requested identity source change.

Once reviewed, type ACCEPT and click Change identity source.

Confirming the identity source change

Once the change is made, go back to the SSO settings and click Enable automatic provisioning to begin using automatic provisioning.

Enabling AWS SSO usergroups automatic provisioning

A new page will pop up that includes an SCIM endpoint and an access token. Copy these two values and switch back to the AWS enterprise application we created earlier in Azure AD.

Navigate to Provisioning and click Get Started.

Enabling the Enterprise Application usergroups provisioning

Change the provisioning mode to Automatic and pass the value of the SCIM endpoint in the Tenant URL and the access token in the Secret Token.

Configuring the Enterprise Application usergroups provisioning

Click Test Connection to verify that you can connect to AWS with these credentials.

Once the test succeeds, click Save and change Provisioning Status to On.

Navigate back to the AWS Enterprise Application Users and groups and select the users and/or groups you would like to grant permissions to AWS.

Granting Azure AD users permissions over the AWS SSO Enterprise Application

Once the users/groups have been added, navigate to Provisioning to check the status of user sync from Azure AD to AWS.

Checking the provisioning cycle status

It looks like the two added users have been synchronized to AWS. To verify this, we will switch back to the AWS SSO Users section.

Checking synced users in AWS SSO

Map Azure AD users and groups to AWS permissions

From the AWS SSO console, navigate to AWS accounts > Permission sets and click Create permission set.

You will be redirected to a new page from which you can start the process of creating a permission set.

First, specify whether you would like to use an existing job function policy or create a custom one. In this article, we will use an existing one.
Then, you can select the existing policy. We will use ViewOnlyAccess to test it.

Once created, switch back to AWS accounts > AWS organization and select the projects to which you would like to grant users the permission set you just created.

Afterward, click Assign users.

Selecting an AWS account to assign users to

Select the users/groups you would like to map to the permission set over the previously selected project.

Selecting users to be assigned to the AWS account

Select the permission set.

Selecting the permission set to be assigned to the users who would access the AWS account

Then, click Finish and start testing.

Testing user access

There are a couple of ways to test user access:

Subscribe to 4sysops newsletter!

Via myapps.microsoft.com, you can click the AWS Single Sign-on application. This redirects you to the AWS SSO page, from which you can select the account and the permission set (if you have more than one assigned to you), and set whether you want to access it via the management console or the command line.

Logging in to the AWS account from the AWS SSO portal

Via the user portal URL in AWS SSO settings, which would directly open the AWS SSO page shown previously.If you open the AWS management console, you will be able to view all the resources; however, if you try to create any resource, for example, an EC2 instance, you will get an error that you're not authorized.