Examkin

Question

Difficulty: MediumMulti-Account Identity and Access Management Federation

A company is implementing a multi-account federation solution using an external SAML 2.0 Identity Provider (IdP). The solutions architect configures a SAML provider in the primary AWS account and wants to allow federated users to assume a specific IAM role across multiple target member accounts in the AWS Organization. During testing, users receive an access denied error when attempting to authenticate and assume the role in the member accounts. Which of the following configurations is required to successfully establish this federated access to the target member accounts?

  1. A
    Create the SAML Identity Provider (IdP) only in the primary management account. In each target member account, create an IAM role with a trust policy that allows the sts:AssumeRoleWithSAML action and references the ARN of the SAML IdP in the primary management account as the principal.
  2. Create a SAML Identity Provider (IdP) in each target member account. In each member account, create an IAM role with a trust policy that allows the sts:AssumeRoleWithSAML action and specifies the local SAML IdP as the principal.Answer
  3. C
    Create a SAML Identity Provider (IdP) in each target member account. In each member account, create an IAM role with a trust policy that allows the sts:AssumeRole action and specifies the local SAML IdP as the principal.
  4. D
    Attach a Service Control Policy (SCP) to the organization's root that allows the sts:AssumeRoleWithSAML action for the external identity provider, thereby granting federated access to all member accounts without needing to define local IAM roles or trust relationships in each target account.

Answer

Create a SAML Identity Provider (IdP) in each target member account. In each member account, create an IAM role with a trust policy that allows the sts:AssumeRoleWithSAML action and specifies the local SAML IdP as the principal.
For direct SAML federation to work in a multi-account environment, a SAML Identity Provider (IdP) must be created in each target member account. The IAM role in each member account must have a trust policy that allows the sts:AssumeRoleWithSAML action and references the local SAML IdP as the principal. This allows the SAML assertion to be directly validated and exchanged for temporary security credentials in that specific account.

Step-by-Step Solution

1
Analyze the validation requirements for SAML assertions in AWS.
Establish that an AWS account must possess a local representation of the Identity Provider (IdP) to validate incoming SAML assertions.
IAM roles cannot directly trust a SAML IdP located in a different AWS account; therefore, the SAML IdP resource must exist locally in each target account.
2
Determine the correct Security Token Service (STS) action for SAML assertion exchange.
Identify that the sts:AssumeRoleWithSAML action is mandatory in the trust policy.
Standard cross-account role assumption uses sts:AssumeRole, but exchanging external SAML tokens for AWS temporary credentials requires the sts:AssumeRoleWithSAML API action.
3
Verify that Service Control Policies (SCPs) do not block the configuration.
Ensure that SCPs allow the necessary sts:AssumeRoleWithSAML action, while recognizing that the actual permissions must still be granted by local IAM roles.
SCPs restrict maximum permissions but do not grant them, meaning the local IAM roles and federation configurations are still necessary.

Key Concept

Multi-Account Identity and Access Management Federation
Rate this question

Topics

Multi-Account Identity and Access Management Federation

More questions from this topic