Being part of Mismo Systems, I am fortunate enough to get to work on a diverse set of projects. Few technologies that we see deployed often are Microsoft 365 and EC2, S3 on AWS. Microsoft 365 is growing in stature in the Enterprise space when it comes to Identity and Single Sign-On. Microsoft has worked hard to make it ridiculously simple to integrate with SaaS, Public Clouds, or any other application. Microsoft 365 comes pre-packaged with a free version of Azure AD in the backend, which means you do not have to worry about setting up any major infrastructure if you want to dabble your feet into the world of enterprise SSO. Recently while working on a project I was tasked with setting up SSO between Azure AD and AWS and I thought why not share the knowledge I gathered while working on this with you by writing this blog. Now, before we go ahead and set up the Azure AD SSO for AWS, let’s first take a quick dip into the world of SSO.

Single sign-on (SSO) is an authentication scheme that allows a user to log in with a single identity to any of several related, yet independent, software systems. It is a property of identity and access management (IAM) that enables users to securely authenticate with multiple applications and websites by logging in only once—with just one set of credentials (username and password). With SSO, the application or website that the user is trying to access relies on a trusted third party to verify that users are who they say they are.

Single sign-on provides a giant leap forward in how users sign in and use applications. Single sign-on based authentication systems are often called “modern authentication”. Modern authentication and single sign-on fall into a category of computing called Identity and Access Management (IAM). Web applications are incredibly popular. Web apps are hosted by various companies and made available as a service. Some popular examples of web apps include Microsoft 365, GitHub, and Salesforce, and there are thousands of others. People access web apps using a web browser on their computer. Single sign-on makes it possible for people to navigate between the various web apps without having to sign in multiple times.

