Examkin

Question

Difficulty: HardMulti-Account Identity and Access Management Federation

An enterprise is implementing a multi-account strategy using AWS Organizations. Users must authenticate using an external SAML 2.0 Identity Provider (IdP) to access resources in several member accounts. A solutions architect creates the IAM SAML identity provider resource in each target member account and configures the corresponding federated IAM roles. During testing, users are successfully authenticated by the corporate IdP and redirected to AWS, but they receive an Access Denied error when attempting to assume the target IAM role in the member account. Which configuration error is the most likely cause of this issue?

  1. A
    The permissions policy attached to the IAM role in the member account lacks an explicit statement allowing the sts:AssumeRoleWithSAML action on the SAML provider resource.
  2. B
    The Service Control Policy (SCP) attached to the organizational unit containing the member accounts does not explicitly grant the sts:AssumeRoleWithSAML permission to the federated users.
  3. The trust policy of the IAM role in the member account specifies the SAML provider as the federated principal but designates the sts:AssumeRole action instead of sts:AssumeRoleWithSAML.Answer
  4. D
    The trust policy of the IAM role in the member account designates the target member account's root principal as the federated entity instead of specifying the SAML provider ARN.

Answer

The trust policy of the IAM role in the member account specifies the SAML provider as the federated principal but designates the sts:AssumeRole action instead of sts:AssumeRoleWithSAML.
The trust policy of the IAM role must permit the sts:AssumeRoleWithSAML action and specify the SAML provider as the federated principal. If the action is configured as sts:AssumeRole, STS will reject the SAML assertion because sts:AssumeRole is designed for standard IAM security credentials, not SAML assertions.

Step-by-Step Solution

1
Examine the authentication flow stage where the error occurs.
The user is successfully authenticated by the IdP and redirected, meaning the SAML assertion is generated correctly, but AWS rejects the role assumption request.
This isolates the failure to the trust verification process on the AWS side when processing the incoming SAML assertion.
2
Analyze the IAM role configuration required for SAML federation.
SAML federation requires a specific API call, sts:AssumeRoleWithSAML, to exchange the assertion for temporary credentials.
The trust policy must permit this specific STS action rather than the standard sts:AssumeRole action used for IAM-based cross-account access.
3
Identify the incorrect trust policy configuration causing the Access Denied error.
A trust policy that specifies the federated SAML principal but maps it to sts:AssumeRole is invalid for SAML exchange, leading to failure.
STS requires the sts:AssumeRoleWithSAML action in the trust policy to match the assertion consumption endpoint protocol.

Key Concept

SAML 2.0 Federation Trust Relationships and STS Actions
Estimated Time:2m 30s
Rate this question

Topics

Multi-Account Identity and Access Management Federation

More questions from this topic