AWS Partner Network (APN) Blog

Automate SAML 2.0 Federation for AWS Organizations Using Azure Active Directory

By Elias Abud, Principal IT Consultant – Devoteam A Cloud
By Yuriy Bezsonov, Sr. Partner Solutions Architect – AWS

Devoteam A Cloud

Many enterprises want to streamline identity management by introducing a single identity provider (IdP) for their multi-cloud approach. In this post, we will cover the integration of single sign-on (SSO) with Azure Active Directory (Azure AD) in the context of AWS Control Tower.

Devoteam A Cloud recently led a migration project where it presented a client with two options for integrating SAML 2.0 federation into their AWS Organization using Azure AD.

This post outlines two separate SSO templates that are available in Azure Marketplace. By comparing and contrasting these options, Devoteam highlighted their respective strengths and helped the client choose the best option for their specific use case. After careful consideration, an AWS single-account access template was selected.

Devoteam A Cloud is an AWS Premier Tier Services Partner and AWS Marketplace Seller with several AWS Competencies, including DevOps and Migration Consulting. Working with AWS since 2013, Devoteam supports customers with scalable infrastructure and new ways of thinking to re-invent their business.

Solution Background

Azure Marketplace (Figure 1) is a comprehensive repository of hundreds of applications, among them templates that streamline the deployment and setup process for SSO.

Amazon Web Services (AWS) has many pre-built templates available in Azure Marketplace, but we’ll focus on two that are specifically designed for creating a simpler SSO experience and ensuring secure and seamless access to your applications.

The two templates (apps) available in Azure Marketplace are:

  • AWS IAM Identity Center: A pre-constructed template to leverage SSO integration between AWS as a service provider and Azure AD as an identity provider for one or more AWS accounts. This template creates an enterprise application in Azure AD with which AWS IAM Identity Center is able to import users from Azure AD into AWS and assign the users into roles and accounts in AWS IAM Identity Center.
  • AWS Single-Account Access: A pre-constructed template that allows for seamless SSO integration between AWS and Azure AD, specifically for a single AWS account. It establishes an enterprise application within Azure AD for each account, providing a centralized location for managing user identities. This template exports identity and access management (IAM) SAML roles from AWS to Azure AD, enabling you to manage user identities externally and grant access to AWS resources within your account.

The following table further compares AWS IAM Identity Center and AWS Single-Account Access, highlighting the differences in the way every application manages the user management as well as the technical realization.

Azure Marketplace App AWS IAM Identity Center AWS Single-Account Access
SAML certificate Single certificate Separate certificates per app/account
User creation Azure AD Azure AD
Roles – trusted entity type IAM roles/AWS services SAML 2.0 federation
Technical realization One-time configuration for all accounts Setting up is required for every newly-created account
Role assignment AWS IAM Identity Center Azure enterprise application
Account assignment AWS IAM Identity Center Azure enterprise application
How it works AWS imports users from Azure Azure imports roles from AWS

Both solutions utilize the SAML protocol for secure authentication and access to applications. This allows for the exchange of user data—such as logins, authentication status, and other key attributes—between the IdP and the service provider. In next two figures, we emphasize the significant difference between both approaches.

Figure 1 shows the architecture of the role assignment when using the AWS IAM Identity Center App from Azure Marketplace. Upon setting up the SSO integration, users are imported from Azure AD into AWS IAM Identity Center. The role assignment of a permission set to a user for a specific account is taking place in AWS and not in Azure.


Figure 1 – Roles assignment when using AWS IAM Identity Center from Azure Marketplace.

Contrary to the Azure Marketplace application “AWS IAM Identity Center,” with the Azure Marketplace application “AWS Single-Account Access” the roles are imported into Azure and Azure is creating an AppRole reflecting the IAM SAML role in AWS. The assignment of users and groups to roles is performed within Azure AD, as shown below.


Figure 2 – Roles assignment when using AWS Single Account Access from Azure Marketplace.

There are several ways a AWS Single Account Access approach can benefit an enterprise:

  • Security: Large organizations prefer to manage their users in only one IdP in order to have a single point of control. Managing permissions, users, groups, and roles in a centralized place improves visibility into the user access process.
  • Maintenance effort: Another reason is to reduce maintenance efforts where a team can take care of enforcing user access policies in one place. Onboarding new team members and offboarding team members can be easily done from a centralized place, also for AWS.
  • Ownership: Because every account is linked separately with Azure AD, it’s possible to assign an owner on every enterprise application. Owners can then control which users and groups in Azure AD can access the AWS accounts. This is not possible when using AWS IAM Identity Center application because the role assignments must be done in the management account.

Set Up AWS IAM Identity Center from Azure Marketplace

Below, Figure 3 presents the resulting architecture of using the AWS IAM Identity Center application from Azure Marketplace. Setup can be completed through a few manual actions in both the AWS Management Console and Azure portal without the need for automation or prior cloud and coding experience.

The central component of this architecture is the Azure enterprise application, which is responsible for creating and managing the integration with AWS. On the AWS side, SSO is managed within AWS IAM Identity Center. In the settings, you can change the default setting “Identity Center Directory” to “External Identity Provider.”


Figure 3 – Architecture of AWS IAM Identity Center – Azure Marketplace.

This setup operates on the basis of a single SAML certificate per AWS Organization. The certificate is typically linked to the management account, allowing for the import of users into AWS IAM Identity Center.