Traditionally, companies used on-prem federation services to enable users/applications to connect without worrying about safety threats to overcome this challenge. In order to set up this mechanism companies require ADFS (Active Directory Federation Services. ADFS provided a means for managing online identities and providing single sign-on capabilities.

List of requirements to set up ADFS federation in the traditional environment are listed below:

• ADFS server with High availability solution (Active & Passive)
• WAP or ADFS Proxy server for external expose
• Public CA – Certificate
• Domain controller server

Some of the challenges with traditional federation setup are:

• High availability & Server Maintenance – Administration
• Billing cost for hardware, license and certificate management

A solution for the above scenario is to use Azure AD with Enterprise application SSO supported application with centralized user management setup. When you integrate Amazon Web Services (AWS) with Azure AD, you can:

• Control in Azure AD who has access to Amazon Web Services (AWS)
• Enable your users to be automatically signed-in to Amazon Web Services (AWS) with their Azure AD accounts
• Manage your accounts in one central location – the Azure portal

Choosing a single sign-on method

There are several ways to configure an application for single sign-on. Choosing a single sign-on method depends on how the application is configured for authentication.

• Cloud applications can use OpenID Connect, OAuth, SAML, password-based, linked, or disabled methods for single sign-on
• On-premises applications can use password-based, Integrated Windows Authentication, header-based, linked, or disabled methods for single sign-on. The on-premises choices work when applications are configured for Application Proxy

This flowchart helps you decide which single sign-on method is best for your situation:

Since we are going to implement SSO between Azure AD and AWS, I will only talk about the former, i.e. Cloud application. For this blog, we look at how to set up SSO using SAML.

SAML

SAML stands for Security Assertion Markup Language. It is an XML-based open-standard for transferring identity data between two parties: an identity provider (IdP) and a service provider (SP).

• Identity Provider — Performs authentication and passes the user’s identity and authorization level to the service provider
• Service Provider — Trusts the identity provider and authorizes the given user to access the requested resource

In our scenario, the identity provider would be Azure AD, (which itself uses Auth0 to authenticate users). The service provider would be AWS. The employee signs into the “My Apps” dashboard with Auth0. They click on the AWS icon, and AWS recognizes that the user wants to log in via SAML. AWS sends the employee back to Auth0 with a SAML Request that asks Auth0 to authenticate the user. Since the employee has already authenticated with Auth0, Auth0 verifies the session and sends the user back to AWS with a SAML Response. AWS checks this response, and if it looks good, the employee is granted access!

Benefits of SAML Authentication

• Improved User Experience — Users only need to sign in one time to access multiple service providers. This allows for a faster authentication process and less expectation of the user to remember multiple login credentials for every application. In the example above, that user could have clicked on any of the other icons in their dashboard and been promptly logged in without ever having to enter more credentials!
• Increased Security — SAML provides a single point of authentication, which happens at a secure identity provider. Then, SAML transfers the identity information to the service providers. This form of authentication ensures that credentials are only sent to the IdP directly
• Loose Coupling of Directories — SAML doesn’t require user information to be maintained and synchronized between directories
• Reduced Costs for Service Providers — With SAML, you don’t have to maintain account information across multiple services. The identity provider bears this burden

Azure & AWS – Why use both?

There are two main reasons why an organization would want to use multiple clouds: To leverage the strengths of each cloud and to improve availability. Large organizations are selecting different services or features from different providers as part of an overall multi-cloud strategy. This allows them to optimize resources and budgets, as some environments are better suited than others for particular tasks.

In my specific scenario, the company was already using AWS. Once it was decided that they would migrate their workplace services from G Suite to Microsoft 365, we had to go ahead and implement a way for the two technologies to be connected to each other to provide users with a seamless experience. But there are other examples as well where companies willingly go ahead and use both Azure and AWS to manage their cloud infrastructure.

There are specific reasons why an organization would want to use both AWS and Azure together. A few general-use cases for multi-cloud environments include:

• Site replication and disaster recovery
• On-ramping and off-ramping data
• Load balancing across different clouds
• Cloud switching to take advantage of cost structures
• Keeping development and production environments separate

Such scenarios warrant the use SSO as users only need to remember the credentials for one environment rather than having to remember a slew of different passwords.

Now that we have covered some basics of the SSO & SAML, lets go ahead and start setting up SSO between Azure AD and AWS. Before we start, there are a few pre-requisites that we need to know of which are as follows:

• An Azure AD subscription
• An AWS single sign-on (SSO) enabled subscription

Adding Amazon Web Services (AWS) from the gallery

To configure the integration of Amazon Web Services (AWS) into Azure AD, we need to add Amazon Web Services (AWS) from the gallery to our list of managed SaaS apps. The steps are as follows:

• Sign in to the Azure portal using a work or school account
• In the Azure portal, search for and select Azure Active Directory
• Within the Azure Active Directory overview menu, choose Enterprise Applications > All applications
• Select New application to add an application

In the Add from the gallery section, type Amazon Web Services (AWS) in the search box

• Select Amazon Web Services (AWS) from results panel and then add the app. We wait a few seconds while the app is added to our tenant

Once the app is added successfully, it opens a new app blade where we can start configuring SSO.

Configure Azure AD SSO

• In the Amazon Web Services (AWS) application integration page, select single sign-on in Manage section and click on SAML

• In Save Single Sign On Setting prompt click on “No, I’ll save it later”

• On the Set up single sign-on with SAML page, in the SAML Signing Certificate (Step 3) dialog box, click on Download to save a copy of the federation metadata XML as shown:

Now we move to the AWS console to upload this federation metadata XML and add Azure AD as an identity provider.

Configure Amazon Web Services (AWS) SSO

• In a different browser window, we sign-on to our AWS company site as an administrator
• In the AWS Management Console, type IAM in the find services field, and click IAM

• Select Identity Providers > Create Provider

• On the Configure Provider page, perform the following steps:
• In Provider Type chose SAML
• In Provider Name, type AzureAD (The name can be anything, I have added Azure AD to simplify things. You can add whatever name you like)
• In the Metadata Document, choose the federation metadata XML file you downloaded in the step above and click on Next Steps

• Click Create to finish the process

• Now select Roles > Create role

• On the Create role page, perform the following steps:
• Under Select type of trusted entity, select SAML 2.0 federation
• Under Choose a SAML 2.0 Provider, select the SAML provider you created previously (AzureAD or whatever name you choose in the step above)
• Select Allow programmatic and AWS Management Console access
• Select Next: Permissions

• On the Attach permissions policies dialog box, attach the appropriate policy, per your requirements. I chose the AdministratorAccess role

• On the Review dialog box, perform the following steps:
• In Role name, enter your role name
• In Role description, enter the description
• Select Create role
• Create as many roles as needed, and map them to the identity provider

• Now, we need to create a user on AWS with the ReadRoles permissions and add it to Azure Azure AD so that we can grant our Azure AD users the roles we created in the step above. To do that, we forst need to create a ReadRoles policy in AWS IAM. In the IAM section, select Policies and click Create Policies

• In the Visual Editor on Create Policy page, do the following:
• In Services, choose IAM
• In Actions, choose ListRoles
• Click Review Policy

• Click Create Policy

• Now we create a new user account in the AWS IAM service. In the AWS IAM console, select Users and click on Add User

• In the Add user section:
• Enter the user name as AzureADRoleManager
• For the access type, select Programmatic access. This way, the user can invoke the APIs and fetch the roles from the AWS account
• Select Next Permissions

• On the Set Permissions page, select the policy we created above

• On the Review page, click Create User and download the user credentials of a user

Configure AWS Role Provisioning in Azure AD

• In the Azure AD management portal, in the AWS app, go to Provisioning and click on Get Started
• In the Provisioning Mode, select Automatic and enter the access key and secret in the clientsecret and Secret Token fields, respectively and click on Test Connection

• Once the test is successful, click on Save and reload the page. Once the page has reloaded, select Edit Provisioning

• Turn on provisioning by toggling the Provisioning Status Button to On

The provisioning service imports roles only from AWS to Azure AD. The service does not provision users and groups from Azure AD to AWS. After we save the provisioning credentials, we must wait for the initial sync cycle to run. Sync usually takes around 40 minutes to finish.

Assign the Azure AD test user

• Within the Azure Active Directory overview menu, choose Enterprise Applications > All applications
• In the application list, select Amazon Web Services (AWS)
• In the app’s overview page, find the Manage section and select Users and groups and, select Add user, then select Users and groups in the Add Assignment dialog
• In the Users and groups dialog, select the required user the Users list, then click the Select button at the bottom of the screen

• Click on Assign
• To assign a specific AWS role to the user, select the user and click on Edit

• Click on Select A Role and select the appropriate role for the user. Click Assign once done

End User Experience

Once you have added the user to the App and assigned appropriate permission, the user can start accessing the AWS console without needing to perform any additional authentication. The user can log in to https://myapps.microsoft.com using their Azure AD/Microsoft 365 credentials and they will see the Amazon Web Services (AWS) app in their my apps portal.

They will be taken to the AWS console directly just by clicking on it and will granted to access to those services only for which they were assigned the roles.

Conclusion

As a next step, it is best practice to set up several SAML Roles inside of AWS. The SAML roles can and should be granularly defined down to the AWS account and resource level.

Here are some example roles to get started with:

• ReadOnlyAccess Role
• AmazonEC2FullAccess Role
• AdministratorAccess Role

On the Azure AD side, we recommend creating groups for each of the above Roles. The assign users to the group, and they are then automatically assigned to the AWS role. Using groups makes a bit easier to manage large amounts of users.

Find out more about Mismo Systems

We love Cloud, Containers, DevOps, and Workplace as a service. If you are interested in chatting, connect with us on Twitter, or drop us an email: connect@mismosystems.com. We hope you found this article helpful. If there is anything you would like to contribute or you have questions, please let us know!