Examkin

Question

Difficulty: Very hardMulti-Account Identity and Access Management Federation

A multinational enterprise manages a multi-account AWS environment under AWS Organizations. The enterprise integrates its on-premises SAML 2.0 Identity Provider (IdP) directly with target AWS member accounts to federate corporate directories. The security team wants to implement a global Attribute-Based Access Control (ABAC) strategy using the corporate attributes `CostCenter` and `Project`. The IdP is configured to send these attributes as SAML assertions mapped to AWS principal tags (`PrincipalTag:CostCenter` and `PrincipalTag:Project`).

The security team creates a standard IAM role named `ProjectContributorRole` in each member account. The local permission policies are configured to allow actions only when the resource's `CostCenter` tag matches the user's `CostCenter` principal tag. However, during initial testing, corporate users receive an error and are unable to log in to AWS when attempting to federate.

Which combination of configurations will resolve the login failures and securely enforce the cross-account ABAC boundaries across all organization accounts?

  1. Ensure the trust policy of `ProjectContributorRole` in each member account permits both the `sts:AssumeRoleWithSAML` and `sts:TagSession` actions for the SAML Identity Provider ARN. Implement an Organization-wide Service Control Policy (SCP) at the root level that explicitly denies any action if the request does not carry the `aws:PrincipalTag/CostCenter` tag or if it does not match the target resource's `aws:ResourceTag/CostCenter` tag.Answer
  2. B
    Ensure the trust policy of `ProjectContributorRole` in each member account permits only the `sts:AssumeRoleWithSAML` action for the SAML Identity Provider ARN. Modify the SAML assertion in the IdP to map the `CostCenter` and `Project` attributes to standard SAML Session Attributes rather than principal tags, thereby bypassing the requirement for `sts:TagSession` authorization.
  3. C
    Ensure the trust policy of `ProjectContributorRole` in each member account permits both the `sts:AssumeRoleWithSAML` and `sts:TagSession` actions. Create an Organization-wide Service Control Policy (SCP) that explicitly grants read and write access to resources when `aws:PrincipalTag/CostCenter` matches `aws:ResourceTag/CostCenter`, allowing you to delete the local permission policies from the role in each member account to simplify management.
  4. D
    Ensure the trust policy of `ProjectContributorRole` in each member account permits the `sts:AssumeRole` action for the SAML Identity Provider principal. Configure an IAM Policy at the Organization level that maps the SAML assertion attributes to transient IAM policy variables, and attach it to the root of the organization.

Answer

Ensure the trust policy of the IAM role permits both the sts:AssumeRoleWithSAML and sts:TagSession actions for the SAML Identity Provider, and use an Organization-wide Service Control Policy (SCP) to deny operations when the CostCenter principal tag does not match the resource tag.
The correct option correctly identifies that to pass session tags (principal tags) via SAML federation, the role's trust policy must authorize both the sts:AssumeRoleWithSAML and sts:TagSession actions. Furthermore, it correctly utilizes a Service Control Policy (SCP) to deny operations when the principal tag does not match the resource tag, serving as a secure guardrail while local IAM policies in target accounts grant the actual permissions.

Step-by-Step Solution

1
Analyze the federation failure when using principal tags.
Identify that passing principal tags (ABAC attributes) via SAML requires authorization to tag the session.
By default, sts:AssumeRoleWithSAML only allows role assumption. Passing tags requires the sts:TagSession action in the role's trust policy.
2
Determine the correct trust policy modification.
Add both sts:AssumeRoleWithSAML and sts:TagSession to the Action element of the IAM role's trust policy in each member account.
This allows the external Identity Provider to pass the corporate attributes as session tags during the federation process.
3
Evaluate the mechanism for enforcing organizational boundaries.
Use a Service Control Policy (SCP) at the Organization root with a Deny effect to prevent operations when tags do not match.
SCPs cannot grant permissions, but they act as guardrails. Combining local IAM allow policies with an organizational deny guardrail ensures secure enforcement across all accounts.

Key Concept

SAML 2.0 federation with Session Tags requires the trust policy to authorize the sts:TagSession action in addition to sts:AssumeRoleWithSAML.
Estimated Time:3m 0s
Rate this question

Topics

Multi-Account Identity and Access Management Federation

More questions from this topic