Examkin

Question

Difficulty: MediumMulti-Account Identity and Access Management Federation

A company is implementing a federated access solution using an on-premises SAML 2.0 compliant Identity Provider (IdP) for their AWS Organizations environment. While testing the integration, a user successfully authenticates against the identity provider and selects a role named FederatedAdminRole in a target member account. However, the redirection to the AWS Management Console fails, and the user receives the following error message: 'Access denied. Action: sts:AssumeRoleWithSAML is not authorized.' The Solutions Architect verifies that the SAML identity provider is correctly created in the IAM console of the target account, and the user's SAML assertion contains the correct role and provider ARNs. Which configuration issue is the most likely cause of this error?

  1. The trust policy of the target IAM role specifies the principal as the SAML provider but designates the action as sts:AssumeRole rather than sts:AssumeRoleWithSAML.Answer
  2. B
    The Service Control Policy (SCP) attached to the target member account's Organizational Unit does not contain an explicit allow statement for the sts:AssumeRoleWithSAML action.
  3. C
    The identity-based permission policy attached to the target IAM role does not explicitly grant permissions for the sts:AssumeRoleWithSAML API action.
  4. D
    The SAML assertion generated by the Identity Provider lacks the mandatory https://aws.amazon.com/SAML/Attributes/RoleSessionName attribute, causing the request to fail authorization.

Answer

The trust policy of the target IAM role specifies the principal as the SAML provider but designates the action as sts:AssumeRole rather than sts:AssumeRoleWithSAML.
The correct answer is the option stating that the trust policy of the target IAM role specifies the action as sts:AssumeRole instead of sts:AssumeRoleWithSAML. For SAML federation, the trust policy (trust relationship) of the role must list the SAML Identity Provider as the principal and explicitly allow the 'sts:AssumeRoleWithSAML' action. If 'sts:AssumeRole' is specified instead, AWS will deny the assertion request because it does not match the correct API operation required for federating external users.

Step-by-Step Solution

1
Analyze the error message.
The message indicates that the security token service action sts:AssumeRoleWithSAML is not authorized for the incoming identity request.
This points to a misconfiguration in the trust relationship (trust policy) of the target IAM role being assumed.
2
Check the trust policy structure of the target IAM role.
Confirm that the action specified in the trust policy's Statement block is sts:AssumeRoleWithSAML.
The correct API action for SAML-based federation is sts:AssumeRoleWithSAML. Using sts:AssumeRole is incorrect because it is used for standard IAM role assumption (e.g., cross-account or by services) and will result in an authorization failure for SAML federation.
3
Differentiate trust policies from identity-based policies and SCPs.
Verify that no identity-based permission policies are required to allow the trust setup, and confirm that Service Control Policies (SCPs) do not explicitly deny the action.
SAML federation trust is established solely in the role's trust policy; identity-based policies do not control trust, and SCPs only filter permissions rather than granting them.

Key Concept

SAML 2.0 Federation IAM Role Trust Policy Configuration
Estimated Time:2m 0s
Rate this question

Topics

Multi-Account Identity and Access Management Federation

More questions from this topic