Examkin

Question

Difficulty: HardMulti-Account Identity and Access Management Federation

A financial services company is implementing a centralized identity strategy for its AWS multi-account environment managed by AWS Organizations. The company uses an on-premises SAML 2.0 compliant Identity Provider (IdP) for user authentication. The security team wants to minimize administrative overhead by avoiding the creation of SAML Identity Provider resources in every member account. Instead, they want to establish trust in a single, centralized 'Identity' account, allowing authenticated corporate users to assume specific operations roles in various member accounts.

Which configuration steps must be performed to establish this identity flow while adhering to the security team's constraints? (Select TWO.)

  1. In the centralized Identity account, create an IAM SAML provider and a transition IAM role with a trust policy that permits the sts:AssumeRoleWithSAML action for the SAML provider principal.Answer
  2. In each target member account, create the destination IAM roles with trust policies that permit the sts:AssumeRole action, specifying the centralized transition role's ARN as the principal.Answer
  3. C
    In each target member account, create destination IAM roles with trust policies that permit the sts:AssumeRoleWithSAML action, specifying the centralized Identity account's SAML provider ARN as the principal without creating local SAML providers in those accounts.
  4. D
    Attach a Service Control Policy (SCP) at the Organization root that uses a Principal wildcard to grant sts:AssumeRoleWithSAML access, thereby bypassing the need for individual IAM role trust policies in member accounts.
  5. E
    Configure the corporate IdP to issue SAML assertions containing the destination IAM roles' ARNs directly, and configure the target member accounts' default trust policies to implicitly accept assertions signed by the centralized account.

Answer

Establish the SAML 2.0 federation trust in the centralized Identity account using the sts:AssumeRoleWithSAML action on a transition IAM role, and then use role chaining by configuring target member account roles to trust the transition role ARN via the sts:AssumeRole action.
Establishing a centralized identity account avoids the overhead of creating SAML provider resources in every member account. Corporate users federate into a transition role in the centralized Identity account via the sts:AssumeRoleWithSAML action. From this transition role, users then chain to target roles in member accounts using the standard sts:AssumeRole action, which requires trust policies in the target accounts pointing to the transition role's ARN.

Step-by-Step Solution

1
Configure SAML 2.0 federation in the central Identity account by creating an IAM SAML provider and an associated transition IAM role.
Corporate users can authenticate against the central IdP and assume the transition role in the centralized Identity account via the sts:AssumeRoleWithSAML action.
Establishing the SAML trust locally in a single account minimizes administration by avoiding provider creation in every member account.
2
Configure trust policies on destination roles in target member accounts to trust the centralized transition role's ARN.
The target roles allow the central transition role as a trusted principal using the sts:AssumeRole action.
This enables role chaining, allowing users who have assumed the transition role to assume the target role in the member accounts.
3
Implement the role-chaining flow in the corporate portal or CLI, where the user first authenticates to get credentials for the transition role, then calls sts:AssumeRole to access the target account.
Users gain authorized access to target member accounts without direct SAML provider configurations in those target accounts.
This completes the end-to-end authentication and authorization flow across the multi-account architecture.

Key Concept

Multi-Account Identity Federation with SAML 2.0 and Role Chaining
Estimated Time:3m 0s
Rate this question

Topics

Multi-Account Identity and Access Management Federation

More questions from this topic