# Configure access to applications Application access With AWS IAM Identity Center, you can control who can have single sign-on access to your applications. Users get seamless access to these applications after they use their directory credentials to sign in. IAM Identity Center securely communicates with these applications through a trusted relationship between IAM Identity Center and the application's service provider. This trust can be created in different ways, depending on the application type. IAM Identity Center supports two application types: [AWS managed applications](awsapps.md) and [customer managed applications](customermanagedapps.md). AWS managed applications are configured directly from within the relevant application consoles or through the application APIs. Customer managed applications must be added to the IAM Identity Center console and configured with the appropriate metadata for both IAM Identity Center and the service provider. After you configure applications to work with IAM Identity Center, you can manage which users or groups access the applications. By default, no users are assigned to applications. You can also grant your employees access to the AWS Management Console for a specific AWS account in your organization. For more information, see [Configure access to AWS accounts](manage-your-accounts.md). **Topics** + [ # AWS managed applications ](awsapps.md) + [ # Customer managed applications ](customermanagedapps.md) + [ # Trusted identity propagation overview ](trustedidentitypropagation-overview.md) + [ # Setting up your own OAuth 2.0 application ](trustedidentitypropagation-using-customermanagedapps-setup.md) + [ # Rotate IAM Identity Center certificates ](managecerts.md) + [ # Understand application properties in the IAM Identity Center console ](appproperties.md) + [ # Assign user access to applications in the IAM Identity Center console ](assignuserstoapp.md) + [ # Remove user access to SAML 2.0 applications ](removeaccessfromapp.md) + [ # Map attributes in your application to IAM Identity Center attributes ](mapawsssoattributestoapp.md) # AWS managed applications AWS IAM Identity Center streamlines and simplifies the task of connecting your workforce users to AWS managed applications such as Kiro and Amazon Quick. With IAM Identity Center, you can connect your existing identity provider once and synchronize users and groups from your directory, or create and manage your users directly in IAM Identity Center. By providing one point of federation, IAM Identity Center eliminates the need to set up federation or user and group synchronization for each application and reduces your administrative effort. You also get a common [view of user and group assignments](howtoviewandchangepermissionset.md). For a table of AWS applications that work with IAM Identity Center, see [AWS managed applications that you can use with IAM Identity Center](awsapps-that-work-with-identity-center.md). ## Controlling access to AWS managed applications Controlling access to applications Access to AWS managed applications is controlled in two ways: + **Initial entry to the application** IAM Identity Center manages this through assignments to the application. By default, assignments are required for AWS managed applications. If you are an application administrator, you can choose whether to require assignments to an application. If assignments are required, when users sign in to the AWS access portal, only users who are assigned to the application directly or through a group assignment can view the application tile. If assignments aren't required, you can allow all IAM Identity Center users to enter the application. In this case, the application manages access to resources and the application tile is visible to all users who visit the AWS access portal. **Important** If you’re an IAM Identity Center administrator, you can use the IAM Identity Center console to remove assignments to AWS managed applications. Before you remove assignments, we recommend that you coordinate with the application administrator. You should also coordinate with the application administrator if you plan to modify the setting that determines whether assignments required, or automate application assignments. + **Access to application resources** The application manages this through independent resource assignments that it controls. AWS managed applications provide an administrative user interface that you can use to manage access to application resources. For example, Quick administrators can assign users to access dashboards based on their group membership. Most AWS managed applications also provide an AWS Management Console experience that enables you to assign users to the application. The console experience for these applications might integrate both functions, to combine user assignment capabilities with the ability to manage access to application resources. ## Sharing identity information ### Considerations for sharing identity information in AWS accounts IAM Identity Center supports most commonly used attributes across applications. These attributes include first and last name, phone number, email address, address, and preferred language. Carefully consider which applications and which accounts can use this personally identifiable information. You can control access to this information in either of the following ways: + You can choose to enable access in only the AWS Organizations management account or in all accounts in AWS Organizations. + Alternatively, you can use service control policies (SCPs) to control which applications can access the information in which accounts in AWS Organizations. For example, if you enable access in the AWS Organizations management account only, then applications in member accounts have no access to the information. However, if you enable access in all accounts, you can use SCPs to disallow access by all applications except those you want to permit. Service control policies are a feature of AWS Organizations. For instructions on attaching an SCP, see [Attaching and detaching service control policies](/organizations/latest/userguide/orgs_manage_policies_scps_attach.html) in the *AWS Organizations User Guide.* ### Configuring IAM Identity Center to share identity information IAM Identity Center provides an identity store that contains user and group attributes, excluding sign-in credentials. You can use either of the following methods to keep the users and groups in your IAM Identity Center identity store updated: + Use the IAM Identity Center identity store as your main identity source. If you choose this method, you manage your users, their sign-in credentials, and groups from within the IAM Identity Center console or AWS Command Line Interface (AWS CLI). For more information, see [Manage users in the Identity Center directory](manage-your-identity-source-sso.md). + Set up provisioning (synchronization) of users and groups coming from either of the following identity sources to your IAM Identity Center identity store: + **Active Directory** – For more information, see [Microsoft AD directory](manage-your-identity-source-ad.md). + **External identity provider** – For more information, see [External identity providers](manage-your-identity-source-idp.md). If you choose this provisioning method, you continue managing your users and groups from within your identity source, and those changes are synchronized to the IAM Identity Center identity store. Whichever identity source you choose, IAM Identity Center can share the user and group information with AWS managed applications. That way, you can connect an identity source to IAM Identity Center once and then share identity information with multiple applications in the AWS Cloud. This eliminates the need to independently set up federation and identity provisioning with each application. This sharing feature also makes it easy to give your users access to many applications in different AWS accounts. ## Constraining the use of AWS managed applications When you first enable IAM Identity Center, it becomes available as an identity source for AWS managed applications across all accounts in your AWS Organizations. To constrain applications, you must implement service control policies (SCPs). SCPs are a feature of AWS Organizations that you can use to centrally control the maximum permissions that identities (users and roles) in your organization can have. You can use SCPs to block access to the IAM Identity Center user and group information and to prevent the application from being started, except in designated accounts. For more information, see [Service control policies (SCPs)](https://docs.aws.amazon.com//organizations/latest/userguide/orgs_manage_policies_scps.html) in the *AWS Organizations User Guide.* The following SCP example blocks access to the IAM Identity Center user and group information and prevents the application from being started, except in designated accounts (111111111111 and 222222222222): ``` { "Sid": "DenyIdCExceptInDesignatedAWSAccounts", "Effect": "Deny", "Action": [ "identitystore:*", "sso:*", "sso-directory:*", "sso-oauth:*" ], "Resource": "*", "Condition": { "StringNotEquals": { "aws:PrincipalAccount": [ "111111111111", "222222222222" ] } } } ``` # AWS managed applications that you can use with IAM Identity Center Applications that you can use with IAM Identity Center IAM Identity Center lets you connect your existing identity source or create users once. This enables application administrators to manage access to the following AWS managed applications without separate federation or user and group synchronization. All of the AWS managed applications in the following table integrate with [organization instances of IAM Identity Center](organization-instances-identity-center.md). The table also provides information about the following for a supported AWS managed application: + Whether the application also integrates with account instances of IAM Identity Center + Whether the application can enable trusted identity propagation through IAM Identity Center + Whether the application supports IAM Identity Center configured with a customer managed KMS key + Whether the application supports deployment in additional Regions of IAM Identity Center **Note** Applications that support deployment in additional Regions of IAM Identity Center also support IAM Identity Center configured with a customer managed KMS key. Every AWS managed application listed here supports deployment in the primary Region. For more information, see [Deploying and managing AWS managed applications across multiple AWS Regions](multi-region-application-use.md#multi-region-aws-managed-applications). **AWS managed applications that integrate with IAM Identity Center** | AWS managed application | Integrated with [account instances of IAM Identity Center](account-instances-identity-center.md) | Enables [trusted identity propagation](trustedidentitypropagation-overview.md) through IAM Identity Center | Supports IAM Identity Center configured with a [customer managed KMS key](encryption-at-rest.md) | Supports deployment in [additional Regions of IAM Identity Center](multi-region-iam-identity-center.md) | | --- | --- | --- | --- | --- | | Amazon Athena SQL | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/success_icon.svg) Yes | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/success_icon.svg) Yes | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/success_icon.svg) Yes | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/success_icon.svg) Yes | | Amazon CodeCatalyst | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/success_icon.svg) Yes | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/negative_icon.svg) No | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/success_icon.svg) Yes | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/negative_icon.svg) No | | Amazon DataZone | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/success_icon.svg) Yes | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/success_icon.svg) Yes | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/success_icon.svg) Yes | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/negative_icon.svg) No | | Amazon EKS Capabilities | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/success_icon.svg) Yes | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/success_icon.svg) Yes | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/success_icon.svg) Yes | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/negative_icon.svg) No | | Amazon EMR on EC2 | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/success_icon.svg) Yes | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/success_icon.svg) Yes | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/success_icon.svg) Yes | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/negative_icon.svg) No | | Amazon EMR on EKS | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/success_icon.svg) Yes | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/success_icon.svg) Yes | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/success_icon.svg) Yes | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/negative_icon.svg) No | | Amazon EMR Serverless | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/success_icon.svg) Yes | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/success_icon.svg) Yes | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/negative_icon.svg) Yes | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/negative_icon.svg) No | | Amazon EMR Studio | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/success_icon.svg) Yes | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/success_icon.svg) Yes | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/success_icon.svg) Yes | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/negative_icon.svg) No | | Amazon Kendra | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/negative_icon.svg) No | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/negative_icon.svg) No | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/success_icon.svg) Yes | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/negative_icon.svg) No | | Amazon Managed Grafana | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/negative_icon.svg) No | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/negative_icon.svg) No | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/negative_icon.svg) Yes | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/negative_icon.svg) No | | Amazon Monitron | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/negative_icon.svg) No | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/negative_icon.svg) No | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/negative_icon.svg) No | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/negative_icon.svg) No | | Amazon OpenSearch Service | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/success_icon.svg) Yes | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/success_icon.svg) Yes | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/success_icon.svg) Yes | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/negative_icon.svg) No | | Amazon OpenSearch Service Serverless Service | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/success_icon.svg) Yes | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/success_icon.svg) Yes | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/success_icon.svg) Yes | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/negative_icon.svg) No | | Amazon Q Business | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/success_icon.svg) Yes | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/success_icon.svg) Yes | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/success_icon.svg) Yes | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/negative_icon.svg) No | | Amazon Quick | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/success_icon.svg) Yes | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/success_icon.svg) Yes | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/success_icon.svg) Yes | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/negative_icon.svg) No | | Amazon Redshift | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/success_icon.svg) Yes2 | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/success_icon.svg) Yes | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/negative_icon.svg) Yes | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/success_icon.svg) Yes | | Amazon S3 Access Grants | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/success_icon.svg) Yes | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/success_icon.svg) Yes | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/success_icon.svg) Yes | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/success_icon.svg) Yes | | Amazon SageMaker Studio | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/negative_icon.svg) No | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/success_icon.svg) Yes | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/negative_icon.svg) Yes | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/negative_icon.svg) No | | Amazon SageMaker Unified Studio | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/success_icon.svg) Yes | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/success_icon.svg) Yes | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/success_icon.svg) Yes | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/negative_icon.svg) No | | Amazon WorkMail | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/success_icon.svg) Yes | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/success_icon.svg) Yes | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/success_icon.svg) Yes | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/negative_icon.svg) No | | Amazon WorkSpaces | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/success_icon.svg) Yes | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/negative_icon.svg) No | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/negative_icon.svg) Yes | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/negative_icon.svg) No | | Amazon WorkSpaces Secure Browser | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/negative_icon.svg) No | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/negative_icon.svg) No | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/success_icon.svg) Yes | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/negative_icon.svg) No | | AWS App Studio | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/success_icon.svg) Yes | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/negative_icon.svg) No | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/negative_icon.svg) No | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/negative_icon.svg) No | | AWS Deadline Cloud | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/success_icon.svg) Yes | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/negative_icon.svg) No | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/negative_icon.svg) Yes | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/success_icon.svg) Yes | | AWS Glue | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/success_icon.svg) Yes | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/success_icon.svg) Yes | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/success_icon.svg) Yes | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/negative_icon.svg) No | | AWS IoT Events | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/negative_icon.svg) No | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/negative_icon.svg) No | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/negative_icon.svg) No | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/negative_icon.svg) No | | AWS IoT SiteWise | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/negative_icon.svg) No | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/negative_icon.svg) No | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/negative_icon.svg) No | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/negative_icon.svg) No | | AWS Lake Formation | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/success_icon.svg) Yes | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/success_icon.svg) Yes | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/success_icon.svg) Yes | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/success_icon.svg) Yes | | AWS re:Post Private | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/success_icon.svg) Yes | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/negative_icon.svg) No | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/success_icon.svg) Yes | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/negative_icon.svg) No | | AWS Supply Chain | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/success_icon.svg) Yes | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/negative_icon.svg) No | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/success_icon.svg) Yes | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/negative_icon.svg) No | | AWS Systems Manager | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/negative_icon.svg) No | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/negative_icon.svg) No | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/success_icon.svg) Yes | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/success_icon.svg) Yes - Fleet Manager Remote Desktop | | AWS Transfer Family web apps | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/success_icon.svg) Yes | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/success_icon.svg) Yes | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/success_icon.svg) Yes | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/negative_icon.svg) No | | AWS Transform | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/success_icon.svg) Yes | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/negative_icon.svg) No | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/success_icon.svg) Yes | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/negative_icon.svg) No | | AWS Verified Access | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/negative_icon.svg) No | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/negative_icon.svg) No | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/success_icon.svg) Yes | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/negative_icon.svg) No | | Kiro | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/success_icon.svg) Yes1 | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/success_icon.svg) Yes | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/success_icon.svg) Yes | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/negative_icon.svg) No | | Multi-party approval | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/negative_icon.svg) No | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/success_icon.svg) Yes | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/success_icon.svg) Yes | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/negative_icon.svg) No | | OpenSearch user interface (Dashboards) | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/success_icon.svg) Yes | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/success_icon.svg) Yes | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/success_icon.svg) Yes | ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/negative_icon.svg) No | 1 For Kiro, account instances of IAM Identity Center are supported unless your users require access to the full set of Kiro features on AWS websites. For more information, see [Setting up Kiro](https://docs.aws.amazon.com/amazonq/latest/qdeveloper-ug/getting-started-q-dev.html) in the *Kiro User Guide*. 2 For Amazon Redshift, account instances of IAM Identity Center are supported except for applications like Query Editor v2 that require permission sets, which are not supported by account instances. **Note** Some AWS services such as Amazon Connect and AWS Client VPN are not listed in this table although you can use them with IAM Identity Center. This is because they integrate with IAM Identity Center exclusively using SAML and are therefore categorized as [customer managed applications](customermanagedapps.md). # Quick start: Setting up IAM Identity Center to test AWS managed applications Setting up IAM Identity Center to test AWS managed applications If your administrator hasn’t already provided you with access to IAM Identity Center, you can use the steps in this topic to set up IAM Identity Center to test AWS managed applications. You'll learn how to enable IAM Identity Center, create a user directly in IAM Identity Center, and assign that user to an AWS managed application. This topic provides quick-start steps on how to enable IAM Identity Center in either of the following ways: + **With AWS Organizations** – If you choose this option, an *organization instance* of IAM Identity Center is created. + **Only in your specific AWS account** – If you choose this option, an *account instance* of IAM Identity Center is created. For information about these instance types, see [Organization and account instances of IAM Identity Center](identity-center-instances.md). ## Prerequisites Before you enable IAM Identity Center, confirm the following: + **You have an AWS account** – If you do not have an AWS account, see [Getting started with an AWS account](https://docs.aws.amazon.com//accounts/latest/reference/getting-started.html) in the *AWS Account Management Reference Guide.* + **The AWS managed application works with IAM Identity Center** – Review the list of [AWS managed applications that you can use with IAM Identity Center](awsapps-that-work-with-identity-center.md) to confirm that the AWS managed application you want to test works with IAM Identity Center. + **You’ve reviewed Regional considerations** – Make sure that the AWS managed application you want to test is supported in the AWS Region where you enable IAM Identity Center. For more information, see the documentation for the AWS managed application. **Note** You must deploy your AWS managed application in the same Region where you plan to enable IAM Identity Center. ## Setting up an organization instance of IAM Identity Center to test AWS managed applications Set up an organization instance to test AWS managed applications **Note** This topic describes how to enable IAM Identity Center with AWS Organizations, which is the recommended way to enable IAM Identity Center. **Confirm your permissions** To enable IAM Identity Center with AWS Organizations, you must sign in to the AWS Management Console as either of the following: + A user with administrative permissions in the AWS account where IAM Identity Center will be enabled with AWS Organizations. + The root user (not recommended unless no other administrative users exist). **Important** The root user has access to all AWS services and resources in the account. As a security best practice, unless you have no other credentials, do not use your account's root credentials to access AWS resources. These credentials provide unrestricted account access and are difficult to revoke. ### Step 1. Enable IAM Identity Center with AWS Organizations 1. Do one of the following to sign in to the AWS Management Console. + **New to AWS (root user)** – Sign in as the account owner by choosing **Root user** and entering your AWS account email address. On the next page, enter your password. + **Already using AWS with a standalone AWS account (IAM credentials)** – Sign in using your IAM credentials with administrative permissions. 1. On the AWS Management Console Home page, select the IAM Identity Center service or navigate to the [IAM Identity Center console](https://console.aws.amazon.com/singlesignon). 1. Choose **Enable**, and enable IAM Identity Center with AWS Organizations. When you do this, you’re creating an [organization instance](organization-instances-identity-center.md) of IAM Identity Center. ### Step 2. Create an administrative user in IAM Identity Center This procedure describes how to create a user directly in the built-in Identity Center directory. This directory isn't connected to any other directory that your administrator might use to manage workforce users. After you create the user in IAM Identity Center, you'll specify new credentials for this user. When you sign in as this user to test your AWS managed application, you'll sign in with the new credentials, not with any existing credentials that you use to access corporate resources. **Note** We recommend that you use this method for creating users for testing purposes only. 1. In the navigation pane of the IAM Identity Center console, choose **Users**, and then choose **Add user**. 1. Follow the guidance in the console to add the user. Keep **Send an email to this user with password setup instructions** selected and make sure that you specify an email address to which you have access. 1. In the navigation pane, choose AWS accounts, select the check box next to your account, and choose **Assign users or groups**. 1. Choose the **Users** tab, select the check box next to the user that you just added, and choose **Next**. 1. Choose **Create permission set**, and follow the guidance in the console to create the `AdministratorAccess` predefined permission set. 1. When you’re done, the new permission set appears in the list. Close the **Permission sets** tab in your browser window, return to the **Assign users and groups** tab, and choose the refresh icon next to **Create permission set**. 1. On the **Assign users and groups** browser tab, the new permission set appears in the list. Select the check box next to the name of the permission set, choose **Next**, and then choose **Submit**. 1. Sign out of the console. ### Step 3. Sign in to the AWS access portal as an administrative user The AWS access portal is a web portal that provides the user that you created with access to the AWS Management console. Before you can sign in to the AWS access portal, you must accept the invitation to join IAM Identity Center and activate your user credentials. 1. Check your email for the subject line **Invitation to join AWS IAM Identity Center**. 1. Choose **Accept invitation**, and follow the guidance on the sign-up page to set a new password, sign in, and register an MFA device for your user. 1. After you register your MFA device, the AWS access portal opens. 1. In the AWS access portal, select your AWS account and choose **AdministratorAccess**. You are redirected to the AWS Management Console. ### Step 4. Configure the AWS managed application to use IAM Identity Center 1. While you are signed in to the AWS Management Console, open the console for the AWS managed application that you plan to use. 1. Follow the guidance in the console to configure the AWS managed application to use IAM Identity Center. During this process, you can assign the user that you created to the application. ## Setting up an account instance of IAM Identity Center to test AWS managed applications Set up an account instance to test AWS managed applications **Note** An account instance of IAM Identity Center limits your deployment to a single AWS account. You must enable this instance in the same AWS Region as the AWS application you want to test. **Confirm your app** All AWS managed applications that work with IAM Identity Center can be used with organization instances of IAM Identity Center. However, only some of these applications can be used with account instances of IAM Identity Center. Review the list of [AWS managed applications that you can use with IAM Identity Center](awsapps-that-work-with-identity-center.md). ### Step1. Enable an account instance of IAM Identity Center 1. Do one of the following to sign in to the AWS Management Console. + **New to AWS (root user)** – Sign in as the account owner by choosing **Root user** and entering your AWS account email address. On the next page, enter your password. + **Already using AWS with a standalone AWS account (IAM credentials)** – Sign in using your IAM credentials with administrative permissions. 1. On the AWS Management Console Home page, select the IAM Identity Center service or navigate to the [IAM Identity Center console](https://console.aws.amazon.com/singlesignon). 1. Choose **Enable**. 1. On the **Enable IAM Identity Center with AWS Organizations** page, choose **enable an account instance of IAM Identity Center**. 1. On the **Enable account instance of IAM Identity Center** page, review the information and optionally add tags that you want to associate with this account instance. Then choose **Enable**. ### Step 2. Create a user in IAM Identity Center This procedure describes how to create a user directly in the built-in Identity Center directory. This directory isn't connected to any other directory that your administrator might use to manage workforce users. After you create the user in IAM Identity Center, you'll specify new credentials for this user. When you sign in as this user to test your AWS managed application, you'll sign in with the new credentials. The new credentials will not allow you to access other corporate resources. **Note** We recommend that you use this method for creating users for testing purposes only. 1. In the navigation pane of the IAM Identity Center console, choose **Users**, and then choose **Add user**. 1. Follow the guidance in the console to add the user. Keep **Send an email to this user with password setup instructions** selected and make sure that you specify an email address to which you have access. 1. Sign out of the console. ### Step 3. Sign in to the AWS access portal as your IAM Identity Center user The AWS access portal is a web portal that provides the user that you created with access to the AWS Management console. Before you can sign in to the AWS access portal, you must accept the invitation to join IAM Identity Center and activate your user credentials. 1. Check your email for the subject line **Invitation to join AWS IAM Identity Center**. 1. Choose **Accept invitation**, and follow the guidance on the sign-up page to set a new password, sign in, and register an MFA device for your user. 1. After you register your MFA device, the AWS access portal opens. When applications are available to you, you’ll find them under the **Applications** tab. **Note** AWS applications that support account instances allow users to sign in to applications without requiring additional permissions. Therefore, the **Accounts** tab will remain empty. ### Step 4. Configure the AWS managed application to use IAM Identity Center 1. While you are signed in to the AWS Management Console, open the console for the AWS managed application that you plan to use. 1. Follow the guidance in the console to configure the AWS managed application to use IAM Identity Center. During this process, you can assign the user that you created to the application. # Viewing and changing details about an AWS managed application Viewing and changing application details After you connect an AWS managed application to IAM Identity Center by using the console or APIs for the application, the application is registered with IAM Identity Center. After an application is registered with IAM Identity Center, you can view and change details about the application in the IAM Identity Center console. Information about the application includes whether user and group assignments are required, and if applicable, assigned users and groups and trusted applications for identity propagation. For information about trusted identity propagation, see [Trusted identity propagation overview](trustedidentitypropagation-overview.md). **To view and change information about an AWS managed application in the IAM Identity Center console** 1. Open the [IAM Identity Center console](https://console.aws.amazon.com/singlesignon). 1. Choose **Applications**. 1. Choose the **AWS managed** tab. 1. Choose the link for the managed application you'd like to open and view. 1. If you want to change information about an AWS managed application, choose **Action** and then choose **Edit Details**. 1. You can change the application's display name, description, as well as the user and group assignment method. 1. To change the display name, enter the desired name in the **Display name** field and choose **Save changes**. 1. To change the description, enter the desired description in the **Description** field and choose **Save changes**. 1. To change the user and group assignment method, make the desired change and choose **Save changes**. For more information, see [Users, groups, and provisioning in IAM Identity Center](users-groups-provisioning.md). # Disabling an AWS managed application To prevent users from authenticating to an AWS managed application, you can disable the application in the IAM Identity Center console. **To disable an AWS managed application** 1. Open the [IAM Identity Center console](https://console.aws.amazon.com/singlesignon). 1. Choose **Applications**. 1. On the **Applications** page, under **AWS managed applications**, choose the application that you want to disable. 1. With the application selected, choose **Actions**, and then choose **Disable**. 1. In the **Disable application** dialog box, choose **Disable**. 1. In the **AWS managed applications** list, the application status appears as **Inactive**. **Note** If an AWS managed application is disabled, you can restore users abilty to authenticate to the application by choosing **Actions** and then **Enable**. # Enabling identity-enhanced console sessions An identity-enhanced session for the console enhances a user's AWS console session by providing some additional user context to personalize that user's experience. This capability is currently supported for Kiro Pro users of [Kiro on AWS apps and websites](https://docs.aws.amazon.com/amazonq/latest/qdeveloper-ug/q-on-aws.html). You can enable identity-enhanced console sessions without making any changes to existing access patterns or federation into the AWS console. If your users sign in to the AWS console with IAM (for example, if they sign in as IAM users or through federated access with IAM), they can continue using these methods. If your users sign in to the AWS access portal, they can continue using their IAM Identity Center user credentials. **Topics** + [ ## Prerequisites and considerations ](#prereqs-and-considerations) + [ ## How to enable identity-enhanced-console sessions ](#enable-identity-enhanced-sessions-q) + [ ## How identity-enhanced console sessions work ](#how-identity-enhanced-sessions-work) ## Prerequisites and considerations Before you enable identity-enhanced console sessions, review the following prerequisites and considerations: + If your users access Kiro on AWS apps and websites through an Kiro Pro subscription, you must enable identity-enhanced console sessions. **Note** Kiro users can access Kiro without identity-enhanced sessions, but they will not have access to their Kiro Pro subscriptions. + Identity-enhanced console sessions require an [organization instance](organization-instances-identity-center.md) of IAM Identity Center. + Integration with Kiro isn't supported if you enable IAM Identity Center in an opt-in AWS Region. + To enable identity-enhanced console sessions, you must have the following permissions: + `sso:CreateApplication` + `sso:GetSharedSsoConfiguration` + `sso:ListApplications` + `sso:PutApplicationAssignmentConfiguration` + `sso:PutApplicationAuthenticationMethod` + `sso:PutApplicationGrant` + `sso:PutApplicationAccessScope` + `signin:CreateTrustedIdentityPropagationApplicationForConsole` + `signin:ListTrustedIdentityPropagationApplicationsForConsole` + To enable your users to use identity-enhanced console sessions, you must grant them the `sts:setContext` permission in an identity-based policy. For information, see [Granting users permissions to use identity-enhanced console sessions](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_control-access_sts-setcontext.html). ## How to enable identity-enhanced-console sessions You can enable identity-enhanced console sessions in the Kiro console or in the IAM Identity Center console. **Enable identity-enhanced console sessions in the Kiro console** Before you enable identity-enhanced console sessions, you must have an organization instance of IAM Identity Center with an identity source connected. If you've already configured IAM Identity Center, skip to step 3. 1. Open the IAM Identity Center console. Choose **Enable**, and create an organization instance of IAM Identity Center. For information, see [Enable IAM Identity Center](enable-identity-center.md). 1. Connect your identity source to IAM Identity Center and provision users into IAM Identity Center. You can connect your existing identity source to IAM Identity Center or use the Identity Center directory if you are not already using another identity source. For more information, see [IAM Identity Center identity source tutorials](tutorials.md). 1. After you finish setting up IAM Identity Center, open the Kiro console and follow the steps in [Subscriptions](https://docs.aws.amazon.com/amazonq/latest/qdeveloper-ug/q-admin-setup-subscribe-management-account.html) in the *Kiro User Guide*. Make sure to enable identity-enhanced console sessions. **Note** If you do not have sufficient permissions to enable identity-enhanced console sessions, you might need to ask an IAM Identity Center administrator to perform this task for you in the IAM Identity Center console. For more information, see the next procedure. **Enable identity-enhanced console sessions in the IAM Identity Center console** If you are an IAM Identity Center administrator, you might be asked by another administrator to enable identity-enhanced console sessions in the IAM Identity Center console. 1. Open the IAM Identity Center console. 1. In the navigation pane, choose **Settings**. 1. Under **Enable identity-enhanced sessions**, choose **Enable**. 1. In the second message, choose **Enable**. 1. After you finish enabling identity-enhanced console sessions, a confirmation message appears at the top of the **Settings** page. 1. In the **Details** section, the status for **Identity-enhanced sessions** is **Enabled**. ## How identity-enhanced console sessions work IAM Identity Center enhances a user's current console session to include the active IAM Identity Center user's ID and the IAM Identity Center session ID. Identity-enhanced console sessions include the following three values: + **Identity store user ID** ([identitystore:UserId](condition-context-keys-sts-idc.md#condition-keys-identity-store-user-id)) - This value is used to uniquely identify a user in the identity source that is connected to IAM Identity Center. + **Identity store directory ARN** ([identitystore:IdentityStoreArn](condition-context-keys-sts-idc.md#condition-keys-identity-store-arn)) - This value is the ARN of the identity store that is connected to IAM Identity Center, and where you can look up attributes for `identitystore:UserId`. + **IAM Identity Center session ID** - This value indicates whether the user's IAM Identity Center session is still valid. The values are the same, but obtained in different ways and added at different points of the process, depending on how the user signs in: + **IAM Identity Center (AWS access portal)**: In this case, the user's identity store user ID and ARN values are already provided in the active IAM Identity Center session. IAM Identity Center enhances the current session by adding only the session ID. + **Other sign-in methods**: If the user signs in to AWS as an IAM user, with an IAM role, or as a federated user with IAM, none of these values are provided. IAM Identity Center enhances the current session by adding the identity store user ID, identity store directory ARN, and the session ID. # Customer managed applications IAM Identity Center acts as a central identity service to your workforce users and groups. If you already use an identity provider (IdP), IAM Identity Center can integrate with your IdP so that you can provision your users and groups into IAM Identity Center and use your IdP for authentication. With a single connection, IAM Identity Center represents your IdP in front of multiple AWS services and enables your OAuth 2.0 applications to request access to data in these services on behalf of your users. You can also use IAM Identity Center to assign your users access to [SAML 2.0](https://wiki.oasis-open.org/security) applications. This includes AWS services such as Amazon Connect and AWS Client VPN, which integrate with IAM Identity Center exclusively using SAML and are therefore categorized as customer managed applications. + If your application supports **JSON Web Tokens (JWTs)**, you can use the trusted identity propagation feature of IAM Identity Center to enable your application to request access to data in AWS services on behalf of your users. Trusted identity propagation is built on the OAuth 2.0 Authorization Framework and includes an option for applications to exchange identity tokens that come from an external OAuth 2.0 authorization server for tokens issued by IAM Identity Center and recognized by AWS services. For more information, see [Trusted identity propagation use cases](trustedidentitypropagation-integrations.md). + If your application supports **SAML 2.0**, you can connect it to an [organization instance of IAM Identity Center](identity-center-instances.md). You can use IAM Identity Center to assign access to your SAML 2.0 application. **Note** When integrating customer managed applications with an IAM Identity Center instance that uses a [customer managed KMS key](encryption-at-rest.md), verify whether the application invokes IAM Identity Center service APIs to confirm whether the application needs KMS key permissions. Follow the guidance for granting KMS key permissions to custom workflows in the IAM Identity Center User Guide's [ baseline KMS key policies](baseline-KMS-key-policy.md#baseline-kms-key-policy-statements-for-use-of-custom-workflows-with-iam-identity-center). **Topics** + [ # Single sign-on access to SAML 2.0 and OAuth 2.0 applications ](customermanagedapps-saml2-oauth2.md) + [ # Setting up customer managed SAML 2.0 applications ](customermanagedapps-saml2-setup.md) # Single sign-on access to SAML 2.0 and OAuth 2.0 applications SAML 2.0 and OAuth 2.0 applications IAM Identity Center enables you to provide your users with single sign-on access to SAML 2.0 or OAuth 2.0 applications. The following topics provide a high-level overview of SAML 2.0 and OAuth 2.0. **Topics** + [ ## SAML 2.0 ](#samlfederationconcept) + [ ## OAuth 2.0 ](#oidc-concept) ## SAML 2.0 SAML 2.0 is an industry standard used for securely exchanging SAML assertions that pass information about a user between a SAML authority (called an identity provider or IdP), and a SAML 2.0 consumer (called a service provider or SP). IAM Identity Center uses this information to provide federated single sign-on access for those users who are authorized to use applications within the AWS access portal. **Note** IAM Identity Center does not support validating signatures of incoming SAML authentication requests from SAML applications. ## OAuth 2.0 OAuth 2.0 is a protocol that allows applications to access and share user data securely without sharing passwords. This capability provides a secure and standardized way for users to allow applications access to their resources. Access is facilitated by different OAuth 2.0 grant flows. IAM Identity Center enables applications that run on public clients to retrieve temporary credentials to access AWS accounts and services programmatically on behalf of their users. Public clients are typically desktops, laptops, or other mobile devices that are used to run applications locally. Examples of AWS applications that run on public clients include the AWS Command Line Interface (AWS CLI), AWS Toolkit, and AWS Software Development Kits (SDKs). To enable these applications to obtain credentials, IAM Identity Center supports portions of the following OAuth 2.0 flows: + Authorization Code Grant with Proof Key for Code Exchange (PKCE) ([RFC 6749](https://www.rfc-editor.org/rfc/rfc6749#section-4.1) and [RFC 7636](https://www.rfc-editor.org/rfc/rfc7636)) + Device Authorization Grant ([RFC 8628](https://datatracker.ietf.org/doc/html/rfc8628)) **Note** These grant types can be used only with AWS services that support this capability. These services may not support this grant type in all AWS Regions. Refer to the documentation of relevant AWS services for regional differences. OpenID Connect (OIDC) is an authentication protocol that is based on the OAuth 2.0 Framework. OIDC specifies how to use OAuth 2.0 for authentication. Through the [IAM Identity Center OIDC service APIs](https://docs.aws.amazon.com/singlesignon/latest/OIDCAPIReference/API_Operations.html), an application registers an OAuth 2.0 client and uses one of these flows to obtain an access token that provides permissions to IAM Identity Center protected APIs. An application specifies [access scopes](https://docs.aws.amazon.com/singlesignon/latest/userguide/customermanagedapps-saml2-oauth2.html#scopes-oidc) to declare its intended API user. After you, as the IAM Identity Center administrator, configure your identity source, your application end users must complete a sign-in process, if they have not already done so. Your end users must then provide their consent to allow the application to make API calls. These API calls are made using the users' permissions. In response, IAM Identity Center returns an access token to the application that contains the access scopes to which the users consented. ### Using an OAuth 2.0 grant flow OAuth 2.0 grant flows are only available through AWS managed applications that support the flows. To use an OAuth 2.0 flow, your instance of IAM Identity Center and any supported AWS managed applications that you use must be deployed in a single AWS Region. Refer to the documentation for each AWS service to determine the regional availability of AWS managed applications and the instance of IAM Identity Center that you want to use. To use an application that uses an OAuth 2.0 flow, the end user must enter the URL where the application will connect and register with your instance of IAM Identity Center. Depending on the application, as the administrator, you must provide your users with the **AWS access portal URL** or the **Issuer URL** of your instance of IAM Identity Center. You can find these two settings on the [IAM Identity Center console](https://console.aws.amazon.com/singlesignon/) **Settings** page. For additional information about configuring a client application, refer to that application’s documentation. The end user experience for signing into an application and providing consent depends on whether the application uses the [Authorization Code Grant with PKCE](#auth-code-grant-pkce) or [Device Authorization Grant](#device-auth-grant). #### Authorization Code Grant with PKCE This flow is used by applications that run on a device that has a browser. 1. A browser window opens. 1. If the user has not authenticated, the browser redirects them to complete user authentication. 1. After authentication, the user is presented with a consent screen that displays the following information: + The name of the application + The access scopes that the application is requesting consent to use 1. The user can cancel the consent process or they can give their consent and the application proceeds with access based on the user’s permissions. #### Device Authorization Grant This flow can be used by applications that run on a device with or without a browser. When the application initiates the flow, the application presents a URL and a user code that the user must verify later in the flow. The user code is necessary because the application that initiates the flow might be running on a different device than the device on which the user provides consent. The code ensures that the user is consenting to the flow they initiated on the other device. **Note** If you have clients using `device.sso.region.amazonaws.com`, you must update your authorization flow to use Proof Key for Code Exchange (PKCE). For more information, see [Configuring IAM Identity Center authentication with the AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-sso.html) in the *AWS Command Line Interface User Guide*. 1. When the flow initiates from a device with a browser, a browser window opens. When the flow initiates from a device without a browser, the user must open a browser on a different device and go to the URL that the application presented. 1. In either case, if the user has not authenticated, the browser redirects them to complete user authentication. 1. After authentication, the user is presented with a consent screen that displays the following information: + The name of the application + The access scopes that the application is requesting consent to use + The user code that the application presented to the user 1. The user can cancel the consent process or they can give their consent and the application proceeds with access based on the user’s permissions. ### Access scopes A *scope* defines the access for a service that can be accessed through an OAuth 2.0 flow. Scopes are a way for the service, also called a resource server, to group permissions related to actions and the service resources, and they specify the coarse-grained operations that OAuth 2.0 clients can request. When an OAuth 2.0 client registers with the [IAM Identity Center OIDC service](https://docs.aws.amazon.com/singlesignon/latest/OIDCAPIReference/Welcome.html), the client specifies the scopes to declare its intended actions, for which the user must provide consent. OAuth 2.0 clients use `scope` values as defined in [section 3.3 of OAuth 2.0 (RFC 6749)](https://www.rfc-editor.org/rfc/rfc6749.html#section-3.3) to specify what permissions are being requested for an access token. Clients can specify a maximum of 25 scopes when requesting an access token. When a user provides consent during an Authorization Code Grant with PKCE or Device Authorization Grant flow, IAM Identity Center encodes the scopes into the access token it returns. AWS adds scopes to IAM Identity Center for supported AWS services. The following table lists the scopes that the IAM Identity Center OIDC service supports when you register a public client. #### Access scopes supported by the IAM Identity Center OIDC service when registering a public client **** | Scope | Description | Services supported by | | --- | --- | --- | | sso:account:access | Access IAM Identity Center managed accounts and permission sets. | IAM Identity Center | | codewhisperer:analysis | Enable access to Kiro code analysis. | AWS Builder ID and IAM Identity Center | | codewhisperer:completions | Enable access to Kiro inline code suggestions. | AWS Builder ID and IAM Identity Center | | codewhisperer:conversations | Enable access to Kiro chat. | AWS Builder ID and IAM Identity Center | | codewhisperer:taskassist | Enable access to Kiro Agent for software development. | AWS Builder ID and IAM Identity Center | | codewhisperer:transformations | Enable access to Kiro Agent for code transformation. | AWS Builder ID and IAM Identity Center | | codecatalyst:read\$1write | Read and write to your Amazon CodeCatalyst resources, allowing access to all your existing resources. | AWS Builder ID and IAM Identity Center | | verified\$1access:application:connect | Enable AWS Verified Access | AWS Verified Access | | redshift:connect | Connect to Amazon Redshift | Amazon Redshift | | datazone:domain:access | Access your DataZone Domain Execution Role | Amazon DataZone | | nosqlworkbench:datamodeladviser | Create and read data models | NoSQL Workbench | | transform:read\$1write | Enable access to AWS Transform Agent for code transformation | AWS Transform | # Setting up customer managed SAML 2.0 applications SAML 2.0 application setup If you use customer managed applications that support [SAML 2.0](https://wiki.oasis-open.org/security), you can federate your IdP to IAM Identity Center through SAML 2.0 and use IAM Identity Center to manage user access to those applications. You can select a SAML 2.0 application from a catalog of commonly used applications in the IAM Identity Center console, or you can set up your own SAML 2.0 application. **Note** If you have customer managed applications that support OAuth 2.0 and your users need access from these applications to AWS services, you can use trusted identity propagation. With trusted identity propagation, a user can sign in to an application, and that application can pass the users’ identity in requests to access data in AWS services. **Topics** + [ # Set up an application from the IAM Identity Center application catalog ](saasapps.md) + [ # Set up your own SAML 2.0 application ](customermanagedapps-set-up-your-own-app-saml2.md) # Set up an application from the IAM Identity Center application catalog Set up an application from the catalog You can use the application catalog in the IAM Identity Center console to add many commonly used SAML 2.0 applications that work with IAM Identity Center. Examples include Salesforce, Box, and Microsoft 365. Most applications provide detailed information about how to set up the trust between IAM Identity Center and the application's service provider. This information is available in the configuration page for the application, after you select the application in the catalog. After you configure the application, you can assign access to users or groups in IAM Identity Center as needed. Use this procedure to set up a SAML 2.0 trust relationship between IAM Identity Center and your application's service provider. Before you begin this procedure, it is helpful to have the service provider's metadata exchange file so that you can more efficiently set up the trust. If you do not have this file, you can still use this procedure to configure the trust it manually. **To add and configure an application from the application catalog** 1. Open the [IAM Identity Center console](https://console.aws.amazon.com/singlesignon). 1. Choose **Applications**. 1. Choose the **Customer managed** tab. 1. Choose **Add application**. 1. On the **Select application type** page, under **Setup preference**, choose **I want to select an application from the catalog**. 1. Under **Application catalog**, start typing the name of the application that you want to add in the search box. 1. Choose the name of the application from the list when it appears in the search results, and then choose **Next**. 1. On the **Configure application** page, the **Display name** and **Description** fields are prepopulated with relevant details for the application. You can edit this information. 1. Under **IAM Identity Center metadata**, do the following: 1. Under **IAM Identity Center SAML metadata file**, choose **Download** to download the identity provider metadata. 1. Under **IAM Identity Center certificate**, choose **Download certificate** to download the identity provider certificate. **Note** You will need these files later when you set up the application from the service provider's website. Follow the instructions from that provider. 1. (Optional) Under **Application properties**, you can specify the **Application start URL**, **Relay state**, and **Session duration**. For more information, see [Understand application properties in the IAM Identity Center console](appproperties.md). 1. Under **Application metadata**, do one of the following: 1. If you have a metadata file, choose **Upload application SAML metadata file**. Then, select **Choose file** to find and select the metadata file. 1. If you do not have a metadata file, choose **Manually type your metadata values**, and then provide the **Application ACS URL** and **Application SAML audience** values. 1. Choose **Submit**. You're taken to the details page of the application that you just added. # Set up your own SAML 2.0 application You can set up your own applications that allow identity federation using SAML 2.0 and add them to IAM Identity Center. Most of the steps for setting up your own SAML 2.0 applications are the same as setting up a SAML 2.0 application from the application catalog in the IAM Identity Center console. However, you must also provide additional SAML attribute mappings for your own SAML 2.0 applications. These mappings enable IAM Identity Center to populate the SAML 2.0 assertion correctly for your application. You can provide this additional SAML attribute mapping when you set up the application for the first time. You can also provide SAML 2.0 attribute mappings on the application details page in the IAM Identity Center console. Use the following procedure to set up a SAML 2.0 trust relationship between IAM Identity Center and your SAML 2.0 application's service provider. Before you begin this procedure, make sure that you have the service provider's certificate and metadata exchange files so that you can finish setting up the trust. **To set up your own SAML 2.0 application** 1. Open the [IAM Identity Center console](https://console.aws.amazon.com/singlesignon). 1. Choose **Applications**. 1. Choose the **Customer managed** tab. 1. Choose **Add application**. 1. On the **Select application type** page, under **Setup preference**, choose **I have an application I want to set up**. 1. Under **Application type**, choose **SAML 2.0**. 1. Choose **Next**. 1. On the **Configure application** page, under **Configure application**, enter a **Display name** for the application, such as **MyApp**. Then, enter a **Description**. 1. Under **IAM Identity Center metadata**, do the following: 1. Under **IAM Identity Center SAML metadata file**, choose **Download** to download the identity provider metadata. 1. Under **IAM Identity Center certificate**, choose **Download** to download the identity provider certificate. **Note** You will need these files later when you set up the custom application from the service provider's website. 1. (Optional) Under **Application properties**, you can also specify the **Application start URL**, **Relay state**, and **Session duration**. For more information, see [Understand application properties in the IAM Identity Center console](appproperties.md). 1. Under **Application metadata**, choose **Manually type your metadata values**. Then, provide the **Application ACS URL** and **Application SAML audience** values. 1. Choose **Submit**. You're taken to the details page of the application that you just added. # Trusted identity propagation overview Trusted identity propagation Trusted identity propagation is a feature of IAM Identity Center that enables administrators of AWS services to grant permissions based on user attributes such as group associations. With trusted identity propagation, identity context is added to an IAM role to identify the user requesting access to AWS resources. This context is propagated to other AWS services. Identity context comprises information that AWS services use to make authorization decisions when they receive access requests. This information includes metadata that identifies the requester (for example, an IAM Identity Center user), the AWS service to which access is requested (for example, Amazon Redshift), and the scope of access (for example, read only access). The receiving AWS service uses this context, and any permissions assigned to the user, to authorize access to its resources. ## Benefits of trusted identity propagation Trusted identity propagation allows the administrators of AWS services to grant permissions to resources, such as data, using the corporate identities of your workforce. In addition, they can audit who accessed what data by looking at service logs or AWS CloudTrail. If you are an IAM Identity Center administrator, you may be asked by other AWS service administrators to enable trusted identity propagation. ## Enabling trusted identity propagation The process of enabling trusted identity propagation involves the following two steps: 1. **Enable IAM Identity Center and connect your existing source of identities to IAM Identity Center** - You'll continue to manage your workforce identities in your existing source of identities; connecting it to IAM Identity Center creates a reference to your workforce that all AWS services in your use case can share. It's also available for data owners to use in future use cases. 1. **Connect the AWS services in your use case to IAM Identity Center** - The administrator of each AWS service in the trusted identity propagation use case follows the guidance in the respective service documentation to connect the service to IAM Identity Center. **Note** If your use case involves a *third-party* or *customer developed application*, you enable trusted identity propagation by configuring a trust relationship between the identity provider that authenticates the application users and IAM Identity Center. This allows your application to take advantage of the trusted identity propagation flow previously described. For more information, see [Using applications with a trusted token issuer](using-apps-with-trusted-token-issuer.md). ## How trusted identity propagation works The following diagram shows the high-level workflow for trusted identity propagation: ![\[Simplified trusted identity propagation workflow.\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/simplied-tip-1.png) 1. Users authenticate with a client-facing application, for example Quick. 1. The client-facing application requests access to use an AWS service to query data and includes information on the user. **Note** Some trusted identity propagation use cases involve tools that interact with AWS services using service drivers. You can find out if this applies to your use case in the [use case guidance](trustedidentitypropagation-integrations.md). 1. The AWS service verifies the user identity with IAM Identity Center and compares the user attributes, like their group associations, with those required for access. The AWS service authorizes the access so long as the user or their group has the necessary permissions. 1. AWS services may log the user identifier in AWS CloudTrail and in their service logs. Check the service documentation for details. The following image provides an overview of the previously described steps in the trusted identity propagation workflow: ![\[Simplified trusted identity propagation workflow.\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/simplied-tip-2.png) **Topics** + [ ## Benefits of trusted identity propagation ](#benefits-trusted-identity-propagation) + [ ## Enabling trusted identity propagation ](#enabling-tip) + [ ## How trusted identity propagation works ](#how-tip-works) + [ # Prerequisites and considerations ](trustedidentitypropagation-overall-prerequisites.md) + [ # Trusted identity propagation use cases ](trustedidentitypropagation-integrations.md) + [ # Authorization services ](authorization-services.md) # Prerequisites and considerations Before you set up trusted identity propagation, review the following prerequisites and considerations. **Topics** + [ ## Prerequisites ](#trustedidentitypropagation-prerequisites) + [ ## Considerations ](#trustedidentitypropagation-considerations) + [ ## Considerations for customer managed applications ](#trustedidentitypropagation-customer-apps) ## Prerequisites To use trusted identity propagation, ensure your environment meets the following prerequisites: + Enable and provision IAM Identity Center + To use trusted identity propagation, you must enable IAM Identity Center in the same AWS Region where the AWS applications and services your users will access are enabled. For information, see [Enable IAM Identity Center](enable-identity-center.md). + IAM Identity Center Organization instance is recommended - We recommend you use an [organization instance](organization-instances-identity-center.md) of IAM Identity Center that you enable in the management account of AWS Organizations. You can [delegate administration](organization-instances-identity-center.md) of an organization instance of IAM Identity Center to a member account. If you choose an [account instance](account-instances-identity-center.md) of IAM Identity Center, all AWS services that you want users to access with trusted identity propagation must reside in the same AWS account where you enable IAM Identity Center. For more information, see [Account instances of IAM Identity Center](account-instances-identity-center.md). + Connect your existing identity provider to IAM Identity Center and provision your users and groups into IAM Identity Center. For more information, see [IAM Identity Center identity source tutorials](tutorials.md). + Connect the AWS managed applications and services in your trusted identity propagation use case to IAM Identity Center. To use trusted identity propagation, AWS managed applications must be connected to IAM Identity Center. ## Considerations Keep in mind the following considerations when configuring and using trusted identity propagation: + **Organization vs account instance of IAM Identity Center** + An [organization instance](organization-instances-identity-center.md) of IAM Identity Center will give you the most control and flexibility to grow your use cases to multiple AWS accounts, users, and AWS services. If you are unable to use an organization instance, your use case may be supported with account instances of IAM Identity Center. To learn more about which AWS services in your use case support account instances of IAM Identity Center, see [AWS managed applications that you can use with IAM Identity Center](awsapps-that-work-with-identity-center.md). + **Multi-account permissions (permission sets) not required** + Trusted identity propagation doesn't require you to set up [multi-account permissions](manage-your-accounts.md) (permission sets). You can enable IAM Identity Center and use it for trusted identity propagation only. ## Considerations for customer managed applications Your workforce can benefit from trusted identity propagation even if your users interact with client-facing applications that are not managed by AWS, for example Tableau or your custom-developed applications. The users of these applications may not be provisioned in IAM Identity Center. To enable the smooth recognition and authorization of user access to AWS resources, IAM Identity Center enables you to configure a trusted relationship between the identity provider authenticating your users and IAM Identity Center. For more information, see [Using applications with a trusted token issuer](using-apps-with-trusted-token-issuer.md). In addition, configuring trusted identity propagation for your application will require: + Your application must use OAuth 2.0 framework for authentication. Trusted identity propagation does not support SAML 2.0 integrations. + Your application must be recognized by IAM Identity Center. Follow the guidance specific to your [use case](trustedidentitypropagation-integrations.md). # Trusted identity propagation use cases Use cases As an IAM Identity Center administrator, you might be asked to help configure trusted identity propagation from user facing applications to AWS services. To support this request, you'll need the following information: + What client-facing application will your users interface with? + Which AWS services are used to query the data and to authorize access to the data? + Which AWS service authorizes access to the data? Your role in enabling **trusted identity propagation use cases that do not involve third-party applications or custom-developed applications** is to: 1. [Enable IAM Identity Center](enable-identity-center.md). 1. [Connect your existing source of identities to IAM Identity Center](tutorials.md). The remaining steps of the trusted identity configuration for these use cases are performed within the connected AWS services and applications. The administrators of the connected AWS services or applications should refer to the respective user guides for comprehensive service-specific guidance. Your role in enabling **trusted identity propagation use cases that involve third-party applications or custom-developed applications** includes the steps of [Enable IAM Identity Center](enable-identity-center.md) and [connecting your source of identities](tutorials.md) as well as: 1. Configuring the connection of your identity provider (IdP) to the third-party party or custom-developed application. 1. Enabling IAM Identity Center to recognize the third-party or custom-developed application. 1. Configuring your IdP as a trusted token issuer in IAM Identity Center. For more information, see [Using applications with a trusted token issuer](using-apps-with-trusted-token-issuer.md). The administrators of the connected applications and AWS services should refer to the respective user guides for comprehensive service-specific guidance. ## Analytics, data lakehouse, and machine learning use cases You can enable trusted propagation use cases with the following analytics and machine learning services: + **Amazon Redshift** - For guidance, see [Trusted identity propagation with Amazon Redshift](tip-usecase-redshift.md). + **Amazon EMR** - For guidance, see [Trusted identity propagation with Amazon EMR](tip-usecase-emr.md). + **Amazon Athena** - For guidance, see [Trusted identity propagation with Amazon Athena](tip-usecase-ate.md). + **SageMaker Studio** - For guidance, see [Trusted identity propagation with Amazon SageMaker Studio](trusted-identity-propagation-usecase-sagemaker-studio.md). ## Additional use cases You can enable IAM Identity Center and trusted identity propagation with these additional AWS services: + **Amazon Q Business** - for guidance, see: + [Admin workflow for apps using IAM Identity Center](https://docs.aws.amazon.com//amazonq/latest/qbusiness-ug/how-it-works.html#admin-flow-idc). + [Configuring an Amazon Q Business application using IAM Identity Center](https://docs.aws.amazon.com//amazonq/latest/qbusiness-ug/create-application.html). + [Configure Amazon Q Business with IAM Identity Center trusted identity propagation](https://aws.amazon.com/blogs//machine-learning/configuring-amazon-q-business-with-aws-iam-identity-center-trusted-identity-propagation/). + **Amazon OpenSearch Service** - for guidance, see: + [IAM Identity Center Trusted Identity Propagation Support for Amazon OpenSearch Service](https://docs.aws.amazon.com//opensearch-service/latest/developerguide/idc-aos.html). + [Centralized OpenSearch user interface (Dashboards) with Amazon OpenSearch Service](https://docs.aws.amazon.com//opensearch-service/latest/developerguide/application.html). + **AWS Transfer Family** - for guidance, see: + [Transfer Family web apps](https://docs.aws.amazon.com//transfer/latest/userguide/web-app.html). **Topics** + [ ## Analytics, data lakehouse, and machine learning use cases ](#tip-data-analytic-usecases-overview) + [ ## Additional use cases ](#tip-additional-usecases) + [ # Trusted identity propagation with Amazon Redshift ](tip-usecase-redshift.md) + [ # Trusted identity propagation with Amazon EMR ](tip-usecase-emr.md) + [ # Trusted identity propagation with Amazon Athena ](tip-usecase-ate.md) + [ # Trusted identity propagation with Amazon SageMaker Studio ](trusted-identity-propagation-usecase-sagemaker-studio.md) # Trusted identity propagation with Amazon Redshift The steps to enable trusted identity propagation depend on whether your users interact with AWS managed applications or customer managed applications. The following diagram shows a trusted identity propagation configuration for client-facing applications - either AWS managed or external to AWS - that query Amazon Redshift data with access control provided either by Amazon Redshift or by authorization services, such as AWS Lake Formation or Amazon S3 Access Grants. ![\[Diagram of trusted identity propagation using Amazon Redshift, Quick, Lake Formation, and IAM Identity Center\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/rs-tip-diagram.png) When trusted identity propagation to Amazon Redshift is enabled, Redshift administrators can configure Redshift to [automatically create roles](https://docs.aws.amazon.com//redshift/latest/mgmt/redshift-iam-access-control-sso-autocreate.html) for IAM Identity Center as the identity provider, map Redshift roles to groups in IAM Identity Center, and use [Redshift role-based access control to grant access](https://docs.aws.amazon.com//redshift/latest/dg/r_tutorial-RBAC.html). ## Supported client-facing applications **AWS managed applications** The following AWS managed client-facing applications support trusted identity propagation to Amazon Redshift: + [Amazon Redshift Query Editor V2](setting-up-tip-redshift.md) + [Quick](https://docs.aws.amazon.com//quicksight/latest/user/redshift-trusted-identity-propagation.html) **Note** If you are using Amazon Redshift Spectrum to access external databases or tables in AWS Glue Data Catalog, consider setting up [Lake Formation](tip-tutorial-lf.md) and [Amazon S3 Access Grants](tip-tutorial-s3.md) to provide fine-grain access control. **Customer managed applications** The following customer managed applications support trusted identity propagation to Amazon Redshift: + **Tableau** including Tableau Desktop, Tableau Server, and Tableau Prep + To enable trusted identity propagation for users of Tableau, refer to [Integrate Tableau and Okta with Amazon Redshift using IAM Identity Center](https://aws.amazon.com/blogs//big-data/integrate-tableau-and-okta-with-amazon-redshift-using-aws-iam-identity-center/) in the *AWS Big Data Blog*. + **SQL Clients** (DBeaver and DBVisualizer) + To enable trusted identity propagation for users of SQL Clients (DBeaver and DBVisualizer), refer to [Integrate Identity Provider (IdP) with Amazon Redshift Query Editor V2 and SQL Client using IAM Identity Center for seamless Single Sign-On](https://aws.amazon.com/blogs//big-data/integrate-identity-provider-idp-with-amazon-redshift-query-editor-v2-and-sql-client-using-aws-iam-identity-center-for-seamless-single-sign-on/) in the *AWS Big Data Blog*. # Setting up trusted identity propagation with Amazon Redshift Query Editor V2 Amazon Redshift Query Editor V2 The following procedure walks you through how to achieve trusted identity propagation from Amazon Redshift Query Editor V2 to Amazon Redshift. ## Prerequisites Before you can get started with this tutorial, you'll need to set up the following: 1. [Enable IAM Identity Center](enable-identity-center.md). [Organization instance](organization-instances-identity-center.md) is recommended. For more information, see [Prerequisites and considerations](trustedidentitypropagation-overall-prerequisites.md). 1. [Provision the users and groups from your source of identities into IAM Identity Center](tutorials.md). Enabling trusted identity propagation includes tasks performed by an IAM Identity Center administrator in the IAM Identity Center console and tasks performed by an Amazon Redshift administrator in the Amazon Redshift console. ## Tasks performed by the IAM Identity Center administrator The following tasks needed to be complete by the IAM Identity Center administrator: 1. **Create an [IAM role](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_roles.html)** in the account where the Amazon Redshift cluster or Serverless instance exists with the following permission policy. For more information, see [IAM Role creation](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create.html). 1. The following policy examples includes the necessary permissions to complete this tutorial. To use this policy, replace the *italicized placeholder text* in the example policy with your own information. For additional directions, see [Create a policy](https://docs.aws.amazon.com//IAM/latest/UserGuide/access_policies_create.html) or [Edit a policy](https://docs.aws.amazon.com//IAM/latest/UserGuide/access_policies_manage-edit.html). **Permission policy:** ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "AllowRedshiftApplication", "Effect": "Allow", "Action": [ "redshift:DescribeQev2IdcApplications", "redshift-serverless:ListNamespaces", "redshift-serverless:ListWorkgroups", "redshift-serverless:GetWorkgroup" ], "Resource": "*" }, { "Sid": "AllowIDCPermissions", "Effect": "Allow", "Action": [ "sso:DescribeApplication", "sso:DescribeInstance" ], "Resource": [ "arn:aws:sso:::instance/Your-IAM-Identity-Center-Instance ID", "arn:aws:sso::111122223333:application/Your-IAM-Identity-Center-Instance-ID/*" ] } ] } ``` ------ **Trust policy:** ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": [ "redshift-serverless.amazonaws.com", "redshift.amazonaws.com" ] }, "Action": [ "sts:AssumeRole", "sts:SetContext" ] } ] } ``` ------ 1. **Create a permission set** in the AWS Organizations management account where IAM Identity Center is enabled. You’ll use it in the next step to allow federated users to access Redshift Query Editor V2. 1. Go to the **IAM Identity Center** console, under **Multi-Account permissions**, choose **Permission sets**. 1. Choose **Create permission set**. 1. Choose **Custom permission set** and then choose **Next**. 1. Under **AWS managed policies**, choose **`AmazonRedshiftQueryEditorV2ReadSharing`**. 1. Under **Inline policy**, add the following policy: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "Statement1", "Effect": "Allow", "Action": [ "redshift:DescribeQev2IdcApplications", "redshift-serverless:ListNamespaces", "redshift-serverless:ListWorkgroups", "redshift-serverless:GetWorkgroup" ], "Resource": "*" } ] } ``` ------ 1. Select **Next** and then provide a name for the permission set name. For example, **Redshift-Query-Editor-V2**. 1. Under **Relay state – optional**, set default relay state to the Query Editor V2 URL, using the format: `https://your-region.console.aws.amazon.com/sqlworkbench/home`. 1. Review the settings and choose **Create**. 1. Navigate to the IAM Identity Center Dashboard and copy the AWS access portal URL from the **Setting Summary** section. ![\[Step i, Copy AWS access portal URL from IAM Identity Center console.\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/setting-up-redshift-step-i.png) 1. Open a new Incognito Browser Window and paste the URL. This will take you to your AWS access portal, ensuring you are signing in with an IAM Identity Center user. ![\[Step j, Sign in to AWS access portal.\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/setting-up-redshift-step-j.png) For more information about permission set, see [Manage AWS accounts with permission sets](permissionsetsconcept.md). 1. **Enable federated users access to Redshift Query Editor V2**. 1. In the AWS Organizations management account, open the **IAM Identity Center** console. 1. In the navigation pane, under **Multi-account permissions**, choose **AWS accounts**. 1. On the AWS accounts page, select the AWS account that you want to assign access to. 1. Choose **Assign users or groups**. 1. On the **Assign users and groups** page, choose the users and or groups that you want to create the permission set for. Then, choose **Next**. 1. On the **Assign permission sets **page, choose the permission set you created in the previous step. Then, choose **Next**. 1. On the **Review and submit assignments** page, review your selections and choose **Submit**. ## Tasks performed by an Amazon Redshift administrator Enabling trusted identity propagation to Amazon Redshift requires an Amazon Redshift cluster administrator or Amazon Redshift Serverless administrator to perform a number of tasks in the Amazon Redshift console. For more information, see [Integrate Identity Provider (IdP) with Amazon Redshift Query Editor V2 and SQL Client using IAM Identity Center for seamless Single Sign-On](https://aws.amazon.com/blogs//big-data/integrate-identity-provider-idp-with-amazon-redshift-query-editor-v2-and-sql-client-using-aws-iam-identity-center-for-seamless-single-sign-on/) in the *AWS Big Data Blog*. # Trusted identity propagation with Amazon EMR The following diagram shows a trusted identity propagation configuration for Amazon EMR Studio using Amazon EMR on Amazon EC2 with access control provided by AWS Lake Formation and Amazon S3 Access Grants. ![\[Diagram of trusted identity propagation using Amazon EMR, Lake Formation, and IAM Identity Center\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/emr-tip-diagram.png) **Supported client-facing applications** + Amazon EMR Studio **To enable trusted identity propagation, follow these steps:** + [Set up Amazon EMR Studio](setting-up-tip-emr.md) as the client-facing application for Amazon EMR cluster. + Set up [Amazon EMR Cluster on Amazon EC2 with Apache Spark](https://docs.aws.amazon.com//emr/latest/ManagementGuide/emr-idc-start.html). + *Recommended*: [AWS Lake Formation](tip-tutorial-lf.md) and [Amazon S3 Access Grants](tip-tutorial-s3.md) to provide fine-grained access control to AWS Glue Data Catalog and underlying data locations in S3. # Setting up trusted identity propagation with Amazon EMR Studio Amazon EMR Studio The following procedure walks you through setting up Amazon EMR Studio for trusted identity propagation in queries against an Amazon Athena workgroups or Amazon EMR clusters running Apache Spark. ## Prerequisites Before you can get started with this tutorial, you'll need to set up the following: 1. [Enable IAM Identity Center](enable-identity-center.md). [Organization instance](organization-instances-identity-center.md) is recommended. For more information, see [Prerequisites and considerations](trustedidentitypropagation-overall-prerequisites.md). 1. [Provision the users and groups from your source of identities into IAM Identity Center](tutorials.md). To complete setting up trusted identity propagation from Amazon EMR Studio, the EMR Studio administrator must perform the following steps. ## Step 1. Create the required IAM roles for EMR Studio In this step, the Amazon EMR Studio administrator creates and IAM service role and an IAM user role for EMR Studio. 1. **[Create an EMR Studio service role](https://docs.aws.amazon.com//emr/latest/ManagementGuide/emr-studio-service-role.html)** - EMR Studio assume this IAM role to securely manage workspaces and notebooks, connect to clusters, and handle data interactions. 1. Navigate to the IAM console ([https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)) and create an IAM role. 1. Select **AWS service** as the trusted entity and then choose **Amazon EMR**. Attach the following policies to define the role's permissions and trust relationship. To use these policy, replace the *italicized placeholder text* in the example policy with your own information. For additional directions, see [Create a policy](https://docs.aws.amazon.com//IAM/latest/UserGuide/access_policies_create.html) or [Edit a policy](https://docs.aws.amazon.com//IAM/latest/UserGuide/access_policies_manage-edit.html). ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "ObjectActions", "Effect": "Allow", "Action": [ "s3:PutObject", "s3:GetObject", "s3:DeleteObject" ], "Resource": [ "arn:aws:s3:::Your-S3-Bucket-For-EMR-Studio/*" ], "Condition": { "StringEquals": { "aws:ResourceAccount": "Your-AWS-Account-ID" } } }, { "Sid": "BucketActions", "Effect": "Allow", "Action": [ "s3:ListBucket", "s3:GetEncryptionConfiguration" ], "Resource": [ "arn:aws:s3:::Your-S3-Bucket-For-EMR-Studio" ], "Condition": { "StringEquals": { "aws:ResourceAccount": "Your-AWS-Account-ID" } } } ] } ``` ------ For a reference of all the service role permissions, see [EMR Studio service role permissions](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-studio-service-role.html#emr-studio-service-role-permissions-table). 1. **[Create an EMR Studio user role for IAM Identity Center authentication](https://docs.aws.amazon.com//emr/latest/ManagementGuide/emr-studio-user-permissions.html#emr-studio-create-user-role)** - EMR Studio assumes this role when a user signs in through IAM Identity Center to manage workspaces, EMR clusters, jobs, git repositories. **This role is used to initiate the trusted identity propagation workflow**. **Note** The EMR Studio user role does not need to include permissions to access the Amazon S3 locations of the tables in AWS Glue Catalog. AWS Lake Formation permissions and registered lake locations will be used to receive temporary permissions. The following example policy can be used in a role allowing a user of EMR Studio to use Athena workgroups to run queries. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "AllowDefaultEC2SecurityGroupsCreationInVPCWithEMRTags", "Effect": "Allow", "Action": [ "ec2:CreateSecurityGroup" ], "Resource": [ "arn:aws:ec2:*:*:vpc/*" ], "Condition": { "StringEquals": { "aws:ResourceTag/for-use-with-amazon-emr-managed-policies": "true" } } }, { "Sid": "AllowAddingEMRTagsDuringDefaultSecurityGroupCreation", "Effect": "Allow", "Action": [ "ec2:CreateTags" ], "Resource": "arn:aws:ec2:*:*:security-group/*", "Condition": { "StringEquals": { "aws:RequestTag/for-use-with-amazon-emr-managed-policies": "true", "ec2:CreateAction": "CreateSecurityGroup" } } }, { "Sid": "AllowSecretManagerListSecrets", "Action": [ "secretsmanager:ListSecrets" ], "Resource": "*", "Effect": "Allow" }, { "Sid": "AllowSecretCreationWithEMRTagsAndEMRStudioPrefix", "Effect": "Allow", "Action": "secretsmanager:CreateSecret", "Resource": "arn:aws:secretsmanager:*:*:secret:emr-studio-*", "Condition": { "StringEquals": { "aws:RequestTag/for-use-with-amazon-emr-managed-policies": "true" } } }, { "Sid": "AllowAddingTagsOnSecretsWithEMRStudioPrefix", "Effect": "Allow", "Action": "secretsmanager:TagResource", "Resource": "arn:aws:secretsmanager:*:*:secret:emr-studio-*" }, { "Sid": "AllowPassingServiceRoleForWorkspaceCreation", "Action": "iam:PassRole", "Resource": [ "arn:aws:iam::111122223333:role/service-role/AmazonEMRStudio_ServiceRole_Name" ], "Effect": "Allow" }, { "Sid": "AllowS3ListAndLocationPermissions", "Action": [ "s3:ListAllMyBuckets", "s3:ListBucket", "s3:GetBucketLocation" ], "Resource": "arn:aws:s3:::*", "Effect": "Allow" }, { "Sid": "AllowS3ReadOnlyAccessToLogs", "Action": [ "s3:GetObject" ], "Resource": [ "arn:aws:s3:::aws-logs-Your-AWS-Account-ID-Region/elasticmapreduce/*" ], "Effect": "Allow" }, { "Sid": "AllowAthenaQueryExecutions", "Effect": "Allow", "Action": [ "athena:StartQueryExecution", "athena:GetQueryExecution", "athena:GetQueryResults", "athena:StopQueryExecution", "athena:ListQueryExecutions", "athena:GetQueryResultsStream", "athena:ListWorkGroups", "athena:GetWorkGroup", "athena:CreatePreparedStatement", "athena:GetPreparedStatement", "athena:DeletePreparedStatement" ], "Resource": "*" }, { "Sid": "AllowGlueSchemaManipulations", "Effect": "Allow", "Action": [ "glue:GetDatabase", "glue:GetDatabases", "glue:GetTable", "glue:GetTables", "glue:GetPartition", "glue:GetPartitions" ], "Resource": "*" }, { "Sid": "AllowQueryEditorToAccessWorkGroup", "Effect": "Allow", "Action": "athena:GetWorkGroup", "Resource": "arn:aws:athena:*:111122223333:workgroup*" }, { "Sid": "AllowConfigurationForWorkspaceCollaboration", "Action": [ "elasticmapreduce:UpdateEditor", "elasticmapreduce:PutWorkspaceAccess", "elasticmapreduce:DeleteWorkspaceAccess", "elasticmapreduce:ListWorkspaceAccessIdentities" ], "Resource": "*", "Effect": "Allow", "Condition": { "StringEquals": { "elasticmapreduce:ResourceTag/creatorUserId": "${aws:userId}" } } }, { "Sid": "DescribeNetwork", "Effect": "Allow", "Action": [ "ec2:DescribeVpcs", "ec2:DescribeSubnets", "ec2:DescribeSecurityGroups" ], "Resource": "*" }, { "Sid": "ListIAMRoles", "Effect": "Allow", "Action": [ "iam:ListRoles" ], "Resource": "*" }, { "Sid": "AssumeRole", "Effect": "Allow", "Action": [ "sts:AssumeRole" ], "Resource": "*" } ] } ``` ------ The following trust policy allows EMR Studio to assume the role: **Note** Additional permissions are needed to leverage EMR Studio Workspaces and EMR Notebooks. See [Create permissions policies for EMR Studio users](https://docs.aws.amazon.com//emr/latest/ManagementGuide/emr-studio-user-permissions.html#emr-studio-permissions-policies) for more information. **You can find more information with the following links:** + [Define custom IAM permissions with customer managed policies](https://docs.aws.amazon.com//IAM/latest/UserGuide/access_policies_create.html) + [EMR Studio service role permissions](https://docs.aws.amazon.com//emr/latest/ManagementGuide/emr-studio-service-role.html#emr-studio-service-role-permissions-table) ## Step 2. Create and configure your EMR Studio In this step, you'll create an Amazon EMR Studio in the EMR Studio console and use the IAM roles you created in [Step 1. Create the required IAM roles for EMR StudioStep 2. Create and configure your EMR Studio](#setting-up-tip-emr-step1). 1. Navigate to the EMR Studio console, select **Create Studio** and the **Custom Setup** option. You can either create a new S3 bucket or use an existing bucket. You may check the box to **Encrypt workspace files with your own KMS keys**. For more information, see [AWS Key Management Service](https://docs.aws.amazon.com//kms/latest/developerguide/overview.html). ![\[Step 1 Create EMR Studio in the EMR console.\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/emr-tutorial-step-3.1.png) 1. Under **Service role to let Studio access your resources**, select the service role created in [Step 1. Create the required IAM roles for EMR StudioStep 2. Create and configure your EMR Studio](#setting-up-tip-emr-step1) from the menu. 1. Choose **IAM Identity Center** under **Authentication**. Select the user role created in [Step 1. Create the required IAM roles for EMR StudioStep 2. Create and configure your EMR Studio](#setting-up-tip-emr-step1). ![\[Step 3 Create EMR Studio in the EMR console, selecting IAM Identity Center for the authentication method.\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/emr-tutorial-step-3.3.png) 1. Check the **Trusted identity propagation** box. Choose **Only assigned users and groups **under the Application access section, which will allow you to grant only authorized user and groups to access this studio. 1. *(Optional)* - You can configure VPC and subnet if you are using this Studio with EMR clusters. ![\[Step 4 Create EMR Studio in the EMR console, selecting network and security settings.\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/emr-tutorial-step-3.4.png) 1. Review all the details and select **Create Studio**. 1. After configuring an Athena WorkGroup or EMR clusters, sign in to the Studio's URL to: 1. Run Athena queries with the Query Editor. 1. Run Spark jobs in the workspace using Jupyter notebook. # Trusted identity propagation with Amazon Athena The steps to enable trusted identity propagation depend on whether your users interact with AWS managed applications or customer managed applications. The following diagram shows a trusted identity propagation configuration for client-facing applications - either AWS managed or external to AWS - that uses Amazon Athena to query Amazon S3 data with access control provided by AWS Lake Formation and Amazon S3 Access Grants. **Note** Trusted identity propagation with Amazon Athena requires the use of Trino. Apache Spark and SQL clients connected to Amazon Athena via ODBC and JDBC drivers are not supported. ![\[Diagram of trusted identity propagation using Athena, Amazon EMR, Lake Formation, and IAM Identity Center\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/ate-tip-diagram.png) **AWS managed applications** The following AWS managed client-facing application supports trusted identity propagation with Athena: + Amazon EMR Studio **To enable trusted identity propagation, follow these steps:** + [Set up Amazon EMR Studio](setting-up-tip-emr.md) as the client-facing application for Athena. The Query Editor in EMR Studio is needed to run Athena Queries when trusted identity propagation is enabled. + [Set up Athena Workgroup](setting-up-tip-ate.md). + [Set up AWS Lake Formation](tip-tutorial-lf.md) to enable fine-grained access control for AWS Glue tables based on the user or group in IAM Identity Center. + [Set up Amazon S3 Access Grants](tip-tutorial-s3.md) to enable temporary access to the underlying data locations in S3. **Note** Both Lake Formation and Amazon S3 Access Grants are required for access control to AWS Glue Data Catalog and for Athena query results in Amazon S3. **Customer managed applications** To enable trusted identity propagation for users of *custom-developed applications*, see to [Access AWS services programmatically using trusted identity propagation](https://aws.amazon.com/blogs//security/access-aws-services-programmatically-using-trusted-identity-propagation/) in the *AWS Security Blog*. # Setting up trusted identity propagation with Amazon Athena workgroups Amazon Athena workgroups The following procedure walks you through setting up Amazon Athena workgroups for trusted identity propagation. ## Prerequisites Before you can get started with this tutorial, you'll need to set up the following: 1. [Enable IAM Identity Center](enable-identity-center.md). [Organization instance](organization-instances-identity-center.md) is recommended. For more information, see [Prerequisites and considerations](trustedidentitypropagation-overall-prerequisites.md). 1. [Provision the users and groups from your source of identities into IAM Identity Center](tutorials.md). 1. This configuration requires [Amazon EMR Studio](setting-up-tip-emr.md), [AWS Lake Formation](tip-tutorial-lf.md), and [Amazon S3 Access Grants](tip-tutorial-s3.md). ## Setting up trusted identity propagation with Athena To set up trusted identity propagation with Athena, the Athena administrator must: 1. Review [Considerations and limitations in using IAM Identity Center enabled Athena workgroups](https://docs.aws.amazon.com//athena/latest/ug/workgroups-identity-center.html#workgroups-identity-center-considerations-and-limitations). 1. [Create an IAM Identity Center enabled Athena workgroup](https://docs.aws.amazon.com//athena/latest/ug/workgroups-identity-center.html#workgroups-identity-center-creating-an-identity-center-enabled-athena-workgroup). # Trusted identity propagation with Amazon SageMaker Studio [Amazon SageMaker Studio](https://docs.aws.amazon.com//sagemaker/latest/dg/studio-updated.html) integrates with IAM Identity Center, and it supports [user background sessions](user-background-sessions.md) and trusted identity propagation. User background sessions allow a user to initiate a long-running job on SageMaker Studio, without that user having to remain signed in while the job runs. The job runs immediately and in the background, using the permissions of the user who initiated the job. The job can continue to run even if the user turns off their computer, their IAM Identity Center sign-in session expires, or the user signs out of the AWS access portal. The default session duration for user background sessions is 7 days, but you can specify a maximum duration of 90 days. Trusted identity propagation allows fine-grained access to be provided to AWS resources such as Amazon S3 buckets based on the user's identity or group membership. The following diagram shows a trusted identity propagation configuration for SageMaker Studio, with access to data stored in an Amazon S3 bucket. User background sessions are enabled for IAM Identity Center, which allows the SageMaker Studio training job to run in the background. Access control for the training data is provided by Amazon S3 Access Grants. ![\[Diagram of trusted identity propagation for SageMaker Studio, with a SageMaker Studio training job running in a user background session, and access to the training data in Amazon S3 provided by Amazon S3 Access Grants.\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/sagemaker-studio-s3-user-background-session-training-job-s3-access-grants-diagram.png) **AWS managed application** The following AWS managed client-facing application supports trusted identity propagation: + [Amazon SageMaker Studio](setting-up-trusted-identity-propagation-sagemaker-studio.md) **To enable trusted identity propagation and user background sessions, follow these steps:** + [Set up SageMaker Studio as the client-facing application.](setting-up-trusted-identity-propagation-sagemaker-studio.md) + [Set up Amazon S3 Access Grants](tip-tutorial-s3.md) to enable temporary access to the underlying data locations in Amazon S3. # Setting up trusted identity propagation with SageMaker Studio SageMaker Studio The following procedure walks you through setting up SageMaker Studio for trusted identity propagation and user background sessions. ## Prerequisites Before you can get started with this tutorial, you'll need to complete the following tasks: 1. [Enable IAM Identity Center](enable-identity-center.md). An organization instance is required. For more information, see [Prerequisites and considerations](trustedidentitypropagation-overall-prerequisites.md). 1. [Provision the users and groups from your source of identities into IAM Identity Center](tutorials.md). 1. [Confirm that user background sessions are enabled](user-background-sessions.md) in the IAM Identity Center console. By default, user background sessions are enabled and the session duration is set to 7 days. You can change this duration. To set up trusted identity propagation from SageMaker Studio, the SageMaker Studio administrator must perform the following steps. ## Step 1: Enable trusted identity propagation in a new or existing SageMaker Studio domain SageMaker Studio uses domains to organize user profiles, applications, and their associated resources. To enable trusted identity propagation, you must create a SageMaker Studio domain or modify an existing domain as described in the following procedure. 1. Open the SageMaker AI console, navigate to **Domains**, and do either of the following. + **Create a new SageMaker Studio domain by using [Setup for organizations](https://docs.aws.amazon.com//sagemaker/latest/dg/onboard-custom.html#onboard-custom-instructions).** Choose **Set up for organizations**, and then do the following: + Choose **AWS Identity Center** as the authentication method. + Select the **Enable trusted identity propagation for all users on this domain** check box. + **Modify an existing SageMaker Studio domain.** + Select an existing domain that uses IAM Identity Center for authentication. **Important** Trusted identity propagation is only supported in SageMaker Studio domains that use IAM Identity Center for authentication. If the domain uses IAM for authentication, you can't change the authentication method, and therefore you can't enable trusted identity propagation. + [Edit domain settings](https://docs.aws.amazon.com//sagemaker/latest/dg/domain-edit). Edit the **Authentication and permissions** settings to enable trusted identity propagation. 1. Proceed to [Step 2: Configure the default domain execution role](#setting-up-trusted-identity-propagation-sagemaker-studio-domain-execution-role). This role is required for users of a SageMaker Studio domain to access other AWS services such as Amazon S3. ## Step 2: Configure the default domain execution role and role trust policy A *domain execution role* is an [IAM role](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_roles) that a SageMaker Studio domain assumes on behalf of all users in the domain. The permissions that you assign to this role determine what actions SageMaker Studio can perform. 1. To create or select a domain execution role, do either of the following: + **Create or select a role by using [Setup for organizations](https://docs.aws.amazon.com//sagemaker/latest/dg/onboard-custom.html#onboard-custom-instructions).** + Open the SageMaker AI console and follow the console guidance in **Step 2: Configure roles and ML activities** to create a new domain execution role or select an existing role. + Complete the rest of the setup steps to create your SageMaker Studio domain. + **Create an execution role manually.** + Open the IAM console and [create the execution role yourself](https://docs.aws.amazon.com//sagemaker/latest/dg/sagemaker-roles.html#sagemaker-roles-create-execution-role). 1. [Update the trust policy](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_roles_update-role-trust-policy.html) that is attached to the domain execution role so that it includes the following two actions: [https://docs.aws.amazon.com//STS/latest/APIReference/API_AssumeRole.html](https://docs.aws.amazon.com//STS/latest/APIReference/API_AssumeRole.html) and [https://docs.aws.amazon.com//IAM/latest/UserGuide/reference_policies_iam-condition-keys.html](https://docs.aws.amazon.com//IAM/latest/UserGuide/reference_policies_iam-condition-keys.html). For information about how to find the execution role for your SageMaker Studio domain, see [Get domain execution role](https://docs.aws.amazon.com//sagemaker/latest/dg/sagemaker-roles.html#sagemaker-roles-get-execution-role-domain). A *trust policy* specifies the identity that can assume a role. This policy is required to allow the SageMaker Studio service to assume the domain execution role. Add these two actions so that they appear as follows in your policy. ``` { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": [ "sagemaker.amazonaws.com" ] }, "Action": [ "sts:AssumeRole", "sts:SetContext" ] } ] } ``` ## Step 3: Verify required Amazon S3 Access Grant permissions for the domain execution role To use Amazon S3 Access Grants, you must have a permissions policy attached (either as an inline policy or a customer managed policy) to your SageMaker Studio domain execution role that contains the following permissions. ``` { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:GetDataAccess", "s3:GetAccessGrantsInstanceForPrefix" ], "Resource": "arn:aws:s3:us-east-2:111122223333:access-grants/default" } ] } ``` If you don't have a policy that contains these permissions, follow the instructions in [Adding and removing IAM identity permissions](https://docs.aws.amazon.com//IAM/latest/UserGuide/access_policies_manage-attach-detach.html) in the *AWS Identity and Access Management User Guide*. ## Step 4: Assign groups and users to the domain Assign groups and users to the SageMaker Studio domain by following the steps in [Add groups and users](https://docs.aws.amazon.com//sagemaker/latest/dg/domain-groups-add.html). ## Step 5: Set up Amazon S3 Access Grants To set up Amazon S3 Access Grants, follow the steps in [Configuring Amazon S3 Access Grants for trusted identity propagation through IAM Identity Center](tip-tutorial-s3.md#tip-tutorial-s3-configure). Use the step-by-step instructions to complete the following tasks: 1. Create an Amazon S3 Access Grants instance. 1. Register a location in that instance. 1. Create grants to allow specific IAM Identity Center users or groups to access designated Amazon S3 locations or subsets (for example, specific prefixes) within those locations. ## Step 6: Submit a SageMaker training job and view user background session details In SageMaker Studio, launch a new Jupyter notebook and submit a training job. While the job is running, complete the following steps to view the session information and to verify that the user background session context is active. 1. Open the IAM Identity Center console. 1. Choose **Users**. 1. On the **Users** page, choose the username of the user whose sessions you want to manage. This takes you to a page with the user's information. 1. On the user's page, choose the **Active sessions** tab. The number in parentheses next to **Active sessions** indicates the number of active sessions for this user. 1. To search for sessions by the Amazon Resource Name (ARN) of the job that is using the session, in the **Session type** list, choose **User background sessions**, and then enter the job ARN in the search box. Following is an example of how a training job that is using a user background session appears in the A**ctive sessions** tab for a user. ![\[alt text not found\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/sagemaker-studio-training-job-displayed-in-identity-center-console-active-sessions.png) ## Step 7: View the CloudTrail logs to verify trusted identity propagation in CloudTrail When trusted identity propagation is enabled, actions appear in CloudTrail event logs under the `onBehalfOf` element. The `userId` reflects the ID of the IAM Identity Center user who initiated the training job. The following CloudTrail event captures the process of trusted identity propagation. ``` "userIdentity": { "type": "AssumedRole", "principalId": "AROA123456789EXAMPLE:SageMaker", "arn": "arn:aws:sts::111122223333:assumed-role/SageMaker-ExecutionRole-20250728T125817/SageMaker", "accountId": "111122223333", "accessKeyId": "ASIAIOSFODNN7EXAMPLE", "sessionContext": { "sessionIssuer": { "type": "Role", "principalId": "AROA123456789EXAMPLE", "arn": "arn:aws:iam::111122223333:role/service-role/SageMaker-ExecutionRole-20250728T125817", "accountId": "111122223333", "userName": "SageMaker-ExecutionRole-20250728T125817" }, "attributes": { "creationDate": "2025-07-29T17:17:10Z", "mfaAuthenticated": "false" } }, "onBehalfOf": { "userId": "2801d3e0-f0e1-707f-54e8-f558b19f0a10", "identityStoreArn": "arn:aws:identitystore::777788889999:identitystore/d-1234567890" } }, ``` ## Runtime considerations If an administrator sets **MaxRuntimeInSeconds** for long-running training or processing jobs that is lower than the user background session duration, SageMaker Studio runs the job for the minimum of either **MaxRuntimeInSeconds ** or the user background session duration. For more information about **MaxRuntimeInSeconds**, see the guidance for the `CreateTrainingJob` [StoppingCondition](https://docs.aws.amazon.com//sagemaker/latest/APIReference/API_CreateTrainingJob.html#sagemaker-CreateTrainingJob-request-StoppingCondition) parameter in the *Amazon SageMaker API Reference*. # Authorization services In all [analytics and data lakehouse use cases](trustedidentitypropagation-integrations.md#tip-data-analytic-usecases-overview), you can achieve fine-grained access controls using: + AWS Lake Formation - for guidance, see [Setting up AWS Lake Formation with IAM Identity Center](tip-tutorial-lf.md). + Amazon S3 Access Grants - for guidance, see [Setting up Amazon S3 Access Grants with IAM Identity Center](tip-tutorial-s3.md). # Setting up AWS Lake Formation with IAM Identity Center AWS Lake Formation [AWS Lake Formation](https://docs.aws.amazon.com//lake-formation/latest/dg/what-is-lake-formation.html) is a managed service that simplifies the creation and management of data lakes on AWS. It automates data collection, cataloging, and security, providing a centralized repository for storing and analyzing diverse data types. Lake Formation offers fine-grained access controls and integrates with various AWS analytics services, enabling organizations to efficiently set up, secure, and derive insights from their data lakes. Follow these steps to enable Lake Formation to grant data permissions based on user identity using IAM Identity Center and trusted identity propagation. ## Prerequisites Before you can get started with this tutorial, you'll need to set up the following: + [Enable IAM Identity Center](enable-identity-center.md). [Organization instance](organization-instances-identity-center.md) is recommended. For more information, see [Prerequisites and considerations](trustedidentitypropagation-overall-prerequisites.md). ## Steps to set up trusted identity propagation 1. **Integrate IAM Identity Center with AWS Lake Formation** following the guidance in [Connecting Lake Formation with IAM Identity Center](https://docs.aws.amazon.com//lake-formation/latest/dg/connect-lf-identity-center.html). **Important** **If you do not have AWS Glue Data Catalog tables**, you must create them in order to use AWS Lake Formation to grant access to IAM Identity Center users and groups. See [Creating objects in AWS Glue Data Catalog](https://docs.aws.amazon.com//lake-formation/latest/dg/populating-catalog.html) for more information. 1. **Register data lake locations**. [Register the S3 locations](https://docs.aws.amazon.com//lake-formation/latest/dg/register-location.html) where the data of the Glue tables are stored. By doing this, Lake Formation will provision temporary access to the required S3 locations when the tables are queried, removing the need to include S3 permissions in the service role (e.g. the Athena service role configured on the WorkGroup). 1. Navigate to the **Data lake locations** under the **Administration** section in the navigation pane in the AWS Lake Formation console. Select **Register location**. This will allow Lake Formation to provision temporary IAM credentials with the necessary permissions to access S3 data locations. ![\[Step 1 Register data lake location in Lake Formation console.\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/lf-tutorial-step-3.1.png) 1. Enter the S3 path of the data locations of the AWS Glue tables in the **Amazon S3 path** field. 1. In the **IAM role** section, do not select the service linked role if you want to use it with trusted identity propagation. Create a separate role with the following permissions. To use these policies, replace the *italicized placeholder text* in the example policy with your own information. For additional directions, see [Create a policy](https://docs.aws.amazon.com//IAM/latest/UserGuide/access_policies_create.html) or [Edit a policy](https://docs.aws.amazon.com//IAM/latest/UserGuide/access_policies_manage-edit.html). The permission policy should grant access to the S3 location specified in the path: 1. **Permission policy**: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "LakeFormationDataAccessPermissionsForS3", "Effect": "Allow", "Action": [ "s3:PutObject", "s3:GetObject", "s3:DeleteObject" ], "Resource": [ "arn:aws:s3:::Your-S3-Bucket/*" ] }, { "Sid": "LakeFormationDataAccessPermissionsForS3ListBucket", "Effect": "Allow", "Action": [ "s3:ListBucket" ], "Resource": [ "arn:aws:s3:::Your-S3-Bucket" ] }, { "Sid": "LakeFormationDataAccessServiceRolePolicy", "Effect": "Allow", "Action": [ "s3:ListAllMyBuckets" ], "Resource": [ "arn:aws:s3:::*" ] } ] } ``` ------ 1. **Trust relationship**: This should include `sts:SectContext`, which is required for trusted identity propagation. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "", "Effect": "Allow", "Principal": { "Service": "lakeformation.amazonaws.com" }, "Action": [ "sts:AssumeRole", "sts:SetContext" ] } ] } ``` ------ **Note** The IAM role created by the wizard is a service-linked role and does not include `sts:SetContext`. 1. After creating the IAM role, select **Register location**. ## Trusted identity propagation with Lake Formation across AWS accounts AWS Lake Formation supports using [AWS Resource Access Manager (RAM)](https://docs.aws.amazon.com//ram/latest/userguide/what-is.html) to share tables across AWS accounts and it works with trusted identity propagation when the grantor account and grantee account are in the same AWS Region, in the same AWS Organizations, and share the same organization instance of IAM Identity Center. See [Cross-account data sharing in Lake Formation](https://docs.aws.amazon.com//lake-formation/latest/dg/cross-data-sharing-lf.html) for more information. # Setting up Amazon S3 Access Grants with IAM Identity Center Amazon S3 Access Grants [Amazon S3 Access Grants](https://docs.aws.amazon.com//AmazonS3/latest/userguide/access-grants-get-started.html) provides the flexibility to grant identity-based fine-grain access control to S3 locations. You can use Amazon S3 Access Grants to grant Amazon S3 bucket access directly to your corporate users and groups. Follow these steps to enable S3 Access Grants with IAM Identity Center and achieve trusted identity propagation. ## Prerequisites Before you can get started with this tutorial, you'll need to set up the following: + [Enable IAM Identity Center](enable-identity-center.md). [Organization instance](organization-instances-identity-center.md) is recommended. For more information, see [Prerequisites and considerations](trustedidentitypropagation-overall-prerequisites.md). ## Configuring S3 Access Grants for trusted identity propagation through IAM Identity Center **If you already have an Amazon S3 Access Grants instance with a registered location, follow these steps:** 1. [Associate your IAM Identity Center instance](https://docs.aws.amazon.com//AmazonS3/latest/userguide/access-grants-instance-idc.html). 1. [Create a grant](#tip-tutorial-s3-create-grant). **If you have not created an Amazon S3 Access Grants yet, follow these steps:** 1. [https://docs.aws.amazon.com//AmazonS3/latest/userguide/access-grants-instance-create.html](https://docs.aws.amazon.com//AmazonS3/latest/userguide/access-grants-instance-create.html) - You can create one S3 Access Grants instance per AWS Region. When you create the S3 Access Grants instance, make sure to check the **Add IAM Identity Center instance** box and provide the ARN of your IAM Identity Center instance. Select **Next**. The following image shows the Create S3 Access Grants instance page in the Amazon S3 Access Grants console: ![\[Create S3 Access Grants instance page in S3 Access Grants console.\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/s3-tutorial-step-1.1.png) 1. **Register a location** - After you create an [create an Amazon S3 Access Grants instance](https://docs.aws.amazon.com//AmazonS3/latest/userguide/access-grants-instance-create.html) in an AWS Region in your account, you [register an S3 location](https://docs.aws.amazon.com//AmazonS3/latest/userguide/access-grants-location-register.html) in that instance. An S3 Access Grants location maps the default S3 region (`S3://`), a bucket, or a prefix to an IAM role. S3 Access Grants assumes this Amazon S3 role to vend temporary credentials to the grantee that is accessing that particular location. You must first register at least one location in your S3 Access Grants instance before you can create an access grant. For the **Location scope**, specify `s3://`, which includes all of your buckets in that Region. This is the recommended location scope for most use cases. If you have an advanced access management use case, you can set the location scope to a specific bucket `s3://bucket`or prefix within a bucket `s3://bucket/prefix-with-path`. For more information, see [Register a location](https://docs.aws.amazon.com//AmazonS3/latest/userguide/access-grants-location-register.html) in the *Amazon Simple Storage Service User Guide*. **Note** Ensure the S3 locations of the AWS Glue tables you want to grant access to are included in this path. The procedure requires you to configure an IAM role for the location. This role should include permissions to access the location scope. You can use the S3 console wizard to create the role. You'll need to specify your S3 Access Grants instance ARN in the policies for this IAM role. The default value of your S3 Access Grants instance ARN is `arn:aws:s3:Your-Region:Your-AWS-Account-ID:access-grants/default`. The following example permission policy gives Amazon S3 permissions to the IAM role that you created. And the example trust policy following it allows the S3 Access Grants service principal to assume the IAM role. 1. **Permission policy** To use these policies, replace the *italicized placeholder text* in the example policy with your own information. For additional directions, see [Create a policy](https://docs.aws.amazon.com//IAM/latest/UserGuide/access_policies_create.html) or [Edit a policy](https://docs.aws.amazon.com//IAM/latest/UserGuide/access_policies_manage-edit.html). ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "ObjectLevelReadPermissions", "Effect": "Allow", "Action": [ "s3:GetObject", "s3:GetObjectVersion", "s3:GetObjectAcl", "s3:GetObjectVersionAcl", "s3:ListMultipartUploadParts" ], "Resource": [ "arn:aws:s3:::*" ], "Condition": { "StringEquals": { "aws:ResourceAccount": "111122223333" }, "ArnEquals": { "s3:AccessGrantsInstanceArn": [ "arn:aws:s3:::access-grants/instance-id" ] } } }, { "Sid": "ObjectLevelWritePermissions", "Effect": "Allow", "Action": [ "s3:PutObject", "s3:PutObjectAcl", "s3:PutObjectVersionAcl", "s3:DeleteObject", "s3:DeleteObjectVersion", "s3:AbortMultipartUpload" ], "Resource": [ "arn:aws:s3:::*" ], "Condition": { "StringEquals": { "aws:ResourceAccount": "111122223333" }, "ArnEquals": { "s3:AccessGrantsInstanceArn": [ "arn:aws:s3:::access-grants/instance-id" ] } } }, { "Sid": "BucketLevelReadPermissions", "Effect": "Allow", "Action": [ "s3:ListBucket" ], "Resource": [ "arn:aws:s3:::*" ], "Condition": { "StringEquals": { "aws:ResourceAccount": "111122223333" }, "ArnEquals": { "s3:AccessGrantsInstanceArn": [ "arn:aws:s3:::access-grants/instance-id" ] } } }, { "Sid": "OptionalKMSPermissionsForSSEEncryption", "Effect": "Allow", "Action": [ "kms:Decrypt", "kms:GenerateDataKey" ], "Resource": [ "*" ] } ] } ``` ------ 1. **Trust policy** In the IAM role trust policy, give the S3 Access Grants service (`access-grants.s3.amazonaws.com`) principal access to the IAM role that you created. To do so, you can create a JSON file that contains the following statements. To add the trust policy to your account, see [Create a role using custom trust policies](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_roles_create_for-custom.html). ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "Stmt1234567891011", "Effect": "Allow", "Action": [ "sts:AssumeRole", "sts:SetSourceIdentity" ], "Resource": "*", "Condition": { "StringEquals": { "aws:SourceAccount": "111122223333", "aws:SourceArn": "Your-Custom-Access-Grants-Location-ARN" } } }, { "Sid": "Stmt1234567891012", "Effect": "Allow", "Action": "sts:SetContext", "Resource": "*", "Condition": { "StringEquals": { "aws:SourceAccount": "111122223333", "aws:SourceArn": "Your-Custom-Access-Grants-Location-ARN" }, "ForAllValues:ArnEquals": { "sts:RequestContextProviders": "arn:aws:iam::aws:contextProvider/IdentityCenter" } } } ] } ``` ------ ## Create an Amazon S3 Access Grant If you have an Amazon S3 Access Grants instance with a registered location and you have associated your IAM Identity Center instance with it, you can [create a grant](https://docs.aws.amazon.com//AmazonS3/latest/userguide/access-grants-grant-create.html). In the S3 console **Create Grant** page, complete the following: **Create a grant** 1. Select the location created in the previous step. You can reduce the scope of the grant by adding a sub-prefix. The sub-prefix can be a `bucket`, `bucket/prefix`, or an object in the bucket. For more information, see [Subprefix](https://docs.aws.amazon.com//AmazonS3/latest/userguide/access-grants-grant-create.html#subprefix) in the *Amazon Simple Storage Service User Guide*. 1. Under **Permissions and access**, select **Read** and or **Write** depending on your needs. 1. In **Granter type**, choose **Directory Identity form IAM Identity Center**. 1. Provide the IAM Identity Center **User or Group ID**. You can find the user and group IDs in the IAM Identity Center console under [**User** and **Group** sections](howtoviewandchangepermissionset.md). Select **Next**. 1. On the **Review and Finish** page, review the settings for the S3 Access Grant and then select **Create Grant**. The following image shows the Create Grant page in the Amazon S3 Access Grants console: ![\[Create Grant page in Amazon S3 Access Grants console.\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/s3-tutorial-step-1.4.png) # Setting up your own OAuth 2.0 application Setting up your own OAuth 2.0 application Trusted identity propagation enables a customer managed application to request access to data in AWS services on behalf of a user. Data access management is based on a user’s identity, so administrators can grant access based on users' existing user and group memberships. The user's identity, actions performed on their behalf, and other events are recorded in service-specific logs and CloudTrail events. With trusted identity propagation, a user can sign in to a customer managed application, and that application can pass the user's identity in requests to access data in AWS services. **Important** To access an AWS service, customer managed applications must obtain a token from a trusted token issuer, which is external to IAM Identity Center. A *trusted token issuer* is an OAuth 2.0 authorization server that creates signed tokens. These tokens authorize applications that initiate requests for access to AWS services (receiving applications). For more information, see [Using applications with a trusted token issuer](using-apps-with-trusted-token-issuer.md). **Topics** + [ # Set up customer managed OAuth 2.0 applications for trusted identity propagation ](customermanagedapps-trusted-identity-propagation-set-up-your-own-app-OAuth2.md) + [ # Specify trusted applications ](trustedidentitypropagation-using-customermanagedapps-specify-trusted-apps.md) + [ # Using applications with a trusted token issuer ](using-apps-with-trusted-token-issuer.md) # Set up customer managed OAuth 2.0 applications for trusted identity propagation Set up customer managed applications To set up a customer managed OAuth 2.0 application for trusted identity propagation, you must first add it to IAM Identity Center. Use the following procedure to add your application to IAM Identity Center. **Topics** + [ ## Step 1: Select application type ](#customermanagedapps-trusted-identity-propagation-set-up-your-own-app-OAuth2-select-app-type) + [ ## Step 2: Specify application details ](#customermanagedapps-trusted-identity-propagation-set-up-your-own-app-OAuth2-specify-app-details) + [ ## Step 3: Specify authentication settings ](#customermanagedapps-trusted-identity-propagation-set-up-your-own-app-OAuth2-specify-authentication-settings) + [ ## Step 4: Specify application credentials ](#customermanagedapps-trusted-identity-propagation-set-up-your-own-app-OAuth2-specify-application-credentials) + [ ## Step 5: Review and configure ](#customermanagedapps-trusted-identity-propagation-set-up-your-own-app-OAuth2-review-and-configure) ## Step 1: Select application type Select application type 1. Open the [IAM Identity Center console](https://console.aws.amazon.com/singlesignon). 1. Choose **Applications**. 1. Choose the **Customer managed** tab. 1. Choose **Add application**. 1. On the **Select application type** page, under **Setup preference**, choose **I have an application I want to set up**. 1. Under **Application type**, choose **OAuth 2.0**. 1. Choose **Next** to proceed to the next page, [Step 2: Specify application details](#customermanagedapps-trusted-identity-propagation-set-up-your-own-app-OAuth2-specify-app-details). ## Step 2: Specify application details 1. On the **Specify application details** page, under **Application name and description**, enter a **Display name** for the application, such as **MyApp**. Then, enter a **Description**. 1. Under **User and group assignment method**, choose one of the following options: + **Require assignments** – Allow only IAM Identity Center users and groups who are assigned to this application to access the application. Application tile visibility –Only users who are assigned to the application directly or through a group assignment can view the application tile in the AWS access portal, provided that **Application visibility in AWS access portal** is set to **Visible**. + **Do not require assignments** – Allow all authorized IAM Identity Center users and groups to access this application. Application tile visibility – The application tile is visible to all users who sign in to the AWS access portal, unless **Application visibility in AWS access portal** is set to **Not visible**. 1. Under **AWS access portal**, enter the URL where users can access the application and specify whether the application tile will be visible or not visible in the AWS access portal. If you choose **Not visible**, not even assigned users can view the application tile. 1. Under **Tags (optional)**, choose **Add new tag**, and then specify values for **Key** and **Value (optional)**. For information about tags, see [Tagging AWS IAM Identity Center resources](tagging.md). 1. Choose **Next**, and proceed to the next page, [Step 3: Specify authentication settings](#customermanagedapps-trusted-identity-propagation-set-up-your-own-app-OAuth2-specify-authentication-settings). ## Step 3: Specify authentication settings To add a customer managed application that supports OAuth 2.0 to IAM Identity Center, you must specify a trusted token issuer. A trusted token issuer is an OAuth 2.0 authorization server that creates signed tokens. These tokens authorize applications that initiate requests (requesting applications) for access to AWS managed applications (receiving applications). 1. On the **Specify authentication settings** page, under **Trusted token issuers**, do either of the following: + To use an existing trusted token issuer: Select the check box next to the name of the trusted token issuer that you want to use. + To add a new trusted token issuer: 1. Choose **Create trusted token issuer**. 1. A new browser tab opens. Follow steps 5 through 8 in [How to add a trusted token issuer to the IAM Identity Center console](setuptrustedtokenissuer.md#how-to-add-trustedtokenissuer). 1. After you complete these steps, return to the browser window that you are using for your application setup and select the trusted token issuer that you just added. 1. In the list of trusted token issuers, select the check box next to the name of the trusted token issuer that you just added. After you select a trusted token issuer, the **Configure selected trusted token issuers** section appears. 1. Under **Configure selected trusted token issuers**, enter the **Aud claim**. The **Aud claim** identifies the intended audience (recipients) for the token that is generated by the trusted token issuer. For more information, see [Aud claim](trusted-token-issuer-configuration-settings.md#trusted-token-issuer-aud-claim). 1. To prevent your users from having to reauthenticate when they are using this application, select **Enable refresh token grant**. When selected, this option refreshes the access token for the session every 60 minutes, until the session expires or the user ends the session. 1. Choose **Next**, and proceed to the next page, [Step 4: Specify application credentials](#customermanagedapps-trusted-identity-propagation-set-up-your-own-app-OAuth2-specify-application-credentials). ## Step 4: Specify application credentials Complete the steps in this procedure to specify the credentials that your application uses to perform token exchange actions with trusted applications. These credentials are used in a resource-based policy. The policy requires that you specify a principal that has permissions to perform the actions that are specified in the policy. **You must specify a principal**, even if the trusted applications are in the same AWS account. **Note** When you set permissions with policies, grant only the permissions required to perform a task. You do this by defining the actions that can be taken on specific resources under specific conditions, also known as least-privilege permissions. This policy requires the [https://docs.aws.amazon.com/singlesignon/latest/OIDCAPIReference/API_CreateTokenWithIAM.html](https://docs.aws.amazon.com/singlesignon/latest/OIDCAPIReference/API_CreateTokenWithIAM.html) API action. For more information about this policy, and an example that you can adapt as required for your environment, see [Resource-based policy example for IAM Identity Center IAM Identity Center](iam-auth-access-using-resource-based-policies.md). 1. On the **Specify application credentials** page, do either of the following: + To quickly specify one or more IAM roles: 1. Choose **Enter one or more IAM roles**. 1. Under **Enter IAM roles**, specify the Amazon Resource Name (ARN) of an existing IAM role. To specify the ARN, use the following syntax. The Region portion of the ARN is blank because IAM resources are global. ``` arn:aws:iam::account:role/role-name-with-path ``` For more information, see [Cross-account access using resource-based policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html#access_policies-cross-account-using-resource-based-policies) and [IAM ARNs](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_identifiers.html#identifiers-arns) in the *AWS Identity and Access Management User Guide*. + To manually edit the policy (required if you specify non-AWS credentials): 1. Select **Edit the application policy**. 1. Modify your policy by typing or pasting text in the JSON text box. 1. Resolve any security warnings, errors, or general warnings generated during policy validation. For more information see [Validating IAM policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_policy-validator.html) in the *AWS Identity and Access Management User Guide*. 1. Choose **Next** and proceed to the next page, [Step 5: Review and configure](#customermanagedapps-trusted-identity-propagation-set-up-your-own-app-OAuth2-review-and-configure). ## Step 5: Review and configure 1. On the **Review and configure** page, review the choices that you made. To make changes, choose the configuration section that you want, choose **Edit**, and then make the required changes. 1. After you are finished, choose **Add application**. 1. The application that you added appears in the **Customer managed applications** list. 1. After you set up your customer managed application in IAM Identity Center, you must specify one or more AWS services, or trusted applications, for identity propagation. This enables users to sign in to your customer managed application and access data in the trusted application. For more information, see [Specify trusted applications](trustedidentitypropagation-using-customermanagedapps-specify-trusted-apps.md). # Specify trusted applications After you [set up your customer managed application](customermanagedapps-trusted-identity-propagation-set-up-your-own-app-OAuth2.md), you must specify one or more trusted AWS services, or trusted applications, for identity propagation. Specify an AWS service that has data that users of your customer managed applications need to access. When your users sign in to your customer managed application, that application will pass your users' identity to the trusted application. Use the following procedure to select a service, and then specify individual applications to trust for that service. 1. Open the [IAM Identity Center console](https://console.aws.amazon.com/singlesignon). 1. Choose **Applications**. 1. Choose the **Customer managed** tab. 1. In the **Customer managed applications** list, select the OAuth 2.0 application that you want to initiate requests for access. This is the application that your users sign in to. 1. On the **Details page**, under **Trusted applications for identity propagation**, choose **Specify trusted applications**. 1. Under **Setup type**, select **Individual applications and specify access**, and then choose **Next**. 1. On the **Select service** page, choose the AWS service that has applications that your customer managed application can trust for identity propagation, and then choose **Next**. The service that you select defines the applications that can be trusted. You'll select applications in the next step. 1. On the **Select applications** page, choose **Individual applications**, select the check box for each application that can receive requests for access, and then choose **Next**. 1. On the **Configure access** page, under **Configuration method**, do either of the following: + **Select access per application** – Select this option to configure different access levels for each application. Choose the application for which you want to configure the access level, and then choose **Edit access**. In **Level of access to apply**, change the access levels as needed, and then choose **Save changes**. + **Apply same level of access to all applications** – Select this option if you do not need to configure access levels on a per-application basis. 1. Choose **Next**. 1. On the **Review configuration** page, review the choices that you made. To make changes, choose the configuration section that you want, choose **Edit access**, and then make the required changes. 1. After you are finished, choose **Trust applications**. # Using applications with a trusted token issuer Trusted token issuer Trusted token issuers enable you to use trusted identity propagation with applications that authenticate outside of AWS. With trusted token issuers, you can authorize these applications to make requests on behalf of their users to access AWS managed applications. The following topics describe how trusted token issuers work and provide setup guidance. **Topics** + [ ## Trusted token issuer overview ](#trusted-token-issuer-overview) + [ ## Prerequisites and considerations for trusted token issuers ](#trusted-token-issuer-prerequisites) + [ ## JTI claim details ](#trusted-token-issuer-configuration-jti-claim) + [ # Trusted token issuer configuration settings ](trusted-token-issuer-configuration-settings.md) + [ # Setting up a trusted token issuer ](setuptrustedtokenissuer.md) + [ # Identity-enhanced IAM role sessions ](trustedidentitypropagation-identity-enhanced-iam-role-sessions.md) ## Trusted token issuer overview Trusted identity propagation provides a mechanism that enables applications that authenticate outside of AWS to make requests on behalf of their users with the use of a trusted token issuer. A *trusted token issuer* is an OAuth 2.0 authorization server that creates signed tokens. These tokens authorize applications that initiate requests (requesting applications) for access to AWS services(receiving applications). Requesting applications initiate access requests on behalf of users that the trusted token issuer authenticates. The users are known to both the trusted token issuer and IAM Identity Center. AWS services that receive requests manage fine-grained authorization to their resources based on their users and group membership as represented in the Identity Center directory. AWS services cannot use the tokens from the external token issuer directly. To solve this, IAM Identity Center provides a way for the requesting application, or an AWS driver that the requesting application uses, to exchange the token issued by the trusted token issuer for a token that is generated by IAM Identity Center. The token that is generated by IAM Identity Center refers to the corresponding IAM Identity Center user. The requesting application, or the driver, uses the new token to initiate a request to the receiving application. Because the new token references the corresponding user in IAM Identity Center, the receiving application can authorize the requested access based on the user or their group membership as represented in IAM Identity Center. **Important** Choosing an OAuth 2.0 authorization server to add as a trusted token issuer is a security decision that requires careful consideration. Only choose trusted token issuers that you trust to perform the following tasks: Authenticate the user who is specified in the token. Authorize that user’s access to the receiving application. Generate a token that IAM Identity Center can exchange for an IAM Identity Center created token. ## Prerequisites and considerations for trusted token issuers Before you set up a trusted token issuer, review the following prerequisites and considerations. + **Trusted token issuer configuration** You must configure an OAuth 2.0 authorization server (the trusted token issuer). Although the trusted token issuer is typically the identity provider that you use as your identity source for IAM Identity Center, it doesn’t have to be. For information about how to set up the trusted token issuer, see the documentation for the relevant identity provider. **Note** You can configure up to 10 trusted token issuers for use with IAM Identity Center, as long you map the identity of each user in the trusted token issuer to a corresponding user in IAM Identity Center. + The OAuth 2.0 authorization server (the trusted token issuer) that creates the token must have an [OpenID Connect (OIDC)](https://openid.net/specs/openid-connect-discovery-1_0.html) discovery endpoint that IAM Identity Center can use to obtain public keys to verify the token signatures. For more information, see [OIDC discovery endpoint URL (issuer URL)](trusted-token-issuer-configuration-settings.md#oidc-discovery-endpoint-url). + **Tokens issued by the trusted token issuer** Tokens from the trusted token issuer must meet the following requirements: + The token must be signed and in [JSON Web Token (JWT)](https://datatracker.ietf.org/doc/html/rfc7519#section-3) format using the RS256 algorithm. + The token must contain the following claims: + [Issuer](https://datatracker.ietf.org/doc/html/rfc7519#section-4.1.1) (iss) – The entity that issued the token. This value must match the value that is configured in the OIDC discovery endpoint (issuer URL) in the trusted token issuer. + [Subject](https://datatracker.ietf.org/doc/html/rfc7519#section-4.1.2) (sub) – The authenticated user. + [Audience](https://datatracker.ietf.org/doc/html/rfc7519#section-4.1.3) (aud) – The intended recipient of the token. This is the AWS service that will be accessed after the token is exchanged for a token from IAM Identity Center. For more information, see [Aud claim](trusted-token-issuer-configuration-settings.md#trusted-token-issuer-aud-claim). + [Expiration Time](https://datatracker.ietf.org/doc/html/rfc7519#section-4.1.4) (exp) – The time after which the token expires. + The token can be an identity token or an access token. + The token must have an attribute that can be mapped uniquely to one IAM Identity Center user. **Note** Using a custom signing key for JWTs from Microsoft Entra ID is not supported. In order to use tokens from Microsoft Entra ID with trusted token issuer, you can't use a custom signing key. + **Optional claims** IAM Identity Center supports all optional claims that are defined in RFC 7523. For more information, see [Section 3: JWT Format and Processing Requirements](https://datatracker.ietf.org/doc/html/rfc7523#section-3) of this RFC. For example, the token can contain a [JTI (JWT ID) claim](https://datatracker.ietf.org/doc/html/rfc7519#section-4.1.7). This claim, when present, prevents tokens that have the same JTI from being reused for token exchanges. For more information about JTI claims, see [JTI claim details](#trusted-token-issuer-configuration-jti-claim). + **IAM Identity Center configuration to work with a trusted token issuer** You must also enable IAM Identity Center, configure the identity source for IAM Identity Center, and provision users that correspond to the users in the trusted token issuer’s directory. To do this, you must do either of the following: + Synchronize users into IAM Identity Center by using the System for Cross-domain Identity Management (SCIM) 2.0 protocol. + Create the users directly in IAM Identity Center. ## JTI claim details If IAM Identity Center receives a request to exchange a token that IAM Identity Center has already exchanged, the request fails. To detect and prevent reuse of a token for token exchanges, you can include a JTI claim. IAM Identity Center protects against the replay of tokens based on the claims in the token. Not all OAuth 2.0 authorization servers add a JTI claim to tokens. Some OAuth 2.0 authorization servers might not allow you to add a JTI as a custom claim. OAuth 2.0 authorization servers that support the use of a JTI claim might add this claim to identity tokens only, access tokens only, or both. For more information, see the documentation for your OAuth 2.0 authorization server. For information about building applications that exchange tokens, see the IAM Identity Center API documentation. For information about configuring a customer managed application to obtain and exchange the correct tokens, see the documentation for the application. # Trusted token issuer configuration settings The following sections describe the settings required to set up and use a trusted token issuer. **Topics** + [ ## OIDC discovery endpoint URL (issuer URL) ](#oidc-discovery-endpoint-url) + [ ## Attribute mapping ](#trusted-token-issuer-attribute-mappings) + [ ## Aud claim ](#trusted-token-issuer-aud-claim) ## OIDC discovery endpoint URL (issuer URL) When you add a trusted token issuer to the IAM Identity Center console, you must specify the OIDC discovery endpoint URL. This URL is commonly referred to by its relative URL, `/.well-known/openid-configuration`. In the IAM Identity Center console, this URL is called the *issuer URL*. **Note** You must paste the URL of the discovery endpoint *up until and without* `.well-known/openid-configuration`. If `.well-known/openid-configuration` is included in the URL, the trusted token issuer configuration will not work. Because IAM Identity Center doesn't validate this URL, if the URL isn't correctly formed, the trusted token issuer setup will fail without notification. The OIDC discovery endpoint URL must be reachable via ports 80 and 443 only. IAM Identity Center uses this URL to obtain additional information about the trusted token issuer. For example, IAM Identity Center uses this URL to obtain the information required to verify the tokens that the trusted token issuer generates. When you add a trusted token issuer to IAM Identity Center, you must specify this URL. To find the URL, see the documentation for the OAuth 2.0 authorization server provider that you use to generate tokens for your application, or contact the provider directly for assistance. ## Attribute mapping Attribute mappings enable IAM Identity Center to match the user that is represented in a token issued by a trusted token issuer to a single user in IAM Identity Center. You must specify the attribute mapping when you add the trusted token issuer to IAM Identity Center. This attribute mapping is used in a claim in the token that is generated by the trusted token issuer. The value in the claim is used to search IAM Identity Center. The search uses the specified attribute to retrieve a single user in IAM Identity Center, who will be used as the user within AWS. The claim that you choose must be mapped to one attribute in a fixed list of available attributes in the IAM Identity Center identity store. You can choose one of the following IAM Identity Center identity store attributes: user name, email, and external ID. The value for the attribute that you specify in IAM Identity Center must be unique for each user. ## Aud claim An *aud claim* identifies the audience (recipients) for which a token is intended. When the application requesting access authenticates through an identity provider that is not federated to IAM Identity Center, that identity provider must be set up as a trusted token issuer. The application that receives the access request (the receiving application) must exchange the token that is generated by the trusted token issuer for a token that is generated by IAM Identity Center. For information about how to obtain the aud claim values for the receiving application as they are registered in the trusted token issuer, see the documentation for your trusted token issuer or contact the trusted token issuer administrator for assistance. # Setting up a trusted token issuer To enable trusted identity propagation for an application that authenticates externally to IAM Identity Center, one or more administrators must set up a trusted token issuer. A trusted token issuer is an OAuth 2.0 authorization server that issues tokens to applications that initiate requests (requesting applications). The tokens authorize these applications to initiate requests on behalf of their users to a receiving application (an AWS service). **Topics** + [ ## Coordinating administrative roles and responsibilities ](#coordinating-administrative-roles-responsibilities) + [ ## Tasks for setting up a trusted token issuer ](#setuptrustedtokenissuer-tasks) + [ ## How to add a trusted token issuer to the IAM Identity Center console ](#how-to-add-trustedtokenissuer) + [ ## How to view or edit trusted token issuer settings in the IAM Identity Center console ](#view-edit-trusted-token-issuers) + [ ## Setup process and request flow for applications that use a trusted token issuer ](#setuptrustedtokenissuer-setup-process-request-flow) ## Coordinating administrative roles and responsibilities In some cases, a single administrator might perform all of the necessary tasks for setting up a trusted token issuer. If multiple administrators perform these tasks, close coordination is required. The following table describes how multiple administrators might coordinate to set up a trusted token issuer and configure AWS service to use it. **Note** The application can be any AWS service that is integrated with IAM Identity Center and supports trusted identity propagation. For more information, see [Tasks for setting up a trusted token issuer](#setuptrustedtokenissuer-tasks). **** | Role | Performs these tasks | Coordinates with | | --- | --- | --- | | IAM Identity Center administrator | Adds the external IdP as a trusted token issuer to the IAM Identity Center console. Helps set up the correct attribute mapping between IAM Identity Center and the external IdP. Notifies the AWS service administrator when the trusted token issuer is added to the IAM Identity Center console. | External IdP (trusted token issuer) administrator AWS service administrator | | External IdP (trusted token issuer) administrator | Configures the external IdP to issue tokens. Helps set up the correct attribute mapping between IAM Identity Center and the external IdP. Provides the audience name (Aud claim) to the AWS service administrator. | IAM Identity Center administrator AWS service administrator | | AWS service administrator | Checks the AWS service console for the trusted token issuer. The trusted token issuer will be visible in the AWS service console after the IAM Identity Center administrator adds it to the IAM Identity Center console. Configures the AWS service to use the trusted token issuer. | IAM Identity Center administrator External IdP (trusted token issuer) administrator | ## Tasks for setting up a trusted token issuer To set up a trusted token issuer, an IAM Identity Center administrator, external IdP (trusted token issuer) administrator, and application administrator must complete the following tasks. **Note** The application can be any AWS service that is integrated with IAM Identity Center and supports trusted identity propagation. 1. **Add the trusted token issuer to IAM Identity Center** – The IAM Identity Center administrator [adds the trusted token issuer by using the IAM Identity Center console ](#how-to-add-trustedtokenissuer) or [APIs](https://docs.aws.amazon.com/singlesignon/latest/APIReference/API_Operations.html). This configuration requires specifying the following: + A name for the trusted token issuer. + The OIDC discovery endpoint URL (in the IAM Identity Center console, this URL is called the *issuer URL*). The discovery endpoint must be reachable via ports 80 and 443 only. + Attribute mapping for user lookup. This attribute mapping is used in a claim in the token that is generated by the trusted token issuer. The value in the claim is used to search IAM Identity Center. The search uses the specified attribute to retrieve a single user in IAM Identity Center. 1. **Connect the AWS service to IAM Identity Center** – The AWS service administrator must connect the application to IAM Identity Center by using the console for the application or the application APIs. After the trusted token issuer is added to the IAM Identity Center console, it is also visible in the AWS service console and available for the AWS service administrator to select. 1. **Configure the use of token exchange** – In the AWS service console, the AWS service administrator configures AWS service to accept tokens issued by the trusted token issuer. These tokens are exchanged for tokens generated by IAM Identity Center. This requires specifying the name of the trusted token issuer from Step 1, and the Aud claim value that corresponds to the AWS service. The trusted token issuer places the Aud claim value in the token it issues to indicate that the token is intended for use by the AWS service. To obtain this value, contact the administrator for the trusted token issuer. ## How to add a trusted token issuer to the IAM Identity Center console In an organization that has multiple administrators, this task is performed by an IAM Identity Center administrator. If you are the IAM Identity Center administrator, you must choose which external IdP to use as a trusted token issuer. **To add a trusted token issuer to the IAM Identity Center console** 1. Open the [IAM Identity Center console](https://console.aws.amazon.com/singlesignon). 1. Choose **Settings**. 1. On the **Settings** page, choose the **Authentication** tab. 1. Under **Trusted token issuers**, choose **Create trusted token issuer**. 1. On the **Set up an external IdP to issue trusted tokens** page, under **Trusted token issuer details**, do the following: + For **Issuer URL**, specify the [OIDC discovery URL](trusted-token-issuer-configuration-settings.md#oidc-discovery-endpoint-url) of the external IdP that will issue tokens for trusted identity propagation. You must specify the URL of the discovery endpoint up until and without `.well-known/openid-configuration`. The administrator of the external IdP can provide this URL. **Note** Note This URL must match the URL in the Issuer (iss) claim in tokens that are issued for trusted identity propagation. + For **Trusted token issuer name**, enter a name to identify this trusted token issuer in IAM Identity Center and in the application console. 1. Under **Map attributes**, do the following: + For **Identity provider attribute**, select an attribute from the list to map to an attribute in the IAM Identity Center identity store. + For **IAM Identity Center attribute**, select the corresponding attribute for the attribute mapping. 1. Under **Tags (optional)**, choose **Add new tag**, specify a value for **Key**, and optionally for **Value**. For information about tags, see [Tagging AWS IAM Identity Center resources](tagging.md). 1. Choose **Create trusted token issuer**. 1. After you finish creating the trusted token issuer, contact the application administrator to let them know the name of the trusted token issuer, so that they can confirm that the trusted token issuer is visible in the applicable console. 1. The application administrator must select this trusted token issuer in the applicable console to enable user access to the application from applications that are configured for trusted identity propagation. ## How to view or edit trusted token issuer settings in the IAM Identity Center console After you add a trusted token issuer to the IAM Identity Center console, you can view and edit the relevant settings. If you plan to edit the trusted token issuer settings, keep in mind that doing so might cause users to lose access to any applications that are configured to use the trusted token issuer. To avoid disrupting user access, we recommend that you coordinate with the administrators for any applications that are configured to use the trusted token issuer before you edit settings. **To view or edit trusted token issuer settings in the IAM Identity Center console** 1. Open the [IAM Identity Center console](https://console.aws.amazon.com/singlesignon). 1. Choose **Settings**. 1. On the **Settings** page, choose the **Authentication** tab. 1. Under **Trusted token issuers**, select the trusted token issuer that you want to view or edit. 1. Choose **Actions**, and then choose **Edit**. 1. On the **Edit trusted token issuer** page, view or edit settings as needed. You can edit the trusted token issuer name, attribute mappings, and tags. 1. Choose **Save changes**. 1. In the **Edit trusted token issuer** dialog box, you are prompted to confirm that you want to make changes. Choose **Confirm**. ## Setup process and request flow for applications that use a trusted token issuer This section describes the setup process and request flow for applications that use a trusted token issuer for trusted identity propagation. The following diagram provides an overview of this process. ![\[Setup process and request flows for apps using trusted token issuer for trusted identity propagation\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/trusted-identity-propagation-trusted-token-issuer-request-flow.png) The following steps provide additional information about this process. 1. Set up IAM Identity Center and the receiving AWS managed application to use a trusted token issuer. For information, see [Tasks for setting up a trusted token issuer](#setuptrustedtokenissuer-tasks). 1. The request flow begins when a user opens the requesting application. 1. The requesting application requests a token from the trusted token issuer to initiate requests to the receiving AWS managed application. If the user hasn't authenticated yet, this process triggers an authentication flow. The token contains the following information: + The subject (Sub) of the user. + The attribute that IAM Identity Center uses to look up the corresponding user in IAM Identity Center. + An audience (Aud) claim that contains a value that the trusted token issuer associates with the receiving AWS managed application. If other claims are present, they aren't used by IAM Identity Center. 1. The requesting application, or the AWS driver that it uses, passes the token to IAM Identity Center and requests that the token be exchanged for a token that is generated by IAM Identity Center. If you use an AWS driver, you might need to configure the driver for this use case. For more information, see the documentation for the relevant AWS managed application. 1. IAM Identity Center uses the OIDC Discovery endpoint to obtain the public key that it can use to verify the authenticity of the token. IAM Identity Center then does the following: + Verifies the token. + Searches the Identity Center directory. To do this, IAM Identity Center uses the mapped attribute specified in the token. + Verifies that the user is authorized to access the receiving application. If the AWS managed application is configured to require assignments to users and groups, the user must have a direct or group-based assignment to the application; otherwise the request is denied. If the AWS managed application is configured to not require user and group assignments, processing continues. **Note** AWS services have a default setting configuration that determines whether assignments are required for users and groups. We recommend that you do not modify the **Require assignments** setting for these applications if you plan to use them with trusted identity propagation. Even if you have configured fine-grained permissions that allow user access to specific application resources, modifying the **Require assignments** setting might result in unexpected behavior, including disrupted user access to these resources. + Verifies that the requesting application is configured to use valid scopes for the receiving AWS managed application. 1. If the previous verification steps are successful, IAM Identity Center creates a new token. The new token is an opaque (encrypted) token that includes the identity of the corresponding user in IAM Identity Center, the audience (Aud) of the receiving AWS managed application, and the scopes that the requesting application can use when making requests to the receiving AWS managed application. 1. The requesting application, or the driver that it uses, initiates a resource request to the receiving application and passes the token that IAM Identity Center generated to the receiving application. 1. The receiving application makes calls to IAM Identity Center to obtain the identity of the user and the scopes that are encoded in the token. It might also make requests to obtain user attributes or the user’s group memberships from the Identity Center directory. 1. The receiving application uses its authorization configuration to determine if the user is authorized to access the requested application resource. 1. If the user is authorized to access the requested application resource, the receiving application responds to the request. 1. The user's identity, actions performed on their behalf, and other events are recorded in the receiving application logs and CloudTrail events. The specific way in which this information is logged varies based on the application. # Identity-enhanced IAM role sessions The [AWS Security Token Service](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_sts-comparison.html) (STS) enables an application to obtain an identity-enhanced IAM role session. Identity-enhanced role sessions have an added identity context that carries a user identifier to the AWS service that it calls. AWS services can look up the group memberships and attributes of the user in IAM Identity Center and use them to authorize the user’s access to resources. AWS applications obtain identity-enhanced role sessions by making requests to the AWS STS [AssumeRole](https://docs.aws.amazon.com//STS/latest/APIReference/API_AssumeRole.html) API action and passing a context assertion with the user’s identifier (`userId`) in the `ProvidedContexts` parameter of the request to `AssumeRole`. The context assertion is obtained from the `idToken` claim received in response to a request to `SSO OIDC` to [https://docs.aws.amazon.com/singlesignon/latest/OIDCAPIReference/API_CreateTokenWithIAM.html](https://docs.aws.amazon.com/singlesignon/latest/OIDCAPIReference/API_CreateTokenWithIAM.html). When an AWS application uses an identity-enhanced role session to access a resource, CloudTrail logs the `userId`, the initiating session, and the action taken. For more information, see [Identity-enhanced IAM role session logging](#trustedidentitypropagation-identity-enhanced-iam-role-session-logging). **Topics** + [ ## Types of identity-enhanced IAM role sessions ](#types-identity-enhanced-iam-role-sessions) + [ ## Identity-enhanced IAM role session logging ](#trustedidentitypropagation-identity-enhanced-iam-role-session-logging) ## Types of identity-enhanced IAM role sessions AWS STS can create two different types of identity-enhanced IAM role sessions, depending on the context assertion provided to the `AssumeRole` request. Applications that have obtained Id tokens from IAM Identity Center can add `sts:identiy_context` (recommended) or `sts:audit_context` (Supported for backward compatibility) to IAM role sessions. An identity-enhanced IAM role session can have only one of these context assertions, not both. ### Identity-enhanced IAM role sessions created with `sts:identity_context` When an identity-enhanced role session contains `sts:identity_context` the called AWS service determines if resource authorization is based on the user who is represented in the role session, or if it is based on the role. AWS services that support user-based authorization provide the application's administrator with controls to assign access to the user or to groups for which the user is a member. AWS services that do not support user-based authorization disregard the `sts:identity_context`. CloudTrail logs the userId of the IAM Identity Center user with all actions taken by the role. For more information, see [Identity-enhanced IAM role session logging](#trustedidentitypropagation-identity-enhanced-iam-role-session-logging). To obtain this type of identity-enhanced role session from AWS STS, applications provide the value of the `sts:identity_context` field in the [AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) request using the `ProvidedContexts` request parameter. Use `arn:aws:iam::aws:contextProvider/IdentityCenter` as the value for `ProviderArn`. For more information on how the authorization behaves, see the documentation for the receiving AWS service. ### Identity-enhanced IAM role sessions created with `sts:audit_context` In the past, `sts:audit_context` was used to enable AWS services to log the user identity without using it to make an authorization decision. AWS services are now able to use a single context - `sts:identity_context` - to achieve this as well as to make authorization decisions. We recommend using `sts:identity_context` in all new deployments of trusted identity propagation. ## Identity-enhanced IAM role session logging When a request is made to an AWS service using an identity-enhanced IAM role session, the user's IAM Identity Center `userId` is logged to CloudTrail in the `OnBehalfOf` element. The way in which events are logged in CloudTrail varies based on the AWS service. Not all AWS services log the `onBehalfOf` element. The following is an example of how a request made to an AWS service using an identity-enhanced role session is logged in CloudTrail. ``` "userIdentity": { "type": "AssumedRole", "principalId": "AROAEXAMPLE:MyRole", "arn": "arn:aws:sts::111111111111:assumed-role/MyRole/MySession", "accountId": "111111111111", "accessKeyId": "ASIAEXAMPLE", "sessionContext": { "sessionIssuer": { "type": "Role", "principalId": "AROAEXAMPLE", "arn": "arn:aws:iam::111111111111:role/MyRole", "accountId": "111111111111", "userName": "MyRole" }, "attributes": { "creationDate": "2023-12-12T13:55:22Z", "mfaAuthenticated": "false" } }, "onBehalfOf": { "userId": "11111111-1111-1111-1111-1111111111", "identityStoreArn": "arn:aws:identitystore::111111111111:identitystore/d-111111111" } } ``` # Rotate IAM Identity Center certificates Rotate certificates IAM Identity Center uses certificates to set up a SAML trust relationship between IAM Identity Center and your application's service provider. When you add an application in IAM Identity Center, an IAM Identity Center certificate is automatically created for use with that application during the setup process. By default, this autogenerated IAM Identity Center certificate is valid for a period of five years. As an IAM Identity Center administrator, you'll occasionally need to replace older certificates with newer ones for a given application. For example, you might need to replace a certificate when the expiration date on the certificate approaches. The process of replacing an older certificate with a newer one is referred to as *certificate rotation*. ## Considerations before rotating a certificate Before you start the process of rotating a certificate in IAM Identity Center, consider the following: + The certification rotation process requires that you reestablish the trust between IAM Identity Center and the service provider. To reestablish the trust, use the procedures provided in [Rotate an IAM Identity Center certificate](rotatecert.md). + Updating the certificate with the service provider may cause a temporary service disruption for your users until the trust has been successfully reestablished. Plan this operation carefully during off peak hours if possible. # Rotate an IAM Identity Center certificate Rotating an IAM Identity Center certificate is a multistep process that involves the following: + Generating a new certificate + Adding the new certificate to the service provider’s website + Setting the new certificate to active + Deleting the inactive certificate Use all of the following procedures in the following order to complete the certificate rotation process for a given application. ## Step 1: Generate a new certificate New IAM Identity Center certificates that you generate can be configured to use the following properties: + **Validity period** – Specifies the time allotted (in months) before a new IAM Identity Center certificate expires. + **Key size** – Determines the number of bits that a key must use with its cryptographic algorithm. You can set this value to either 1024-bit RSA or 2048-bit RSA. For general information about how key sizes work in cryptography, see [Key size](https://en.wikipedia.org/wiki/Key_size). + **Algorithm** – Specifies the algorithm that IAM Identity Center uses when signing the SAML assertion/response. You can set this value to either SHA-1 or SHA-256. AWS recommends using SHA-256 when possible, unless your service provider requires SHA-1. For general information about how cryptography algorithms work, see [Public-key cryptography](https://en.wikipedia.org/wiki/Public-key_cryptography). 1. Open the [IAM Identity Center console](https://console.aws.amazon.com/singlesignon). 1. Choose **Applications**. 1. In the list of applications, choose the application that you want to generate a new certificate for. 1. On the application details page, choose the **Configuration** tab. Under **IAM Identity Center metadata**, choose **Manage certificate**. If you do not have a **Configuration** tab or the configuration setting is not available, you do not need to rotate the certificate for this application. 1. On the **IAM Identity Center certificate** page, choose **Generate new certificate**. 1. In the **Generate new IAM Identity Center certificate** dialog box, specify the appropriate values for **Validity period**, **Algorithm**, and **Key size**. Then choose **Generate**. ## Step 2: Update the service provider's website Use the following procedure to reestablish the trust with the application's service provider. **Important** When you upload the new certificate to the service provider, your users might not be able to get authenticated. To correct this situation, set the new certificate as active as described in the next step. 1. In the [IAM Identity Center console](https://console.aws.amazon.com/singlesignon), choose the application that you just generated a new certificate for. 1. On the application details page, choose **Edit configuration**. 1. Choose **View instructions**, and then follow the instructions for your specific application service provider’s website to add the newly generated certificate. ## Step 3: Set the new certificate to active An application can have up to two certificates assigned to it. IAM Identity Center will use the certification that is set as active to sign all SAML assertions. 1. Open the [IAM Identity Center console](https://console.aws.amazon.com/singlesignon). 1. Choose **Applications**. 1. In the list of applications, choose your application. 1. On the application details page, choose the **Configuration** tab. Under **IAM Identity Center metadata**, choose **Manage certificate**. 1. On the **IAM Identity Center certificate** page, select the certificate you want to set to active, choose **Actions**, and then choose **Set as active**. 1. In the **Set the selected certificate as active** dialog, confirm that you understand that setting a certificate to active may require you to re-establish the trust, and then choose **Make active**. ## Step 4: Delete the old certificate Use the following procedure to complete the certificate rotation process for your application. You can only delete a certificate that is in an **Inactive** state. 1. Open the [IAM Identity Center console](https://console.aws.amazon.com/singlesignon). 1. Choose **Applications**. 1. In the list of applications, choose your application. 1. On the application details page, select the **Configuration** tab. Under **IAM Identity Center metadata**, choose **Manage certificate**. 1. On the **IAM Identity Center certificate** page, select the certificate you want to delete. Choose **Actions** and then choose **Delete**. 1. In the **Delete certificate** dialog box, choose **Delete**. # Certificate expiration status indicators In the IAM Identity Center console, the **Applications** page displays status indicator icons in the properties of each application. These icons display in the **Expires on** column next to each certificate in the list. The following describes the criteria that IAM Identity Center uses to determine which icon displays for each certificate. + **Red** – Indicates that a certificate is currently expired. + **Yellow** – Indicates that a certificate will expire in 90 days or less. + **Green** – Indicates that a certificate is currently valid and will remain valid for at least 90 more days. **To check the status of a certificate** 1. Open the [IAM Identity Center console](https://console.aws.amazon.com/singlesignon). 1. Choose **Applications**. 1. In the list of applications, review the status of the certificates in the list as indicated in the **Expires on** column. # Understand application properties in the IAM Identity Center console Understand application properties In IAM Identity Center you can customize the user experience by configuring the application start URL, relay state, and session duration. ## Application start URL You use an application start URL to start the federation process with your application. The typical use is for an application that supports only service provider (SP)-initiated binding. The following steps and diagram illustrate the application start URL authentication workflow when a user chooses an application in the AWS access portal: 1. The user’s browser redirects the authentication request using the value for the application start URL (in this case https://example.com). 1. The application sends an `HTML` `POST` with a `SAMLRequest` to IAM Identity Center. 1. IAM Identity Center then sends an `HTML` `POST` with a `SAMLResponse` back to the application. ![\[Diagram shows app start URL auth workflow: steps when user chooses app in the AWS access portal.\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/app_properties_start_url.png) ## Relay state During the federation authentication process, the relay state redirects users within the application. For SAML 2.0, this value is passed, unmodified, to the application. After the application properties are configured, IAM Identity Center sends the relay state value along with a SAML response to the application. ![\[Diagram shows federation auth process: relay state, SAML 2.0, IAM Identity Center, app receives response.\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/app_properties_relay_state.png) ## Session duration Session duration is the length of time for which an application user session is valid. For SAML 2.0, this is used to set the `SessionNotOnOrAfter` date of the SAML assertion's element `saml2:AuthNStatement`. Session duration can be interpreted by applications in either of the following ways: + Applications can use it to determine the maximum time that is allowed for the user's session. Applications might generate a user session with a shorter duration. This can happen when the application only supports user sessions with a duration that is shorter than the configured session length. + Applications can use it as the exact duration and might not allow administrators to configure the value. This can happen when the application only supports a specific session length. For more information about how session duration is used, see your specific application’s documentation. # Assign user access to applications in the IAM Identity Center console Assign user access to applications You can assign users single sign-on access to SAML 2.0 applications in the application catalog or to custom SAML 2.0 applications. Considerations for group assignments: + **Assign access directly to groups.** To help simplify administration of access permissions, we recommend that you assign access directly to groups rather than to individual users. With groups you can grant or deny permissions to groups of users, instead of applying those permissions to each individual. If a user moves to a different organization, you simply move that user to a different group. The user then automatically receives the permissions that are needed for the new organization. + **Nested groups aren't supported.** When assigning user access to applications, IAM Identity Center doesn't support users being added to nested groups. If a user is added to a nested group, they might receive a “You do not have any applications” message during sign-in. Assignments must be made against the immediate group for which the user is a member. **To assign user or group access to applications** **Important** For AWS managed applications, you must add users directly from within the relevant application consoles or through the APIs. 1. Open the [IAM Identity Center console](https://console.aws.amazon.com/singlesignon). **Note** If you manage users in AWS Managed Microsoft AD, make sure that the IAM Identity Center console is using the AWS Region where your AWS Managed Microsoft AD directory is located before taking the next step. 1. Choose **Applications**. 1. In the list of applications, choose the application name to which you want to assign access. 1. On the application details page, in the **Assigned users** section, choose **Assign users**. 1. In the **Assign users** dialog box, enter a user display name or group name. You can specify multiple users or groups by selecting the applicable accounts as they appear in search results. 1. Choose **Assign users**. # Remove user access to SAML 2.0 applications Remove user access to applications Use this procedure to remove user access to SAML 2.0 applications in the application catalog or custom SAML 2.0 applications. For more information on authentication sessions and durations, see [Understanding authentication sessions in IAM Identity Center](authconcept.md). **To remove user access to an application** 1. Open the [IAM Identity Center console](https://console.aws.amazon.com/singlesignon). 1. Choose **Applications**. 1. In the list of applications, choose the application from which you want to remove user access. 1. On the application details page, in the **Assigned users** section, select the user or group that you want to remove and then choose the **Remove access** button. 1. In the **Remove access** dialog box, verify the user or group name. Then choose **Remove access**. # Map attributes in your application to IAM Identity Center attributes Map attributes Some service providers require custom SAML assertions to pass additional data about your user sign-ins. In that case, use the following procedure to specify how your applications user attributes should map to corresponding attributes in IAM Identity Center. **To map application attributes to attributes in IAM Identity Center** 1. Open the [IAM Identity Center console](https://console.aws.amazon.com/singlesignon). 1. Choose **Applications**. 1. In the list of applications, choose the application where you want to map attributes. 1. On the application details page, choose the **Actions** and then choose **Edit attribute mapping**. 1. Choose **Add new attribute mapping**. 1. In the first text box, enter the application attribute. 1. In the second text box, enter the attribute in IAM Identity Center that you want to map to the application attribute. For example, you might want to map the application attribute **Username** to the IAM Identity Center user attribute **email**. To see the list of allowed user attributes in IAM Identity Center, see the table in [Attribute mappings between IAM Identity Center and External Identity Providers directory](attributemappingsconcept.md). 1. In the third column of the table, choose the appropriate format for the attribute from the menu. 1. Choose **Save changes**.