# 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)