Examkin

Question

Difficulty: HardMulti-Account Identity and Access Management Federation

An organization is transitioning its multi-account AWS environment to use an external SAML 2.0-compliant Identity Provider (IdP) for user authentication. The solutions architect has created the SAML identity providers in the target member accounts. However, when users attempt to authenticate, the federation process fails, and they are unable to assume the designated IAM roles. To diagnose this, the architect reviews the configurations of the member accounts and the parent AWS Organization. Which combination of actions must the solutions architect take to resolve the authentication failures and establish federated access to the target accounts? (Select TWO.)

  1. Modify the trust policy of the IAM roles in the target accounts to allow the `sts:AssumeRoleWithSAML` action, specifying the SAML identity provider as the principal and enforcing the `SAML:aud` condition.Answer
  2. Ensure that no Service Control Policies (SCPs) applied at the Organization or OU levels explicitly deny the `sts:AssumeRoleWithSAML` action for the target accounts.Answer
  3. C
    Modify the trust policy of the IAM roles in the target accounts to allow the `sts:AssumeRole` action, specifying the SAML identity provider as the principal and checking the `SAML:iss` condition.
  4. D
    Attach a Service Control Policy (SCP) at the root level that explicitly grants the `sts:AssumeRoleWithSAML` action to all federated users, bypassing target account trust policies.
  5. E
    Configure a resource-based policy on the SAML identity providers in the target accounts to delegate the `sts:AssumeRoleWithSAML` action to the external identity provider.

Answer

Configure the trust policy of the target IAM roles to allow `sts:AssumeRoleWithSAML` with the SAML provider as the principal and the correct `SAML:aud` condition, and verify that no parent SCPs explicitly deny the `sts:AssumeRoleWithSAML` action.
For federated users authenticating via SAML 2.0 to access AWS, target IAM roles must trust the SAML provider object as a principal and authorize the `sts:AssumeRoleWithSAML` action. Furthermore, because Service Control Policies (SCPs) act as boundaries across the Organization, any explicit deny on STS operations will block authentication globally within that OU or account, making it necessary to verify that SCPs do not block this action.

Step-by-Step Solution

1
Examine the IAM role trust policy in the target accounts.
Ensure the principal is set to the Federated SAML provider ARN and the action is set to `sts:AssumeRoleWithSAML`.
SAML assertions cannot be parsed or accepted via the standard `sts:AssumeRole` call; the correct API operation must be explicitly trusted.
2
Configure SAML-specific conditions in the trust policy.
Add conditions verifying `SAML:aud` matches the sign-in URL.
This prevents spoofing and ensures only authorized assertions from the trusted IdP are accepted.
3
Inspect parent AWS Organizations Service Control Policies (SCPs).
Ensure that SCPs do not contain explicit deny statements covering the `sts:AssumeRoleWithSAML` action.
Explicit denies in SCPs override any local permissions granted in member accounts, including trust policies.

Key Concept

SAML 2.0 Federation requires both target role trust configurations (`sts:AssumeRoleWithSAML` action) and compliance with Organization-level Service Control Policies (SCPs) which act as maximum permission boundaries.
Rate this question

Topics

Multi-Account Identity and Access Management Federation

More questions from this topic