When our DevOps team launched a year ago, engineers relied on a legacy ADFS integration for AWS access. Under this setup, Active Directory groups were mapped directly to IAM roles; engineers simply logged into a SSO portal and were granted access to AWS Accounts.

However, this “automatically in” model created high-risk Standing Privileges, granting admin rights 24/7 regardless of actual need. Furthermore, any access beyond these pre-mapped roles required a manual incident request fulfilled by a human administrator which created bottlenecks.

 

The Security Shift

To address this, the central platform team integrated Entra ID with AWS IAM Identity Center. They created Permission Sets mapped to Entra ID groups, which functioned as managed roles across our AWS accounts. This established the foundation for our team to integrate these federated roles into the application.

This AWS article covers how this works at the lower level based

Key Components & Their Roles

The new architecture relies on several interconnected services:

• Entra ID (Identity Provider): Acts as the single source of truth for all user identities. It manages group memberships and serves as the portal where engineers trigger access requests.

• AWS Organizations: The structural foundation. It provides the multi-account framework that allows IAM Identity Center to manage access centrally.

• AWS IAM Identity Center: This acts as the access gateway for the organization.

  • Setup: The central team creates Permission Sets which Identity Center automatically deploys into AWS accounts as “empty shell” IAM roles.

  • The “Key” (Entra PIM): When a user requests access via Entra PIM, they obtain a temporary ‘key’ by becoming an active member of a specific Entra group for a defined duration.

  • The “Reception Desk” (Validation): When the user hits the AWS portal, Identity Center verifies their current groups with Entra ID. It then displays the accounts where that “Key” is valid.

• Privileged Identity Management (PIM): Handles “Just-in-Time” elevation. To gain access, an engineer selects a role in the Entra portal, provides a justification (e.g., Jira ticket), and passes MFA to activate eligibility. Once approved, permissions are live for a limited window before expiring.

• Permission Sets: Managed templates within AWS Identity Center that define specific IAM policies. These are assigned to Entra ID groups and applied to specific accounts within the AWS Organization, “boiling down” into the actual IAM roles users assume.

• Resource-Based Policies: Specifically for Dev and Test environments, we configured Lambda and API Gateway policies to allow these federated roles to “Invoke” services directly, ensuring security didn’t block developer velocity.

Entra PIM solution integrated with IAM Identity Center. Source: AWS Docs

 

The Solution: Integrating Entra ID PIM for the Application

Our focus was on ensuring our application components and developer workflows could seamlessly consume the new identity model.

A primary focus for our team was facilitating efficient testing and operations in lower environments. We implemented elevated access for these new federated roles specifically targeting AWS Lambda functions and API Gateway resources in our Dev and Test accounts. We utilized Resource-Based Policies to grant these federated roles the specific “Invoke” permissions required to test application logic and trigger API workflows directly, ensuring that the transition to PIM did not hinder development velocity.2. Transitioning PowerShell Workflows to AWS SSO

A significant technical hurdle was that the AWS Tools for PowerShell did not natively support the modern AWS SSO (IAM Identity Center) login flow. Unlike the AWS CLI, which has built-in commands like aws sso login to handle the browser-based handshake and token caching, the PowerShell modules at the time lacked equivalent cmdlets. This meant PowerShell couldn’t automatically refresh or recognize the SSO tokens generated by the CLI. We had to refactor our automation to bridge this gap, implementing custom Set-AWSCredential logic and “wrapper” functions to locate the CLI-cached tokens and inject them into our PowerShell sessions

 

Conclusion

Transitioning from ADFS to Entra ID PIM replaced high-risk “standing roles” with ephemeral, Just-in-Time eligibility. While the old model relied on 24/7 access and the hope that credentials remained secure, the new framework enforces MFA and business justifications for every elevation.

This shift doesn’t just reduce our attack surface; it changes our security culture from ‘trust by default’ to ‘verify on-demand,’ ensuring every privileged action is intentional and fully audited.

 

References: https://aws.amazon.com/blogs/security/implementing-just-in-time-privileged-access-to-aws-with-microsoft-entra-and-aws-iam-identity-center/