Seamless User Logins from Azure AD to AWS EKS via Web Identity Federation or SAML Bridging

IAM Design pattern, Federated Identity in Action: Azure AD to AWS EKS Deployments with SAML and Web Identity Federation

Introduction

As organizations expand their cloud usage, identity and access management become a top priority. While Azure Active Directory (Azure AD) has become a staple for enterprise user authentication—particularly for Microsoft-centric environments—teams also increasingly rely on AWS for broader cloud services. A common scenario arises: a user logs into Azure AD, but must also securely access AWS resources, such as deploying workloads to an Amazon EKS (Elastic Kubernetes Service) cluster.

In this case study, we explore how one organization, TechFusion{Name Changed to protect client security vector attack}, accomplished single sign-on for developers who use Azure AD credentials to manage daily tasks, yet require ephemeral AWS credentials when performing EKS deployments. They achieved this by configuring Web Identity Federation or SAML bridging, ensuring that short-lived AWS security tokens are issued whenever a user from Azure AD needs to interact with the EKS environment. The result is a seamless, secure workflow—no storing of static AWS Access Keys, no manual copying of credentials, and an improved compliance posture.

---

Background

The Organization

TechFusion is a mid-sized technology company with 4,000+ employees spread across multiple geographic regions. They run a mixture of Microsoft Office 365, Azure-based SaaS solutions, and a variety of custom microservices deployed primarily on AWS. Over the past two years, they standardized on Azure AD for user authentication due to its strong integration with Microsoft services, streamlined MFA (Multi-Factor Authentication), and enterprise identity governance features.

Evolving Infrastructure

While TechFusion had some workloads in Azure, their core production environment was centered on AWS, particularly:

• Amazon EKS for microservice container orchestration.

• Amazon RDS for relational databases.

• AWS Lambda for serverless tasks.

Developers, site reliability engineers (SREs), and data scientists needed secure, immediate access to these AWS resources—particularly to run kubectl commands against the EKS cluster or to push container images to Amazon ECR.

Challenge: Without a unified identity solution, these users had to maintain a separate set of AWS IAM credentials or shared roles with static keys. This risked key leaks, manual credential refreshes, and complicated off-boarding.

---

Identity and Access Management Overview

Azure AD as the Source of Truth

TechFusion’s employees and contractors all have Azure AD accounts. Group membership in Azure AD dictates a user’s role (e.g., “Developers,” “DevOps Engineers,” “Ops Admins”). For single sign-on to Microsoft 365 or Azure Portal, this was straightforward. But bridging that same identity to AWS demanded an additional layer: either SAML bridging or OIDC-based Web Identity Federation.

AWS IAM and Temporary Credentials

AWS Identity and Access Management (IAM) typically uses:

1. Access Key + Secret: Static keys, not recommended for ephemeral dev usage.

2. IAM Roles: Usually best practice, generating short-lived tokens via STS (Security Token Service).

3. Federation: Delegates external identity providers to yield ephemeral tokens. SAML or OIDC can be used, where a trusted IdP vouches for the user, and AWS grants a session accordingly.

Goal: TechFusion wanted ephemeral tokens that expire in, say, 1 hour or 8 hours. No static credentials would be stored on developer machines or in configuration files. This approach also aligns with compliance frameworks (ISO 27001, SOC 2, even FedRAMP for certain workloads).

---

Implementing the Federation

Option A: SAML Bridging

1. SAML Provider in AWS: TechFusion created a SAML provider in AWS IAM, uploading the Azure AD SAML metadata or certificate.

2. Enterprise App in Azure AD: In Azure AD, they set up an Enterprise Application pointing to AWS, providing roles or claim mappings in the SAML assertion.

3. Assertion Flow: When a user logs into Azure AD, they can click on the AWS application tile. Azure AD sends a SAML assertion to AWS, indicating which user or group. AWS then issues a temporary role session.

Advantages: A well-trodden path, with multiple guides from Microsoft and AWS. SAML supports group-based role mapping—e.g., a user in “AzureAD_DevOps” group becomes “arn:aws:iam::123456789012:role/DevOpsRole” in AWS.

