AWS SSO with Azure AD – Enterprise Adoption Tips

If you manage many AWS accounts in an enterprise environment, you probably feel the need for better user management and federate it with IdP (in my case with Azure Active Directory). In 2017 AWS has introduced a new way how to federate access – with an AWS SSO service. In this post, I would like to describe some properties of the solution you need to count on.

AWS IAM can federate with external IdP for a long time (called Single-Account Access), but this solution requires creating and managing AAD Enterprise app for every federated AWS account. In case you have hundreds of AWS accounts, it brings overhead costs to manage all these applications.

Diagram of Azure AD and AWS relationship
AAD with AWS integration diagram – Single-Account Access

AWS SSO federation

I found AWS SSO as a much better approach because all you have to do is set up and maintain a single AAD Enterprise app – long story short, metadata about users and groups (username, email address,… – NO passwords) are provisioned into AWS SSO service, deployed in AWS master account, together with role definitions (permission set). Inside AWS SSO user interface are available all connected AWS child accounts, you just select a role, destination AWS child account (where the role will be deployed), who should be granted the role in given AWS account and AWS SSO will provision and generate roles with trust relationship into AWS IAMs of selected child accounts.

IDP Initiated SSO 
IDP Initiated SSO 
AWS 1 
AWS Cloud 
AWS Xcount 2 
AWS Account 3
AAD with AWS integration diagram – via AWS SSO

When user logs into AWS console, after successful SSO login (via SAML protocol) is redirected to AWS SSO Portal, where user see all available AWS accounts and roles. The provisioning is one-way sync made via SCIM protocol and it works that AAD periodically pushes updates about users into AWS SSO service.

This setup brings some limitations or maybe „strange“ behavior you need to count with.

Empty first name/surname results in SCIM failure

If you follow the official tutorial provided by Microsoft, you installed the AAD Enterprise application AWS Single Sign-On by AWS from the AAD application gallery.

The application has all the required attribute mapping out of the box. In my AD directory, after the first run of provisioning, some of the users have not been provisioned in AWS SSO with strange SystemForCrossDomainIdentityManagementServiceIncompatible error :

StatusCode: BadRequest, {"schema":["urn:ietf:params:scim:api:messages:2.0:Error"],
"detail":"Request is unparsable, syntactically incorrect, or violates schema.","status":"400"

After some debugging, I found out that the application doesn’t cover cases when a user doesn’t have filled in first name/surname. In attribute mapping, you can add some default value to these attributes or you can switch these two attributes to expression like Coalesce([surname], [mail]) – in case surname is empty, email value is used.

Scoping users and groups for provisioning

AAD Enterprise app in AWS SSO is used for SSO access (you log in via SAML into AWS SSO portal) and for provisioning (to sync users into AWS SSO via SCIM protocol).

AWS SSO service has few limits you need to have on your mind. Currently, there is a limit of 50 000 users to be provisioned into AWS SSO. This could be an issue in a scenario, you have a large organization of over 50 000 users and just a small subset of users need access to AWS console (developers, security,…) and you will need to limit number of users to be provisioned with scope filter.

There are two modes, how to filter groups/users, who will be provisioned.

Sync all users and groups scope

In AAD Enterprise app select Sync all users and groups scope and in the section Mapping create a scoping filter (one filter can be for users and one for groups – but there are two isolated filters). This settings will provision all users and groups matching given filter, but it doesn’t mean they will be able to login (on AAD side). AAD checks during login workflow, if user is assigned to AAD Enterprise application. You can turn off this by switching off toggle User assignment required? in Properties. Thanks to that any user (including users with no assigned roles in AWS) will be able to login into AAD Enterprise app, but they will not see any AWS account after login.

Important limitation: AAD provisioning scope filter currently doesn’t support operator memberOf, so you can’t filter users by membership in a security group.

Sync only assigned users and groups scope

In AAD Enteprise app select Sync only assigned users and groups scope. In this mode it  will provision only users and groups, who have been directly assigned to the AAD Enterprise app. If you assign the app to UserA, it will provision UserA into AWS SSO, but with no other membership. If you have assigned the AAD Enterprise app to SecurityGroupB (where UserA is member of), it will provision the security group, UserA and membership information into AWS SSO.

Cons of this approach is that you have to manage list of assigned users in two places – first is the AAD Enterprise app assignment, wait for users to be updated in AWS SSO, and assign requested role inside AWS SSO.

Nested security groups

SCIM doesn’t support nested security groups. If you have a more complicated structure when a user is a member of a security group and the security group is a member of another security group, this membership information will not be transferred into AWS SSO. Only first-level security groups are supported.

Personal Microsoft accounts with aliases

A long time away, I had an idea to rename my personal Microsoft account (Windows LiveID) hotmail account to use new alias @outlook.com. This idea brought me much trouble – many apps (even in Microsoft world) can’t handle the situation, somewhere is the account referred as @hotmail.com and somewhere as @outlook.com.

AWS SSO is, unfortunately, the same story – I was not able to get the account working, during login I receive an error message Invalid MFA credentials. I do not recommend using this kind of Microsoft accounts.

Redshift federation support

In case you use federated login into AWS Redshift, I have bad news for you. Federation via AWS SSO is not supported for Redshift services. You will need to onboard an AWS account with deployed Redshift cluster with a traditional Single-Account access approach into AAD in parallel.

Napsat komentář

Vaše e-mailová adresa nebude zveřejněna. Vyžadované informace jsou označeny *