Examkin

Question

Difficulty: MediumMulti-Account Identity and Access Management Federation

A company is implementing a multi-account strategy using AWS Organizations. They want to set up federated access for their enterprise users to log into the AWS Management Console of various member accounts using their on-premises SAML 2.0 Identity Provider (IdP). The Solutions Architect has created an IAM SAML identity provider in each member account and defined an IAM role for the federated users. However, during testing, users receive an error indicating that they are not authorized to assume the role.

Which configuration issue is the most likely cause of this error?

  1. A
    The Service Control Policy (SCP) attached to the Organizational Unit fails to explicitly grant the sts:AssumeRoleWithSAML permission to the federated principal.
  2. B
    The trust policy of the IAM role defines the member account's root user as the principal rather than referencing the ARN of the IAM SAML identity provider.
  3. The trust policy of the IAM role in the member accounts specifies the sts:AssumeRole action instead of the sts:AssumeRoleWithSAML action.Answer
  4. D
    The trust policy of the IAM role lacks a condition block restricting the SAML:iss key to the specific Amazon Resource Name of the management account.

Answer

The trust policy of the IAM role in the member accounts specifies the sts:AssumeRole action instead of the sts:AssumeRoleWithSAML action.
To enable SAML 2.0 federation, the IAM role's trust policy must trust the SAML provider as the principal and allow the sts:AssumeRoleWithSAML action. If the trust policy incorrectly specifies sts:AssumeRole (which is used for standard cross-account access or IAM user role assumption), the AWS Security Token Service (STS) will reject the federation request because the correct API endpoint (AssumeRoleWithSAML) is not authorized by the trust policy.

Step-by-Step Solution

1
Analyze the authentication flow for SAML 2.0 federation to AWS.
Identify that the identity provider (IdP) sends a SAML assertion to the AWS STS service, which calls the AssumeRoleWithSAML API operation.
This establishes that the role's trust policy must specifically authorize the AssumeRoleWithSAML action.
2
Examine the trust policy requirements of the target IAM role.
The principal must be set to the ARN of the IAM SAML identity provider, and the action must be set to sts:AssumeRoleWithSAML.
Standard role assumption (sts:AssumeRole) is restricted to AWS principals and does not support SAML federated assertions.
3
Evaluate the cause of the authorization failure during federation.
Specifying sts:AssumeRole instead of sts:AssumeRoleWithSAML in the trust policy prevents the trust relationship from matching the incoming AssumeRoleWithSAML request.
Correcting the action in the trust policy allows the identity provider to exchange the SAML assertion for temporary credentials.

Key Concept

SAML 2.0 federation trust policies require the sts:AssumeRoleWithSAML action to allow external identity provider assertions to be exchanged for temporary security credentials.
Estimated Time:2m 0s
Rate this question

Topics

Multi-Account Identity and Access Management Federation

More questions from this topic