SSO on AWS – 2/3 – Architecture

A brief context

• This project concerns a large multi-cloud customer: more than 10,000 employees
• Who has an AWS landing-zone automation: 30 -> 600 AWS accounts in 3 years
• And several AWS Organizations

Target

• Manage AWS console access for projects on their dedicated AWS accounts

Cross-functional access and IAC remain on the Identity model seen in part 1/3, so as not to overload AWS IAM Identity Center, which has API limits to consider.

Constraints

• Implement security: corporated MFA and source IP restriction
• Be scalable: up to 10,000 users
• Manage segmentation between multi AWS organizations
• With Azure Active Directory as IDP

Architecture

Binding AAD Groups to AWS SSO Assignments

• Azure Active Directory

Azure Active Directory is the referential directory. It is defined as the AWS SSO Identity Provider for each AWS Organization.

In AAD, an Administrative Unit has been dedicated to the solution in wich we manipulate groups, owners and SSO members.

It is connected to AWS through Enterprises Applications.

• Enterprise Application

These are Applications on Azure supported by AWS that allow you to link providers with AWS SSO.

There are 1 per AWS Organization

• App Registration

These are Azure records of applications carrying Applications rights.

There are 3:

AWS_IAM_Identity_Center_ORGA1_PROD

AWS_IAM_Identity_Center_ORGA2_PROD

And IAC_PROD for IAC accesses in Graph API

Points of attention

AWS access are now managed by a cross clouder process, chaining Azure AD actions and AWS SSO calls. Somes buffers are needed in these processes and all steps must be resilients and idempotents.

Scalability

The expected payload is between 500 and 2000 AWS Accounts.

The customer’s landing zone factory delivers 5 default roles per AWS account with an average of 20 AWS accounts per mounth.

-> solution must handle multiples roles creation at the same time.

IAC on Azure

Using Graph API with an App Registration owner of each Azure Enterprise Application for SSO

AWS SSO Observability

• MS Teams flux is used to follow live role creation progress.

Default accesses creation on 1 AWS account:

Alien SSO configuration detected:

• A ‘live SSO state’ is maintained in dynamodb that compiles configured and real SSO accesses.

SSO Access State can be graphed dynamically:

By controlling ‘who do what’ in AWS SSO, the automation can therefore ingests console SSO configurations as well.

Global Informations

There are 2 differents types of AWS SSO actions in CloudTrail:

• SSO users actions: authenticate, federate …
• SSO configuration actions: account assignment, permissionset creation …

All SSO actions are audited, both those coming from factories and those coming from outside the factories.

Complete SSO Observability is provided by the project SAS ( SSO Access State )

-> SAS Project will have its own article.

Next

After survey and architecture, automation of SSO accesses will be discussed in section 3/3 of this story.

The following topics will be covered:

1. Global automation process
2. Azure resource availability in IAC
3. Azure<->AWS synchronization limit
4. AWS SSO assignment control