Disadvantages: SAML is more XML-based, can be verbose, occasionally tricky to debug. Some DevOps prefer the OIDC approach.

Option B: Web Identity Federation via OIDC

OIDC is a simpler identity layer on top of OAuth 2.0. For TechFusion, this might mean:

1. Azure AD acts as an OIDC IdP.

2. An App Registration is configured in Azure AD, enabling OIDC tokens for third-party usage.

3. AWS trusts that OIDC identity provider. The user’s sign-in token from Azure AD is exchanged for STS credentials with a role.

4. The developer’s local CLI uses a “federation client” that obtains an Azure AD token, passes it to AWS STS, which returns short-lived credentials.

Advantages: OIDC-based flows are sometimes simpler than SAML. They integrate nicely with tools like the AWS CLI or aws-iam-authenticator for EKS.
Disadvantages: Requires a bit of custom script or a third-party tool to orchestrate token exchange if not using a standard library.

---

Workflow Details

Developer Experience

1. Login: The developer opens a local terminal and runs a script or tool that prompts them to sign in with their Azure AD credentials (maybe an az login or a custom web flow).

2. Token Exchange: After successful sign-in, the tool obtains an OIDC or SAML token from Azure AD.

3. Role Assumption: The token is sent to AWS STS with a RoleArn parameter, requesting temporary credentials.

4. STS Response: AWS returns ephemeral access keys and session tokens.

