The single sign-on (SSO) to applications has increased its popularity within organisations. SSO gives users a better logon experience and improves organisation’s security by enabling more manageable structure for application permission management. Users and their permissions can be managed in one, or at least in fewer, place(s) instead of separately in each application.
At the beginning, the SSO was mainly for web-based services’ end-users and not so much for power-users or admins. That has also changed over the time.
We got a customer request to investigate how SSO could be configured from Azure AD to Amazon Web Services (AWS) in an environment where users are mainly power-users and use the AWS through CLI. Power-users manage several AWS accounts belonging to the organisation.
The solution turned out to be such a nice and usable feature that we decided to share the overview of it with this blog post to all of you. Enjoy!
Tl;dr:
Azure AD can be configured as an identity source allowing login to Amazon Web Services with Azure credentials.
- Single Sign-on to AWS services with Azure AD credentials
- Centralised user and application permission management in Azure AD instead of managing same users also in application (AWS) side
- Possibility to invite external users as guests in Azure AD and grant the application (AWS) permission to them allowing guests still use their own organisation credentials
- Allow power-users to use their organisational credentials with the AWS CLI, easy workflow
The choice of two options
Microsoft has improved its Azure AD SSO capabilities drastically over the years. They have ready-made “Gallery Applications” for many popular web applications that can be configured and taken into use within minutes, and the custom application configuration has also been made simple. We decided to try both approaches: 1.) the “Amazon Web Services (AWS)” -gallery application, and 2.) by configuring the custom gallery application for AWS SSO purposes. Here’s a summary of the approaches.
Option 1. Use ready-made gallery application in Azure AD
- Just follow the official Microsoft instructions, and you are ready to go
- Configured in AWS IAM service, define Azure AD as an IdP
- In case of multiple AWS accounts, you need to define separate Azure AD gallery application for each of the accounts and configure the AWS IAM service account by account
- Supports federated SSO login to the AWS Console
- CLI usage with SSO a bit more cumbersome, requires assuming role using CLI
- Official AWS blog about it: https://aws.amazon.com/premiumsupport/knowledge-center/aws-cli-call-store-saml-credentials/
- SCIM provisioning from AWS → Azure AD
- Provisions defined AWS IAM roles to Azure AD, in where the target Azure users and groups can be defined to the roles
- Supports only IdP initiated SSO
Option 2. Define custom enterprise application in Azure AD for the AWS SSO
- Requires couple of more steps in Azure AD side than the previously mentioned gallery app
- Define SAML SSO configurations and attributes (tip: do the AWS SSO configuration first and you can import the AWS metadata to the Azure application)
- Configured in AWS SSO service, define Azure AD as a SALM identity source
- Only root account needs to be configured, SSO inherited to child accounts
- Supports federated SSO login to the AWS Console
- Supports SSO with the AWS CLI usage
- (AWS CLI SSO feature is build into the AWS CLI v2. AWS CLI v2 came generally available on Feb 2020. So the AWS CLI SSO is a relatively new feature (~ 6 months at the time of writing this). Before that the only way was to assume a role using CLI scripts, which was a bit cumbersome with all the SAML response copying and other steps.)
- SCIM provisioning from Azure AD → AWS
- Provisions defined Azure AD users and groups (& group members) to the AWS SSO service, in where the users/groups are defined to the target AWS accounts with defined permission sets
- Supports both IdP initiated and SP initiated SSO
Common with the two options
Both configuration options have relatively similar SSO experience to the AWS Console. We configured the 1.) official Amazon Web Services (AWS) application and 2.) the custom application, added a user to both application in Azure side, and with that user logged in to https://myapplications.microsoft.com/ -portal to see how the login experience goes.
Below is a short video with an active Azure session showing how the SSO goes from https://myapplications.microsoft.com/ to AWS Console using both approaches.
In addition to the IdP initiated session, the custom application also allows SP initiated SSO as well.
The CLI usage
The CLI usage experience varies a lot between option 1 and option 2.
The option 1, using the Azure ready-made Amazon Web Service gallery application, does not support easy to approach CLI usage with SSO. Instead you need to first create a SAML request to gather the response and then insert the response to a script to assume the used role (more of it in here). Does not sound any fun, does it?
The option 2 uses instead native aws sso configure command in CLI which instructs the user with the needed steps. Only thing a user needs to know is the SP initiated SSO url. So remember to provide that url to the power-users. (You can find it in the AWS console from SSO service configuration.)
Here is a example of power-user logon experience when using AWS CLI with the option 2 approach:
Our thoughts
We do respect the work of admins and power-users and our goal is to try to understand how to make their daily work easier while keeping the organisation’s policies and security in line. Also the consolidated user permission management enhances the transparency and eases the management tasks for those who control the permissions to the applications.
The benefit of using Azure as an identity source for the applications, such as AWS, is not only consolidating organisation internal user permission management to one place, but also allowing guest user permission management to the applications. The invited guest users can login to the shared applications using their own organisation credentials without needing any additional credentials to be managed or remembered.
In the experiment of AWS SSO, we tried two approaches and our choice and preferred method for the time being is the option 2: Azure custom application.
Couple of important factors why the custom application:
- In case of multiple AWS accounts
- Easier and consolidated configuration in AWS SSO
- Easier and consolidated configuration in Azure: just one Azure application instead of needing to create an application per target AWS account within the organisation
- Supereasy CLI SSO for the power-users
Services are constantly evolving and today’s approaches might be legacy one day. Our job is to keep up with the best practices and new technologies. Drop an email if you have ideas or questions for this or other topic. Let’s take a look at it together.
/Juho Erkkilä