5 min read

Enabling SSO for AWS with Azure Entra ID: A Step-by-Step Guide

In today’s digital era, Single Sign-On (SSO) is an essential feature for secure access to resources across other platforms. Implementing SSO between platforms like AWS and Azure Entra ID (previously it was named as Azure Active Directory) enables the organization users to access AWS resources using their Azure credentials.

In this article, we will configure an AWS account as an SSO application within Microsoft Entra ID.

What we would need to perform this activity

• An Azure Account with a valid subscription.
• An AWS Account with admin access to configure roles and identity providers.

What we are aiming to achieve?

Let`s imagine a scenario where students from one school can access resources (like books) from another school without enrolling there directly.

This setup is similar: we will create a trust relationship between AWS and Azure so that users in Azure can access AWS resources without being added to AWS’s IAM user list.

Overview of Steps

To achieve this integration, we’ll go through these main steps:

1. Set Up AWS as an Enterprise Application in Microsoft Entra ID
2. Enable SSO with SAML in Azure
3. Create Identity Provider in AWS and Upload SAML XML
4. Create Specific AWS Roles for Azure Users
5. Provision AWS Application in Azure with Automated Access Control
   

Step 1: Set Up AWS as an Enterprise Application in Azure Entra ID

1. Log into the Azure Portal and go to Azure Active Directory > Enterprise applications.
2. Create an AWS Enterprise Application:
   • Click New application
   • AWS would be automatically listed under cloud platforms.
   • If its not listed, then click on “Create your own application” and search for AWS
   • Select the AWS (AWS Single-Account Access)
   • Enter a name, like “AWS SSO,” (I kept name as “partho-aws-account”)
   • Click Create to generate the application in Azure.
3. Configure Basic SAML SSO Settings:
   • Once the application is created, go to Single sign-on and choose SAML.
   • Keep the default values

• Download the Federation Metadata XML file from Azure under the SAML Signing Certificate section. This XML contains the SAML configurations that AWS will use to trust Azure as an Identity Provider.

Step 2: Enable SSO on the Azure AWS Application

With the application set up, the next step is to enable SSO on the application:

1. Ensure Unique Identifier:
   • Confirm that the Identifier is unique and not shared with any other application in your Azure AD instance.
2. Save Settings:
   • Save these settings so Azure Entra ID can recognize the AWS account through SAML.

Step 3: Set Up AWS Identity Provider with Azure SAML Metadata

Now, let’s configure AWS to recognize Azure as a trusted SAML provider.

1. Log in to the AWS Console with an admin account.
2. Navigate to IAM > Identity Providers:
   • Click Add Provider, select SAML, and give it a name (e.g., “AzureEntra_SAML”).
   • Upload the XML file downloaded from Azure, which provides AWS the necessary information about your Azure configuration.
3. Save the SAML Provider:
   • This step completes the SAML trust between AWS and Azure Entra ID, allowing Azure to act as the Identity Provider for AWS.
4. This makes both Azure and AWS connected through SAML authentication.

Now, to do the test, if the Entra user can access AWS resources using their entra ID. We have to create a role in AWS and assign that role to a user in Azure. Let`s see that in action.

Step 4: Create Specific AWS IAM Roles for Azure Users

With trust established, now set up AWS roles that Azure users will assume based on their permissions.

1. Create Two Roles in AWS:
   • One role for Full EC2 Access and another for Full S3 Access.
2. Role Setup:
   • When creating each role, select SAML 2.0 Federation as the trusted entity.
   • Choose the Identity Provider you created (e.g., “AzureEntra_SAML”).
   • Rest, assigning the appropreate policy remain as usual
   • Attach policies to each role (e.g., AmazonEC2FullAccess for the EC2 role and AmazonS3FullAccess for the S3 role).
   • Name the roles appropriately, such as “AzureEntra_EC2FullAccess” and “AzureEntra_S3FullAccess.”

Step 5: Provision the AWS Application in Azure Entra ID

This step allows the azure to identify the roles that are created into the AWS, and for that we need to enable an automated provisioning. But, for that we need a service account who needs to list all the AWS Roles.

Provisioning allows Azure to manage AWS role assignments for users automatically.

1. Create a Service Account in AWS: (Its like a normal IAM user with policy attached to list only the IAM Roles)
   • Create an IAM user in AWS with permissions to list roles.
   • Attach an IAM policy like IAMReadOnlyAccess to allow Azure to view IAM role information.
   • Generate Access Key ID and Secret Access Key for this user and note these credentials.

1. Configure Provisioning in Azure:
   • Go to Azure Active Directory > Enterprise applications, open the AWS SSO application, and go to Provisioning.
   • Set the Provisioning mode to Automatic.
   • Under Admin Credentials, add the Access Key ID and Secret Access Key for the service account.
   • Save your settings to enable Azure to sync users and groups to AWS automatically.

Step 6: Assign Azure Users to AWS Roles

Finally, add users or groups in Azure who need AWS access.

Example : In our Azure we have more than 500 users, but only few users are assigned to perfrom some actions on aws, so we need to add those users on the enterprise application, like this.

1. Assign Users to AWS Application in Azure:
   • Go to AWS SSO Application > Users & Groups in Azure.
   • Click Add User/Group, select the users/groups from Azure Entra ID, and map each to their designated AWS roles (e.g., EC2 or S3 access roles).

Step 7: Test the Configuration

To verify everything is set up correctly, perform these steps:

1. Go to myapps.microsoft.com and log in with an Azure Entra ID account.
2. You should see AWS as an available application. Click the icon to access AWS.
3. You’ll be logged into AWS with the appropriate permissions, based on the role mappings.

This is the way, we enable SSO to Entra for a single point for authentication for any application that an organization need. We follow similar approach to enable SSO for Jenkins as well.