Automating OpenID Connect-Based AWS IAM Web Identity Roles with Microsoft Entra ID

By Elias Abud, Principal IT Consultant – Devoteam A Cloud
By Dennis Bögershausen, Principal IT Consultant – Devoteam A Cloud
By Philipp Schäfer, Principal Solutions Architect – AWS

Devoteam A Cloud

For applications running outside of Amazon Web Services (AWS), developers often create an AWS Identity and Access Management (IAM) user with credentials, which are used to access the AWS resources.

An IAM user may have long-lived access and secret keys, which can increase the risk of impact if the credentials are exposed. Additionally, these users may violate company policies that state all user management, login, and authentication should be done by the corporate identity provider (IdP), such as Microsoft Entra ID.

In a previous AWS blog post, we discussed centralizing user management by using SAML-based authentication. This approach isn’t suited for automated background processes or applications running outside of AWS, however, due to its reliance on human interaction in the authentication workflow. This machine-to-machine use case needs a different approach.

In this post, we extend the solution by implementing an authentication workflow based on OpenID Connect, seamlessly integrating it with AWS in the form of an IAM Web Identity Role. On the Microsoft Entra ID side, this involves the registration of an application and includes setup of a service principal. On the AWS side, it requires the establishment of a trust relationship with the registered application and creation of a web identity role.

We’ll discuss the manual process of creating access for a service principal which can be authenticated via OpenID and Microsoft Entra ID to access AWS resources, and then describe how the process can be simplified with automation for all accounts belonging to AWS Organizations. You’ll learn how to automate the creation of OIDC-based AWS IAM Web Identity Roles for machine-to-machine authentication and authorization.

Devoteam A Cloud recently led a migration project where the client requested a centralized and unified secure authentication and authorization for humans and workloads running outside of AWS (see the former AWS blog post). Now, we’ll show you how this was accomplished and simplified through automation.

Devoteam A Cloud is an AWS Premier Tier Services Partner and AWS Marketplace Seller with the Security Competency. Working with AWS since 2013, Devoteam A Cloud supports customers with scalable infrastructure and new ways of thinking to re-invent their business.

Assume Web Identity Role Flow with Microsoft Entra ID

This solution was designed to establish a process on AWS that allows users authenticated through a service principal in Microsoft Entra ID to obtain temporary credentials from. These credentials remain valid for a duration ranging from 15 minutes to 12 hours, enabling applications or background services to carry out specific tasks.

Figure 1 – Assume role flow.

The authentication and authorization process depicted are as follows:

An external process (here it’s part of a CI/CD pipeline) logs in with an Azure service principal using a certificate-based authentication to gain an access token from Microsoft Entra ID.
When a login with the service principal is successful, it authorizes the use of the Azure App Registration and provides the client with a token that specifies the roles, audience, and permissions available to the client in Azure/Entra ID.
The client uses the token obtained from Microsoft Entra ID to exchange it with a temporary token from AWS Security Token Service (AWS STS).
AWS STS generates a transient token with a short lifespan and dispatches it to the client.
Finally, the client is able to take on the IAM Web Identity Role and gain access to the resources permitted for that role.

You might wonder about the authorization for AWS STS to exchange an Entra ID token for a token. This capability is enabled through the establishment of a trust policy within the IAM Web Identity Role.

1 {
2  "Version": "2012-10-17",
3  "Statement": [
4    {
5      "Effect": "Allow",
6      "Action": "sts:AssumeRoleWithWebIdentity",
7      "Principal": {
8       "Federated": "arn:aws:iam::{aws-account-id}:oidc-  
9            provider/sts.windows.net/{azure-tenant-id}/"
10       },
11      "Condition": {
12       "StringEquals": {
13         "https://sts.windows.net/{azure-tenant-id }/:aud":"audience-id"
14       }
15      }
16    }
17  ]
18 }

This trust policy is associated with an IAM Web Identity Role, granting authorization to a federated principal accessing through an OIDC provider from Azure to assume a role with web identity. As mentioned in line 8, the federated principal authorized to assume this role is the OIDC external IdP of Microsoft Entra ID.

To further specify which app registration is eligible to assume this role, a condition statement is added in line 13, ensuring the roles being assumed are for the defined tenant.

Challenges of Manual Setup in Enterprise Environments

Manually registering an application and assigning a service principal in Microsoft Entra ID with an external IdP in AWS can be quite demanding, especially in large enterprises with different individuals. Let’s explore some of the challenges that may arise during a manual setup:

Results in a violation of enterprise security policies and compliance because, when done by different individuals, it will result in varying approaches and setups.
Needs substantial access privileges in both AWS and the IdP, potentially leading to significant security risks.
Requires a deep understanding of both platforms, a competence that can be lacking in many companies.

Step-By-Step Guide for Manual Configuration

Next, we’ll explore the manual setups and before showing how the process get simplified with automation.

