How to setup Corporate Identity Access at scale in AWS?

#aws #security #iam #cloudcomputing

Imagine a large enterprise with thousands of employees spread across multiple cross-functional teams. Managing access to AWS applications in such an environment can quickly become tedious—especially if you're relying solely on IAM users, IAM roles, and IAM policies to provision access.

These traditional IAM resources come with inherent limitations, such as role count restrictions, policy size limits, and the impracticality of managing access on a per-user basis. This manual process not only consumes time but also becomes increasingly unsustainable as the organization scales.

This is where AWS IAM Identity Center (formerly AWS SSO) comes in. It simplifies access management by allowing administrators to integrate their existing identity provider (such as Microsoft Entra ID, Okta, or Cognito Userpool) and automatically synchronize users and groups. This enables access provisioning at scale while reducing the overhead of manual configuration.

More details on automatic provisioning can be found in the AWS documentation.

You can also create and manage users directly within IAM Identity Center, if you don’t have an external identity provider.

Federate Access to Your Applications

Once your user directory is set up in IAM Identity Center, you can grant application access to users directly from the console.

Application Access

There are two types of applications that can be integrated:

AWS-Managed Applications

These applications are native to AWS and are maintained by AWS itself. They provide access to AWS services and features, and administrators configure access through the relevant AWS service consoles. They apply access rules in there as well. Multiple AWS services support this integration natively.

More detailes > HERE

Custom Applications

These are third-party or in-house applications that are either hosted on AWS or outside of it but need to access AWS resources on behalf of users.

More details > HERE

Trusted Identity Propagation

Trusted Identity Propagation is a feature of IAM Identity Center that enables your custom applications to access AWS resources with fine-grained, user-based access control.

These AWS resources are typically part of AWS-managed applications, and Trusted Identity Propagation allows custom applications to securely interact with them on behalf of a user.

More details > HERE

S3 Access Grants Use Case

Trusted Identity Propagation is supported across several AWS services, but for this blog, we’ll walk through setting it up using S3 Access Grants.

Supported usecase > HERE

In this scenario, S3 Access Grants acts as the AWS-managed application, while we simulate a custom application that uses an Amazon Cognito User Pool as both the identity provider (IdP) and OAuth 2.0 authorization server.

This setup demonstrates how TIP enables your application to make fine-grained, user-context-aware access requests to Amazon S3 securely and at scale.

Caution: TIP only works with OAuth 2.0 applications

Setup Guide

Import the IdP into IAM Identity Center

You can also create users manually in IAM Identity Center.

Note: User attribute mapping is important. Ensure that
attribute values match across both systems-for example,
username(Cognito) == username(Identity Center).

See example of IAM Identity Center user in below figure.
Set Trust Relationship with the OAuth 2.0 Server

Set up your custom application's OAuth 2.0 authorization server as a Trusted Token Issuer.
Follow the guide HERE

I did set up a Cognito Userpool for that purpose.
Create custom application in Identity Center

Register your custom app in IAM Identity Center and attach the previously defined Trusted Token Issuer.
Follow the guide HERE
Set up Trusted Identity Propagation

Configure which AWS-managed applications (like S3 Access Grants) your custom application can access, and specify the users or groups that are authorized.
Learn more HERE

Custom application is grnated access to S3 Access grants (AWS-managed application) in below figure.
Set up S3 Access Grants

Now, configure the S3 Access Grant for a desired S3 location. This enables an AWS-managed application for S3 Access Grants.
Follow the guide HERE

S3 Access Grant sample

Now, the setup is complete, let’s move on to the execution part.

Before diving in, it’s important to understand the concept of Identity-Enhanced IAM Role Sessions, which is a key prerequisite for Trusted Identity Propagation.

Identity Enhanced IAM Role Sessions

Whenever a custom application needs to access an AWS service or resource, it follows these steps:

Fetch an Identity Token:
The application contacts IAM Identity Center to exchange its JWT(IdToken) for a new JWT(IdToken) via the CreateTokenWithIAM API. This token contains the identity context of the currently signed-in user.
Assume an IAM Role:
The application then assumes an IAM role using the AssumeRole API. It attaches the identity context along with the request.
Access AWS Resources:
Using the returned temporary AWS credentials, the application accesses the AWS resource (e.g., S3 via Access Grants).
Audit and Monitoring via CloudTrail:
The associated AWS service (like S3) logs the user identity context in CloudTrail.

Example below

This enables auditing, monitoring, and debugging based on the actual user's identity, not just the application's role.

The diagram below illustrates this flow clearly:

Trusted Identity Propagation(TIP) IN Action

As the custom application accesses AWS resources using Identity-Enhanced IAM role credentials, the target AWS service intercepts each request and validates access based on the attached user identity context.

In our case, S3 Access Grants evaluates the request against the authorization rules defined and either ALLOWS or DENIES access accordingly.

See GetDataAccess API

This is the core of Trusted Identity Propagation—ensuring that access control decisions are made based on the original user's identity, not just the permissions of the application role.

The diagram below illustrates the complete design: