Question

Difficulty: HardMulti-Account Identity and Access Management Federation

A financial services company is implementing a multi-account AWS environment managed by AWS Organizations. The company utilizes a central Identity account to federate corporate identities from an on-premises Active Directory Federation Services (AD FS) server using SAML 2.0. Users first federate into a baseline IAM role in the Identity account. From there, they assume target IAM roles in various Member accounts using the AWS Security Token Service (AWS STS) cross-account role assumption pattern.

The security team requires Attribute-Based Access Control (ABAC) to restrict access to resources. When users federate into the Identity account, the SAML assertion includes the user's department as a session tag. However, when users attempt to assume the target IAM roles in the Member accounts while passing this session tag, the `sts:AssumeRole` API call fails with an Access Denied error.

Which of the following configuration changes is required to resolve this issue and enable session tag propagation for cross-account access?

  1. A
    Configure the on-premises AD FS server as a SAML Identity Provider (IdP) in each Member account, and update the target IAM roles' trust policies to allow the `sts:AssumeRoleWithSAML` action instead of `sts:AssumeRole`.
  2. B
    Modify the trust relationship policy of the IAM role in the central Identity account to allow the `sts:AssumeRole` action for the target IAM roles in the Member accounts, and specify the department tag in the `sts:TransitiveTagKeys` parameter.
  3. Modify the trust relationship policy of the target IAM roles in the Member accounts to allow the `sts:AssumeRole` and `sts:TagSession` actions for the IAM role principal from the central Identity account.Answer
  4. D
    Attach a Service Control Policy (SCP) to the organization's root that allows the `sts:TagSession` action for all resources, as this will inherit down to the target roles in the Member accounts and grant the required tag propagation permission.

Answer

Modify the trust relationship policy of the target IAM roles in the Member accounts to allow the `sts:AssumeRole` and `sts:TagSession` actions for the IAM role principal from the central Identity account.
The correct answer is to modify the trust relationship policy of the target IAM roles in the Member accounts to allow the `sts:AssumeRole` and `sts:TagSession` actions for the centralized IAM role. When assuming a role and passing session tags, the target role's trust policy must explicitly allow the caller to assume the role and perform the `sts:TagSession` action. Without this action allowed in the trust policy, AWS Security Token Service (STS) will return an Access Denied error when tags are included in the `AssumeRole` call.

Step-by-Step Solution

1
Analyze the IAM configuration and identify that the user is trying to pass session tags across account boundaries during role chaining.
Determine that the IAM role in the central Identity account acts as the calling principal, and the IAM roles in the Member accounts act as the target roles.
Because the user first federated into the central Identity account, downstream target roles in the Member accounts are assumed via role-to-role chaining (sts:AssumeRole) rather than direct SAML federation.
2
Evaluate the AWS Security Token Service (STS) requirements for session tags during role-to-role assumption.
Identify that the calling principal must be authorized to tag the session in the target role's trust policy.
By default, sts:AssumeRole does not allow passing session tags unless the target role's trust policy explicitly authorizes both sts:AssumeRole and sts:TagSession for the assuming principal.
3
Review the proposed solutions to isolate the correct trust policy modification.
Confirm that adding sts:TagSession to the target roles' trust relationship solves the Access Denied issue.
This updates the Member accounts' target roles to allow both role assumption and tag propagation from the central Identity account role.

Key Concept

To pass session tags during cross-account role chaining, the target role's trust policy must explicitly grant both `sts:AssumeRole` and `sts:TagSession` permissions to the calling principal.
Estimated Time:2m 0s
Rate this question