Efficiently managing user identities at scale requires new solutions that connect the multiple identity sources that many organizations use today. Customers want to establish a single identity and access strategy across their own apps, 3rd party apps (SaaS), and AWS cloud environments.
Today we announced the next evolution of AWS Single Sign-On, enabling enterprises that use Azure AD to leverage their existing identity store with AWS Single Sign-On. Additionally, automatic synchronization of user identities, and groups, from Azure AD is also supported. Users can now sign into the multiple accounts and applications that make up their AWS environments using their existing Azure AD identity – no need to remember additional usernames and passwords – and they will use the sign-in experience they are familiar with. Additionally, administrators can also focus on managing 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.
Let’s imagine that I am an administrator for an enterprise that already uses Azure AD for user identities and now wants to enable simple and easy use of our AWS environments for my users using their existing identities. I do not want to duplicate my Azure AD group and user membership setup by hand in AWS Single Sign-On, and maintain two identity systems, so I am also going to enable automatic synchronization. My users will sign in to the AWS environments using the experience they are already familiar with in Azure AD. You can read more about enabling single sign-on to applications in Azure AD here. To learn more about managing permissions to AWS accounts and applications, refer to the AWS Single Sign-On User Guide.
Connecting Azure AD as an Identity Source for AWS Single Sign-On
My first step is to connect Azure AD with AWS Single Sign-On. First, I sign into the Azure Portal for my account and navigate to the Azure Active Directory dashboard. From the left-hand navigation panel I then select Enterprise Applications.
Next, I click + New application, and select Non-gallery application. In the Add your own application page that opens, I enter AWS SSO in the Name field – you can use whatever name you like – and click Add. After a few seconds my new application will be created and I am redirected to the settings overview for the application.
This is where I will configure the settings to enable single sign-on and exchange federation metadata between Azure AD and AWS Single Sign-On. I select Single sign-on from the navigation panel and then click the SAML option. From the settings page that then opens, I need to download the Federation Metadata XML file, which is shown in the SAML Signing Certificate panel. This file, which will be named AWS SSO.xml by default, will be used to configure AWS Single Sign-On in the next steps.
Having downloaded the file, I open another browser tab (I leave the Azure AD tab open, as I need to come back to it), and sign into the AWS Single Sign-On Console. From the dashboard home, I click the Enable AWS SSO button. After a few seconds, my account is enabled for single sign-on and I can proceed to configure the connection with Azure AD.
Clicking Settings in the navigation panel, I first set the Identity source by clicking the Change link and selecting External identity provider from the list of options. I now have two things to do. First, I need to download the AWS SSO SAML metadata file using the link on the page – I will need this back in the Azure AD portal. Second, I browse to and select the XML file I downloaded from Azure AD in the Identity provider metadata section.
I click Next: Review, enter CONFIRM in the provided field, and finally click Change identity source to complete the AWS Single Sign-On side of the process.
Returning to the tab I left open to my Azure AD Set up Single Sign-On with SAML settings page, I click the Upload metadata file button at the top of the page, navigate to and select the file I downloaded from the AWS SSO SAML metadata link in the AWS Single Sign-On settings and then, in the Basic SAML Configuration fly-out that opens, click Save. At this point, if I already have a user account in AWS Single Sign-On with a username that matches to a user in Azure AD, I can click the Test button to verify my setup.
Customers with a relatively small number of users may prefer to continue maintaining the user accounts in AWS Single Sign-On rather than rely on automatic provisioning and can stop here, as it is possible to use just the sign-in aspect. We do however recommend enabling automatic provisioning for convenience. New users you add to an Azure AD group automatically get access with no additional action needed, making it convenient for administration and productive for the end user. Users who get removed from a group in Azure AD will automatically lose access to associated permissions in AWS Single Sign-On, a security benefit.
Enabling Automatic Provisioning
Now that my Azure AD is configured for single sign-on for my users to connect using AWS Single Sign-On I’m going to enable automatic provisioning of user accounts. As new accounts are added to my Azure AD, and assigned to the AWS SSO application I created, when those users sign into AWS, a corresponding AWS Single Sign-On user will be created automatically. As an administrator, I do not need to do any work to configure a corresponding account in AWS to map to the Azure AD user.
From the AWS Single Sign-On Console I navigate to Settings and then click the Enable identity synchronization link. This opens a dialog containing the values for the SCIM endpoint and an OAuth bearer Access token (hidden by default). I need both of these values to use in the Azure AD application settings so either make note of both values, or use multiple browser tabs and copy/paste as you go.
Switching back to my Azure AD browser tab and the AWS SSO application, I click Provisioning in the navigation panel and set Provisioning Mode to Automatic. This triggers display of the fields I need to complete with values from the dialog in the AWS Single Sign-On Console. First, I paste the SCIM endpoint value into the Tenant URL field. Then I paste the Access token into the Secret Token field.
I complete the settings by entering a value for Notification Email, and opt in to receive an email when provisioning failures occur, then click the Test Connection button to verify everything is working as expected. Assuming everything is good, I click Save in the page toolbar and then just a couple of small steps remain to configure mapping of attributes and I am done!
Expanding Mappings, I click the Synchronize Azure Active Directory Users to customappsso link (your link may read ‘…to AWS SSO‘). That takes me to a page where I control attribute mappings. In that section I deleted the facsimileTelephoneNumber and mobile attributes as I won’t be using them, and I click on and edit the mailNickname attribute, changing the Source attribute to be objectId. I click Save to return to the Settings screen and I have one more step remaining, to turn on synchronization, which I do by clicking On in Provisioning Status and clicking Save one more time.
Note that the first sync will take longer than subsequent ones, which happen around every 40 minutes. To check progress I can either view the Synchronization Details or the Audit Logs in Azure AD, or in the AWS Single Sign-On Console I can select Users from the navigation panel.
I Configured Single Sign-On, Now What?
Azure AD will now be my single source of truth for my user identities and their assignment into groups, and periodic synchronization will automatically create corresponding user identities in AWS Single Sign-On, enabling my users to sign into their AWS accounts and applications with their Azure AD credentials and experience, and not have to remember an additional username and password. However, as things stand my users will only have access to sign in. To manage permissions in terms of what they can access once signed into AWS, I need to set up permissions in AWS Single Sign-On which I do using the AWS Single Sign-On Console. AWS Single Sign-On uses a concept of permission sets for assignments. A permission set is essentially a standard role definition to which I attach AWS Identity and Access Management (IAM) policies. Once I define a permission set, I then assign a group, or user, to the permission set in a specified account. AWS Single Sign-On then creates the underlying AWS Identity and Access Management (IAM) role in the designated account, including all the right information that grants access to that group or user. You can read more about permissions sets in the AWS Single Sign-On User Guide.
In the screenshots below, you can see the effect of automatic synchronization. In Azure AD I have created three groups, and assigned my user account into two of them (for the sake of this blog post). Switching to the AWS Single Sign-On Console once synchronization completes, I see the three groups have been automatically created, with my user account assigned into the ones I chose.
Using Permission Sets, available from the AWS Accounts and Applications links in the navigation panel, I can associate one or more access control policies (custom policies I have created, or AWS Identity and Access Management (IAM) managed policies), to both groups and users, thus controlling permissions once users sign in. Sign in is accomplished using the familiar Azure AD experience, and users will be able to choose the account(s) and role(s) to assume. Sign in can also be done using the AWS console and CLI. Details on using single sign-on with the version 2 of the AWS Command Line Interface (CLI) is detailed in this blog post.
In this post I showed how you can take advantage of the new AWS Single Sign-On capabilities to to link Azure AD user identity into AWS accounts and applications centrally for single sign-on, and make use of the new automatic provisioning support to reduce complexity when managing and using identities. Administrators can now use a single source of truth for managing their users, and users no longer need to manage an additional identity and password to sign into their AWS accounts and applications.
This next evolution is now available to all users in all AWS Single Sign-On supported regions. You can check the regional availability of AWS Single Sign-On here.