Examkin

Question

Difficulty: Very hardMulti-Account Identity and Access Management Federation

A medical technology organization operates a multi-account structure managed via AWS Organizations. The security team is implementing single sign-on for application developers using PingFederate as an external SAML 2.0 Identity Provider (IdP). To maintain a secure architecture, the organization mandates that all user authentication occurs via a centralized Identity account. Once authenticated, developers must assume target roles in various application-specific member accounts to perform their duties. The developers also need to pass dynamic session tags (such as 'CostCenter' and 'Environment') from the SAML assertion to the target member account roles to support Attribute-Based Access Control (ABAC).

The administrator configures the SAML assertion to include the attributes for transitive session tags. During testing, developers can successfully authenticate and assume the initial federated role in the Identity account. However, when they attempt to switch roles to the application member accounts, the API call to assume the target role is denied.

Which configuration change will resolve this issue and allow developers to access the member accounts with their session tags?

  1. A
    Configure the PingFederate SAML provider in each member account. Update the trust policy of the target role in each member account to permit 'sts:AssumeRoleWithSAML' directly from the provider, bypassing the Identity account.
  2. B
    Attach a Service Control Policy (SCP) at the root of the AWS Organization that allows the 'sts:AssumeRole' and 'sts:TagSession' actions for the federated role, and remove the local trust policies from the target roles in the member accounts.
  3. Update the trust policy of the target roles in the member accounts to trust the Identity account's federated role and explicitly permit both the 'sts:AssumeRole' and 'sts:TagSession' actions. Ensure the federated role's identity-based policy in the Identity account allows these same actions on the target roles.Answer
  4. D
    Configure the target role trust policies in the member accounts to allow the 'sts:AssumeRole' action from the Identity account's federated role. Update the federated role's identity-based policy in the Identity account to permit 'sts:AssumeRole' on the target roles without granting 'sts:TagSession'.

Answer

Update the trust policy of the target roles in the member accounts to trust the Identity account's federated role and explicitly permit both the 'sts:AssumeRole' and 'sts:TagSession' actions. Ensure the federated role's identity-based policy in the Identity account allows these same actions on the target roles.
For cross-account role assumption using AWS Security Token Service (STS) where session tags are passed (transitive or dynamic), both the calling identity and the target role must have the appropriate permissions. The identity-based policy of the calling role in the Identity account must grant the 'sts:AssumeRole' and 'sts:TagSession' permissions. Additionally, the trust policy of the target role in the member account must explicitly trust the calling role and allow both 'sts:AssumeRole' and 'sts:TagSession' actions. Without 'sts:TagSession' allowed in the target role's trust policy, the request is denied because the principal is attempting to apply tags during the session initialization.

Step-by-Step Solution

1
Analyze the access flow and requirements.
Identify that the flow is centralized federation (SAML to Identity account) followed by cross-account role chaining (Identity account role to Member account role) while passing session tags for ABAC.
This establishes that the failure occurs during the second leg of the access flow: the 'sts:AssumeRole' cross-account call.
2
Determine the permissions required for passing session tags during role assumption.
Identify that both the caller and the target role trust policy must support the 'sts:TagSession' action in addition to 'sts:AssumeRole'.
AWS Security Token Service (STS) requires explicit authorization for session tagging to prevent unauthorized privilege escalation or tag tampering during cross-account access.
3
Evaluate the proposed options against the security requirements.
Select the option that configures the target role's trust policy and the federated role's identity-based policy to allow both 'sts:AssumeRole' and 'sts:TagSession'.
This satisfies the permissions requirement while adhering to the centralized federation architecture.

Key Concept

Cross-account role chaining with session tags (sts:TagSession)
Estimated Time:3m 0s
Rate this question

Topics

Multi-Account Identity and Access Management Federation

More questions from this topic