Examkin

Question

Difficulty: MediumMulti-Account Identity and Access Management Federation

A solutions architect is designing a multi-account federation solution for a company using AWS Organizations. The company wants to allow its corporate directory users to log in to the AWS Management Console of various member accounts using their existing credentials via an external SAML 2.0 Identity Provider (IdP). The IdP is already configured, and the SAML provider object has been created in each member account. Which of the following configuration steps must be performed to establish this federated access? (Select TWO.)

  1. Configure the external IdP to send SAML assertions containing attributes for https://aws.amazon.com/SAML/Attributes/Role and https://aws.amazon.com/SAML/Attributes/RoleSessionName.Answer
  2. In each target AWS member account, create an IAM role with a trust policy that specifies the SAML provider ARN as the principal and allows the sts:AssumeRoleWithSAML action.Answer
  3. C
    Create a Service Control Policy (SCP) at the root Organizational Unit (OU) level that allows the sts:AssumeRoleWithSAML action for the IAM roles in all member accounts.
  4. D
    In each target AWS member account, create an IAM role with a trust policy that specifies the IdP's metadata URL as the principal and allows the sts:AssumeRole action.
  5. E
    In each target AWS member account, attach an IAM identity-based policy to the federated IAM role that grants permissions to execute the sts:AssumeRoleWithSAML action.

Answer

To configure multi-account SAML federation, the external IdP must be configured to pass the Role and RoleSessionName attributes in the SAML assertion, and each target AWS member account must contain an IAM role configured with a trust policy that permits the sts:AssumeRoleWithSAML action from the IAM SAML provider principal.
Establishing federated access via SAML 2.0 requires configuration at both the Identity Provider (IdP) and AWS levels. The IdP must send assertions containing the required attributes (Role and RoleSessionName) so AWS can authorize the session. On the AWS side, each member account must have an IAM role that explicitly trusts the SAML provider ARN and allows the sts:AssumeRoleWithSAML action.

Step-by-Step Solution

1
Configure assertion mappings in the external Identity Provider (IdP).
The IdP sends SAML assertions containing the mandatory AWS-specific attributes: Role (mapping user to Role ARN and SAML Provider ARN) and RoleSessionName (identifying the user session).
AWS STS requires these specific SAML attributes in the assertion to determine which role to assume and how to name the federated console session.
2
Create or configure the IAM roles in the member accounts.
Roles are created with trust policies where the Principal points to the local SAML provider's ARN and the Action allows 'sts:AssumeRoleWithSAML'.
This establishes the necessary trust relationship, enabling users authenticated by the external IdP to exchange their SAML assertion for temporary security credentials in the target member account.

Key Concept

SAML 2.0 federation in a multi-account environment requires both metadata-based trust on the AWS side (role trust policy using sts:AssumeRoleWithSAML) and claim-based configuration on the IdP side (Role and RoleSessionName attributes).
Rate this question

Topics

Multi-Account Identity and Access Management Federation

More questions from this topic