Оффлайн
- Регистрация
- 9 Май 2015
- Сообщения
- 1,483
- Баллы
- 155
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 (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 .
Once your user directory is set up in IAM Identity Center, you can grant application access to users directly from the console.
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.
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.
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.
Trusted Identity Propagation is supported across several AWS services, but for this blog, we’ll walk through setting it up using S3 Access Grants.
This setup demonstrates how TIP enables your application to make fine-grained, user-context-aware access requests to Amazon S3 securely and at scale.
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:
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.
The diagram below illustrates the complete design:
Sample Notebook
I’ve implemented the flow in a Jupyter notebook, which you can find . Feel free to fork it and set it up for your own experimentation.
If you encounter any issues during the setup, refer to the official documentation
That’s all for now. I hope this blog helps you implement scalable access for your AWS applications. Happy learning! ?
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 (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 .
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.
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.
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.
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.
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.
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.
Setup Guide
Import the IdP into IAM Identity Center
You can also create users manually in IAM 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
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
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
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
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 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 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.
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:
Sample Notebook
I’ve implemented the flow in a Jupyter notebook, which you can find . Feel free to fork it and set it up for your own experimentation.
If you encounter any issues during the setup, refer to the official documentation
That’s all for now. I hope this blog helps you implement scalable access for your AWS applications. Happy learning! ?