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.
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.
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:
| |
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.
Mode #1 - 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.
As result, 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.
Warning
Important limitation: AAD provisioning scope filter currently (as state in 2022) doesn’t support operator memberOf, so you can’t filter users by membership in a security group
Mode #2 - 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 (former Windows LiveID) hotmail account to use new alias @outlook.com. This idea brought me much trouble – many apps (even in the 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.