Devoteam did not recommend its client to use this setup because it does not centralize the user management in Azure AD; instead, this setup separates the role and user assignments into two places and requires extra maintenance.

Enable Setup of AWS Single-Account Access

The alternative approach to establishing SSO with Azure AD is to utilize the AWS Single Account Access application in Azure Marketplace.

Figure 4 depicts its implementation showing each AWS account is paired with a single enterprise application. Hence, this option requires an automated process as each newly-created AWS account within the organization necessitates individual configuration and setup.


Figure 4 – Implementation of AWS Single Account Access app from Azure Marketplace.

Next, we will explain the case study for how Devoteam managed to design, together with the client and a cloud provider, an automated solution based on this approach, and how it was connected with AWS Control Tower.

Case Study

For a German client, Devoteam focused on using infrastructure as a code (IaC) with Terraform. It also decided to design the solution to use serverless services such as AWS Lambda, and for code deployment AWS CodeBuild was used.

Using IaC made it easier to deploy the same solution in different stages, development and production environments, as well as for completely new clients with similar requirements.

The account ordering system is reachable with Amazon API Gateway, where Devoteam used a resource policy to limit who can access the API Gateway and added another security layer with JWT tokens using API Gateway authorizers.

Finally, Devoteam restricted with the help of service control policies (SCPs) the creation of IAM roles from AWS, and restricted accounts from being able to create AWS users to prevent anyone from misusing the setup.

Automation with AWS Step Functions

The process of setting up the integration for a single AWS account is straightforward. However, the process must be repeated for each newly-created AWS account.

This can be time-consuming and repetitive, particularly for organizations with a large number of AWS accounts. By automating this process, organizations can simplify the management of user access to their AWS resources and reduce the risk of errors or inconsistencies.

Given the complexity of the multi-step SSO process, Devoteam leveraged AWS Step Functions to simplify the workflow, provide increased visibility, and streamline the SSO experience for users.

AWS Step Functions is triggered by AWS Control Tower directly after creating and provisioning an AWS account. It requires a JSON payload with information such as account ID, account owners, and display name. Figure 5 showcases the necessary steps to complete the SSO integration.


Figure 5 – AWS Step Functions workflow.

The table below provides a brief overview of each task in the AWS Step Functions workflow:

  • Update DB – Starting SSO: Amazon DynamoDB is used as the central repository to maintain an accurate record of every AWS account creation.
  • Create ‘ListRoles’ user: AWS Lambda creates a new user in the newly-created AWS account. The ListRoles user will be used in Azure AD to list SAML roles from the AWS account.
  • Attach policy user: Lambda creates an IAM policy with ListRoles permissions attached to the ListRoles user.
  • Create user access key: Lambda creates credentials for the ListRoles user and stores the credentials in AWS Secrets Manager.
  • Store user credentials in key vault: Lambda securely calls an Azure function and stores the credentials in Azure. These will be used by Azure AD to list IAM federation roles from AWS.
  • Create enterprise application: Lambda securely calls an Azure function and creates a new enterprise application.
  • Wait 120 seconds: The creation of an enterprise application can take up to two minutes. The workflow stops during this time period.
  • Get SAML metadata URL: Lambda calls Azure API to check the status of the provision of the enterprise application.
  • Check if XML metadata URL is available: This step verifies whether the SAML metadata file is available in Azure.
  • Upload XML file to Amazon S3: Uploads and stores the XML file to an Amazon Simple Storage Service (Amazon S3) bucket.
  • Create SAML provider: Lambda creates the SAML provider in AWS using the XML metadata.
  • Update DB – Finished SSO: Updates Amazon DynamoDB with the successfully finished workflow status.

AWS Step Functions form only a fraction of the complete architecture depicted in Figure 6 below. Upon a request from ServiceNow, the API Gateway endpoints are called through a secured connection and it triggers Lambda functions to create, update, or delete AWS accounts.

Integration with AWS Control Tower

Once the request is accepted, the Lambda function parses the request and triggers AWS CodeBuild to begin creating or deleting an AWS account with AWS Control Tower. When this is complete, Control Tower notifies Amazon Simple Notification Service (SNS).

Devoteam registered a Lambda function to this SNS topic, which will be triggered when the AWS account is ready and the SSO integration with AWS Step Functions starts.


Figure 8 – SSO and Amazon API Gateway in the context of AWS Control Tower.


In this post, we summarized our learnings from a migration project led by Devoteam A Cloud for a German client who was looking for a unified identity provider solution for its multi-cloud strategy.

The customer’s main IdP is Azure Active Directory and the requirement was to keep the management of users in Azure AD for AWS accounts.

We examined two different solutions, and both are based on SAML 2.0 protocol. Although both solutions are similar in many other respects, the slight difference in the user management makes a big difference in terms of security, maintenance, and usage for large enterprises.

We have also explained how enterprises benefit when separating single sign-on integration on the account level, and how Devoteam automated this process for its customer in the context of AWS Control Tower.

You can also learn more about Devoteam A Cloud in AWS Marketplace.


Devoteam A Cloud – AWS Partner Spotlight

Devoteam A Cloud is an AWS Premier Tier Services Partner with several AWS Competencies, including DevOps and Migration Consulting. Working with AWS since 2013, Devoteam supports customers with scalable infrastructure and new ways of thinking to re-invent their business.

Contact Devoteam A Cloud | Partner Overview | AWS Marketplace | Case Studies