Step 1: Create an Application in Microsoft Entra ID

In Microsoft Entra ID, you have the option to register a new application and assign a new service principal to this application. An app registration is identified by a unique client id also known as an audience id.

Upon its creation, a new app registration in Microsoft Entra ID will be created holding a unique identifier which will be matched with a web IdP in AWS.

Figure 2 – Register an application in Microsoft Entra ID.

Step 2: Configure OpenID Connect Provider

Within AWS, you can add an external IdP using OpenID Connect. This is a one-time configuration step, and the same IdP can be leveraged for multiple app registrations. The value of the audience can be set in the initial setup as a dummy value because we’ll modify it in the next step.

Figure 3 – Configure OpenID Connect provider in AWS.

This step is required because it will register an audience created in Microsoft Entra ID in the previously created external IdP from Step 2.

Figure 4 – Add a new audience to identity provider.

Step 3: Integrate IAM Web Identity Role into AWS

Next, create an IAM Web Identity Role and associate it with the IdP established in Step 2. Additionally, select the specific audience that was created previously. Ensure you grant the desired permissions to this role.

Figure 5 – Create an IAM Web Identity Role in AWS.

Addressing the Challenges Through Automation

To address the challenges, the best approach is to streamline the process through automation. By automating the manual steps, the process will be simplified for users seeking to register an application in Microsoft Entra ID.

Admins or developers, for instance, would only need to create an AWS IAM Web Identity Role, and the necessary steps will be executed automatically without their direct intervention, thereby improving operational efficiency and scale. The automation also keeps AWS IAM and Entra ID in synch.

For centralized automation across an AWS Organization, we have assigned a single account to receive IAM events from all accounts within our AWS Organization. We refer to this account as the “Account Factory” and it contains roles which have the necessary permissions to modify all IAM Web Identity Roles within the AWS Organization. In addition, this account is authorized to interact with a dedicated API developed on Azure. The API is designed to create and remove service principals from Microsoft Entra ID, as required.

In every account belonging to our AWS Organization, we pre-deployed an IAM Event Rule that identifies events logged into AWS CloudTrail. When an AWS user creates or deletes an IAM Web Identity Role, the event is logged into CloudTrail and captured by this IAM Event Rule. This IAM Event Rule is connected through an Amazon EventBridge bus with another IAM EventBridge Bus located in the previously mentioned centralized “Account Factory.”

Figure 6 – Web identities automation architecture.

In the “Account Factory” we also created an IAM Event Rule which captures events received from an AWS Organization account. This Event Rule invokes an AWS Lambda function which parses the input and decides if it should remove an Azure app registration and its service principal. Finally, the Lambda function invokes Web-Identity-Role-Create or Web-Identity-Role-Delete from AWS Step Functions.

Both Step Functions are created to react to the addition or removal of AWS IAM Web Identity Roles in all accounts belonging to the AWS Organization. This process primarily aims to maintain continuous synchronization between Microsoft Entra ID service principal and the Web Identity Role in AWS IAM.

AWS Step Functions for the addition of an IAM Web Identity Role:

AWS Lambda name	AWS Lambda function	Input/Output	Description
create-service-principal lambda	Register an app and a service principal in Microsoft Entra ID	iam-role-arn/audience	Function calls a dedicated API on Azure to register a new application and assign a service principal to it. The API call returns a unique audience identifier.
add-audience-id-provider	Add audience identifier to identity provider in AWS	account_id audience/no output	Function receives an account id and audience identifier. It adds the audience identifier to the pre-deployed IAM IdP from OIDC deployed in every newly-created AWS account.
assign-role-to-audience	Assign role to audience	account_id audience role-arn/no output	Function rewrites the trust relationship in the IAM Web Identity Role by adding the audience identifier of the app registration to allow the newly-created service principal to assume the Web Identity Role. This step is required because, unlike a manual setup, the AWS user does not have an audience identifier so users enter any dummy value which will be overwritten few seconds afterwards.

AWS Step Function for the removal of an IAM Web Identity Role:

AWS Lambda name	AWS Lambda function	Input/Output	Description
delete-service-principal	Delete a service principal	Audience/no output	Function calls a dedicated API on Azure to delete an existing service principal. The API call returns an audience.

Conclusion

While leveraging AWS IAM users for cloud external background processes is possible, these can sometimes cause problems due to their long-lived credentials which may violate a company’s policy stating all user management must be centralized in an enterprise identity provider (IdP).

An innovative solution uses AWS IAM Web Identity Roles integration with external IdPs like Microsoft Entra ID, making it easier for users by connecting their existing credentials to cloud resources. This is especially helpful for large companies that want to manage users in one place.

This posts shows how to use Microsoft Entra ID with AWS Organizations and explains the difficulties of setting things up manually. We suggested a better way with a central AWS account that changes how developers can access AWS resources from different cloud providers or from their data centers.

.

.

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