Co-author – @ARJUN T S

About

OpenID Connect (OIDC) is an authentication protocol that extends OAuth 2.0, enabling single sign-on (SSO) and secure identity verification across applications. This blog will explore how to leverage Microsoft Azure (Microsoft Entra ID) as an identity provider for AWS services, ensuring seamless and secure integration.

Use case

In today's multi-cloud landscape, enterprises can choose directory or ID services and resource services from various providers. With the OIDC protocol, it is easy to integrate a combination of ID providers and Resource providers as long as they are compliant with OIDC specifications. For example, an enterprise uses Microsoft Azure to manage its directory users and corresponding privileges, while resources are provisioned on AWS for operational purposes. In a tightly coupled world, one will have to create a replica of the directory users and corresponding privileges in AWS, needing a detailed administration overhead and security risks. However, using OIDC provides a seamless federated integration of users and leverages the same privileges as enterprise users. This serves as a robust identity provider that allows employees to authenticate using their existing credentials. Enterprise employees can log into a web application integrated with Microsoft Entra ID, which utilizes OAuth 2.0 for authentication. With a successful OAuth handshake, the application gets an ID token from Microsoft Entra ID. This token is exchanged for temporary AWS credentials through the AWS Security Token Service (STS). The STS service will validate the ID tokens from the original ID providers and validate their role as configured. Once the application receives the temporary AWS credentials, it can interact with various AWS services, such as S3 or DynamoDB, without the need for developers to manage AWS IAM user credentials directly. This setup not only simplifies access but also enhances the security of the users.

How OIDC authentication works

OIDC uses ID tokens to verify user identities and provide authentication information. These tokens are issued by the identity provider (Microsoft Azure) and consumed by the relying party (AWS services) to authenticate users (source).

Setting up Microsoft Azure as an identity provider

1. Register your application in Microsoft Azure:

1. Navigate to the Microsoft Entra admin center.
2. Go to Identity > Applications > App registrations.
3. Register your application and configure the necessary authentication settings (source).

2. Enable ID tokens:

1. Under Platform configurations, select Add a platform.
2. Choose Web for web applications and add the redirect URI.
3. Enable ID tokens under Implicit grant and hybrid flows (source). For more information, see Enable ID tokens on the Microsoft Entra documentation page.

For step-by-step instructions, see Obtaining connection values for Amazon SNS (as an example for Amazon SNS connector) on the IBM App Connect documentation page.

Configuring AWS services to use Microsoft Azure for authentication

1. Set up AWS IAM Identity Center:

1. Enable AWS IAM Identity Center in your AWS account. For more information, see Enable IAM Identity Center on the AWS documentation page.
2. Configure SAML and SCIM provisioning to synchronize user and group information from Microsoft Azure (source).

2. Integrate Microsoft Azure with AWS IAM Identity Center:
Follow the steps to set up SSO integration, allowing users to sign in to AWS services using their Azure credentials (source).

For step-by-step instructions, see Obtaining connection values for Amazon SNS (as an example for Amazon SNS connector) on the IBM App Connect documentation page.

Using AssumeRoleWithWebIdentity for AWS STS Token Exchange

1. Overview:

• AWS Security Token Service (STS) provides temporary security credentials for users authenticated via a web identity provider. This is particularly useful for mobile and web applications (source).

2. AssumeRoleWithWebIdentity API:

• This API returns a set of temporary security credentials (access key ID, secret access key, and security token) for users authenticated by an OIDC-compatible identity provider like Azure (source).
• The credentials can be used to sign AWS service API calls, ensuring secure access without embedding long-term AWS credentials in your application (source).

3. Steps to use AssumeRoleWithWebIdentity:

• Obtain an ID token: Authenticate the user with Azure and obtain an ID token.
• Call AssumeRoleWithWebIdentity: Use the AWS CLI or SDK to call the AssumeRoleWithWebIdentity API, passing the ID token and specifying the Role ARN (source).
• Use temporary credentials: The API response includes temporary credentials that can be used to access AWS services (source).

Benefits of using Microsoft Azure for AWS authentication

• Centralized identity management: Manage user identities and access permissions centrally in Azure, reducing administrative overhead (source).
• Enhanced security: Utilize Microsoft Azure's robust security features, including MFA and Conditional Access policies, to protect AWS resources (source).
• Seamless user experience: Enable users to access AWS services with their existing Microsoft Azure credentials, improving productivity and user satisfaction (source).

Leveraging Microsoft Azure user privileges in AWS services

Microsoft Azure user privileges can be leveraged in AWS services to streamline identity management and enhance security:

• Multicloud identity integration: Use Microsoft Entra ID to consolidate identity services across Azure and AWS. This allows for consistent access and governance, reducing the need for multiple identities (source).
• Federated authentication: Configure AWS IAM to recognize Microsoft Azure as a federation and authentication source. This enables users to authenticate with Microsoft Azure credentials and access AWS resources (source).
• Conditional access policies: Apply Microsoft Azure Conditional Access policies to control access to AWS services based on user attributes and conditions, enhancing security (source).
• Flexibility: This setup allows applications running in Azure to seamlessly interact with AWS services, enabling hybrid cloud architectures.

OIDC token exchange flow

OIDC token exchange flow diagram explanation:

1. User authentication: The user authenticates with Azure (Microsoft Entra ID) and receives an ID token and a refresh token.
2. Token verification and exchange: AWS STS verifies the ID token and issues temporary security credentials (access key ID, secret access key, and security token)
3. Assuming the role: The application uses the OIDC token to call the AWS API AssumeRoleWithWebIdentity. This API call includes the token and specifies the role ARN that the application wants to assume.
4. Access AWS services: The application uses the temporary credentials to access AWS services securely.

Conclusion

Integrating OIDC authentication using Azure as an identity provider for AWS services offers numerous benefits, including improved security, centralized management, and a seamless user experience. By leveraging Azure user privileges in AWS services, you can ensure secure and efficient authentication for your integration workflows.