If you are using Azure AD as your main Identity Provider (IDP), then you know that you can integrate/federate lots of cloud apps with it. This not only gives you better control over cloud app usage, but also allows users to use these apps with a single login (exact details depend on the app). In this blog post I will demo how you can configure AWS to use your Azure AD identities for single Sign-On.
Step 1 – Basic Setup
Login to AWS with an account that has appropriate permissions. Then navigate to the “AWS SSO Console”. If you did not enable AWS SSO yet, you can enable it with just 1 click.
Once AWS SSO is enabled, go to step 1 to choose the identity source for AWS. By default this is AWS SSO, but we will change this to Azure AD.
Now click “Change” in the “Identity Source” section.
Because I want to integrate AWS with Azure AD, I select “External Identity Provider”. To make the integration configuration simple, I download the metadata file and also show the values to better understand the needed settings I need to make in Azure AD. This information is needed in Azure AD later to complete the configuration.
After downloading the metadata file, I now switch to Azure AD and add a new Enterprise Application. I search for “aws” and select “AWS Single Sign-on”.
As you can see from the icons, this integration not only allows federation between the two, but also the provisioning of accounts. We’ll see later what this exactly means. For now just give the application a name (e.g. “AWS Single sign-on)”and then select the newly registered enterprise application from the enterprise applications list to start the configuration. First I go to the “Single sign-on” section and select “SAML”.
From here I can now upload the metadata file I downloaded earlier from AWS. The upload should populate and automatically open the “Basic SAML configuration” section. In my case, only the “Entity Id” and the “Reply URL” was populated, but the “Sign on URL” was still empty. I had to add the value manually (the value was showed earlier in the AWS portal).
Step 2 in the configuration process – the “User Attributes & Claims” section – will not be touched now. I will come back to this in a follow-up post.
Attributes and claims will be covered in a follow-up post.
Instead, let’s go directly to step 3 and download the federation metadata XML file that will be imported in the AWS SSO console later. It contains the configuration details that AWS needs to understand about Azure AD.
Back in the AWS SSO Console, I now add the medatada file from Azure AD. After uploading I can complete the Identity provider change.
Back in the AWS SSO Console, you can now see that the Identity Provider has been changed. Also have a look at the SAML details under “Authentication”.
The 2 platform now know each other and understand how to communicate together. The configuration is not yet done, but this ends the basic setup.
Step 2 – Automatically provision Users and Groups
Before we can use SSO we also need user and group accounts in AWS to assign proper permissions in the platform. These accounts can be created manually, but because the platform supports SCIM (System for cross-platform identity management), I will provision the needed accounts automatically from Azure AD. To start the process, I will first create two groups in Azure AD and add users to the groups as needed. I will create one group that I will use to assign full AWS permissions and another one for view-only permissions. Both groups have 1 member – a user account.
Back in the Azure AD Enterprise Application I add the 2 groups to the app.
Now I go to “Provisioning” and click on “Get started”.
I now change the provisioning mode to “Automatic” and need to add the proper admin credentials to provision the groups and users in AWS. I will get those credentials from the AWS portal in a bit.
Back in the AWS SSO Console I need to enable automatic provisioning. If I do that, I will automatically get the credentials for the provisioning configuration (SCIM endpoint and access token).
After adding the 2 values to the Azure AD Enterprise App Provisioning, you can now test the connection. If the connection is successful, you can save the settings.
Once saved, the configuration is extended and you can configure specific mappings that allow you to bring over specific property values from the Azure AD users/groups to AWS. For now I will leave this untouched.
Mappings will be covered in a follow-up post.
Back in the “Provisioning” section, I now enable the automatic provisioning. Currently the default provisioning interval is set to 40 minutes. So after 40 minutes the groups and group members that I added earlier to the Enterprise Application should be synced over to AWS.
Refresh the page from time to time until the provisioning results are shown. A provisioning log is also available to get more insights into the full process. If urgent synchronization of user accounts is needed, you can use “Provision on demand” to synchronize specific user accounts immediately.
It seems that users and groups have now been synced to AWS. They should now be visible in the AWS SSO Console. But remember: We only synced users and groups, we did not yet assign specific permissions yet. This will be done in the next step.
Now I am ready to test the SSO functionality directly from the Azure AD Enterprise App.Switch back to the app, select “Single sign-on” and use the “Test” button. Depending on the account you are currently logged in, you can either use that currently signed-in user or any other user that now exists in AWS.
Theprocess should work and you should see your current permissions. Because we did not yet assign those, the portal is just empty. But this already proves that SSO worked perfectly so far.
Step 3 – Assign Permissions
There are multiple ways to assign permissions in AWS. I will use one simple approach that is based on the 2 groups I created and synced earlier. The goal ist to assign permissions in AWS based on the membership of one of the 2 groups. Back in the AWS SSO Console I will now assign permissions to the 2 groups – for that I click on my AWS account (I only have 1) and then assign my groups to the account.
During the assignment process, I also need to assign permissions to the groups. This can be done with permission sets. In case no permission sets exist yet, they must be created first. In my scenario I will create 2 permission sets: One with full admin permissions in AWS and one with view-only permissions. The 2 sets will be assigned to the appropriate groups.
Repeat this step for all permissions you need. After all permission sets have been created and assigned to the groups, and those groups have been assigned to the AWS account you are ready to go. The end result should look like this.
That finishes the basic permissions configuration with automatic provisioning. Let’s now test the setup end-to-end.
Step 4 – Test the solution
If a user logs in with his/her Azure AD account, the “AWS Single Sign-On” application should be visible on the “My Apps” page (myapplications.microsoft.com).
If I start the app from here, SSO should work perfectly and the result should now look something like shown in the screenshot below (depending on the permission set the account has been assigned in AWS). Click on the AWS Account and select “Management Console” for the appropriate permission set. This then brings you to the management console without any additional login.
Done! So this seems to work. In the follow-up post I will explain some more advanced configurations and demonstrate what you can do to optimize the integration!
As mentioned in the post, I will soon create a follow-up post that contains more configuration options for the integration. So stay tuned for part 2!
Enjoy!
Cheers, Marcel