5. Access EKS: The user can now run kubectl --context=aws-eks or helm commands, referencing the ephemeral credentials.

   $ ./login-aws.sh
   Opening browser for Azure AD login...
   Login successful. Acquired short-lived AWS STS credentials for role arn:aws:iam::123456789012:role/DevOpsRole
   $ kubectl get pods
   NAME          READY   STATUS    RESTARTS   AGE
   microservice  1/1     Running   0          2h
   

   Admin Setup

   SAML route:

   1. Azure AD: Admin registers a new “AWS SAML Application.” They supply the AWS account ID, the required URNs, and define group-to-role mappings.

   2. AWS: Admin creates an IAM SAML provider (aws iam create-saml-provider) and configures an IAM role with a trust policy referencing that provider.

   3. Testing: The admin logs in to the Azure AD portal, sees the “AWS DevOps Access” tile, clicks, and is redirected to the AWS console with ephemeral credentials. CLI usage can also be handled with a plugin or script.

   OIDC route:

   1. Azure AD: Admin registers an OIDC app, sets redirect URIs or client secrets.

   2. AWS: Admin configures an OIDC identity provider in IAM (aws iam create-open-id-connect-provider), referencing the Azure AD issuer URL and valid client IDs.

   3. Role Policy: An IAM role trusts tokens from that OIDC provider, e.g.

   {
     "Version": "2012-10-17",
     "Statement": [
       {
         "Effect": "Allow",
         "Principal": {
           "Federated": "arn:aws:iam::123456789012:oidc-provider/login.microsoftonline.com/..."
         },
         "Action": "sts:AssumeRoleWithWebIdentity",
         "Condition": {
           "StringEquals": {
             "login.microsoftonline.com:sub": "abcd-efgh-ijkl"
           }
         }
       }
     ]
   }
   

   Security and Compliance Benefits

   Short-lived credentials drastically reduce the risk of key compromise. If a user’s session token leaks, it’s valid only for, say, 1 hour. Once the user leaves the company or changes roles, their Azure AD account is updated—automatically preventing them from obtaining new AWS sessions.

   Logging: Both Azure AD sign-ins and AWS STS assumption calls are logged, providing an audit trail. On the AWS side, you can enable CloudTrail to track the AssumeRoleWithSAML or AssumeRoleWithWebIdentity events. On the Azure side, sign-in logs show the user and device context.

   Compliance: This design aligns with ISO 27001, SOC 2, FedRAMP moderate, etc., as ephemeral credentials plus centralized identity management are recognized best practices.

   ---

   Technical Caveats and Trade-Offs

   1. Lifecycle of Credentials: Typically, the max session for SAML or web identity is up to 12 hours. Some teams prefer shorter, like 1-2 hours. Devs might find it annoying to re-auth frequently.

   2. Multiple Roles: If a developer belongs to multiple Azure AD groups mapping to different AWS roles, they must choose which role to assume at each session.

   3. Onboarding: Each new team or user group in Azure AD might require an update in the AWS role trust policy or SAML group mapping. Good documentation is crucial.

   4. CLI Tools: Some users might rely on open-source scripts or official AWS tools. For the SAML approach, the aws sso login or aws sts commands can handle flows. For OIDC, custom tools or automation might be needed.

   ---

   Performance and User Feedback

   TechFusion ran a pilot among 50 DevOps engineers for 2 weeks. Results:

   • 95% approval for simpler SSO flows. Users no longer manage separate AWS Access Keys.

   • Reduced Onboarding Time: New hires get an Azure AD account; within minutes, they can az login or an SAML-based flow to access AWS EKS.

   • Minimal Overhead: Setting up the SAML application took about 4 hours. The OIDC approach was 2-3 hours plus some scripting. Ongoing maintenance is low, mostly verifying group mappings.

   Developers found ephemeral sessions a huge convenience. The only friction arises if sessions expire mid-day. The default session length was set to 4 hours, but some user groups, like SREs, requested 8 hours. TechFusion decided on a uniform 6-hour session as a middle ground, with an easy re-auth process.

   ---

   Scaling Beyond EKS

   While the initial impetus was EKS cluster access, the ephemeral credentials also unlock broader AWS usage: pushing container images to ECR, reading logs from CloudWatch, or updating CloudFormation stacks. The same approach extends to many AWS services as long as the roles’ policies allow.

   In some advanced scenarios, TechFusion also explored bridging Azure AD for ephemeral GCP credentials or single sign-on to on-prem services. The pattern is consistent: Azure AD remains the user’s “source of identity,” while each environment trusts that identity via a federation protocol.

   ---

   Future Outlook

   1. Automated Role Mapping: TechFusion is building an internal service that automatically syncs Azure AD group changes to AWS IAM or SAML group mappings. This reduces manual administrative overhead.

   2. CLI Polishing: A user-friendly CLI tool that calls az login, obtains tokens, and seamlessly calls sts:AssumeRoleWithWebIdentity or SAML behind the scenes. This might eventually be integrated with DevOps pipelines, ensuring ephemeral credentials for CI/CD jobs.

   3. Beyond Microsoft: TechFusion has begun evaluating Okta as a potential replacement or addition for external partner logins. The bridging concepts remain the same but might simplify certain advanced policy definitions.

   ---

   Conclusion

   By establishing Web Identity Federation or SAML bridging between Azure AD and AWS IAM, TechFusion elegantly solved the once-painful problem of cross-cloud authentication. Users can rely on their existing Azure AD credentials to seamlessly deploy to EKS or manage any AWS resource, while AWS issues short-lived credentials under the covers. This approach fosters better security (no static keys), improved compliance (centralized logging, ephemeral sessions), and a more streamlined user experience.

   Key Takeaways:

   1. SAML vs. OIDC: Both are valid. SAML is older, widely documented; OIDC is modern, often simpler for token-based flows.

   2. Short-Lived Credentials: Greatly reduce risk of credential sprawl or leftover access.

   3. Group-Based Role Mapping: Critical for advanced security. Use Azure AD groups to map to specific AWS roles.

   4. Implementation Effort: Typically a few hours to set up the bridging. Once done, ongoing overhead is minimal.

   5. User Experience: Developers log in once, obtain ephemeral tokens, and can run AWS/EKS tasks with no manual key copying.

   In an era of multi-cloud footprints and enterprise-level identity needs, such federation stands out as a robust pattern. As this case study shows, bridging Azure AD with AWS for short-lived EKS credentials not only simplifies day-to-day developer tasks but also elevates the overall security posture—paving the way for further expansions of cross-cloud identity in the future.