Examkin

Question

Difficulty: HardMulti-Account Identity and Access Management Federation

An enterprise is migrating its multi-account identity strategy to AWS IAM Identity Center to centralize user access management. The security team wants to ensure that all human user access to member accounts is routed exclusively through IAM Identity Center. They must prevent administrators in member accounts from establishing or using direct SAML 2.0 or OpenID Connect (OIDC) federation bypasses directly to their individual accounts. The solution must not impact normal cross-account IAM role assumption used by internal applications and AWS services. Which approach should the solutions architect implement to meet these requirements with the least administrative overhead?

  1. Apply a Service Control Policy (SCP) at the Organization root that denies the sts:AssumeRoleWithSAML and sts:AssumeRoleWithWebIdentity actions.Answer
  2. B
    Apply a Service Control Policy (SCP) to all member account OUs that explicitly allows sts:AssumeRole for the sso.amazonaws.com principal, which implicitly denies all other STS actions across the organization.
  3. C
    Configure the trust policies of all IAM roles in the member accounts to use the sts:AssumeRole action and restrict the principal to the central IAM Identity Center SAML provider ARN.
  4. D
    Apply a Service Control Policy (SCP) at the Organization root that denies the sts:AssumeRole action for all non-administrative sessions, forcing all federation to use sts:AssumeRoleWithSAML managed by IAM Identity Center.

Answer

Apply a Service Control Policy (SCP) at the Organization root that denies the sts:AssumeRoleWithSAML and sts:AssumeRoleWithWebIdentity actions.
The correct option is correct because direct SAML 2.0 and OIDC federation depend on the 'sts:AssumeRoleWithSAML' and 'sts:AssumeRoleWithWebIdentity' actions respectively. Denying these actions in a Service Control Policy (SCP) at the Organization root prevents any direct federation bypasses from being established or used in member accounts. Because AWS IAM Identity Center uses service-controlled roles assumed via 'sso.amazonaws.com' using the standard 'sts:AssumeRole' action, it remains fully functional, as does normal cross-account role assumption.

Step-by-Step Solution

1
Analyze how direct federation and AWS IAM Identity Center authenticate to member accounts.
Direct SAML federation uses sts:AssumeRoleWithSAML, direct OIDC uses sts:AssumeRoleWithWebIdentity, and AWS IAM Identity Center uses sts:AssumeRole via the sso.amazonaws.com service principal.
Understanding the specific STS actions used by each access method is necessary to target the correct actions for restriction without disrupting legitimate traffic.
2
Determine the effect of Service Control Policies (SCPs) on these actions.
SCPs act as guardrails. An explicit deny of sts:AssumeRoleWithSAML and sts:AssumeRoleWithWebIdentity at the Organization root will prevent anyone in member accounts from using direct federation.
Using an explicit deny in an SCP is the most effective and centralized way to enforce this security guardrail across all member accounts with minimal administrative overhead.
3
Verify that normal operations are not impacted by the SCP restrictions.
Normal cross-account role assumption and IAM Identity Center federation rely on the sts:AssumeRole action, which remains allowed under the proposed SCP.
Ensures that application integration and the desired central identity solution function correctly while achieving the security objective.

Key Concept

Multi-Account Identity Federation Security Guardrails
Rate this question

Topics

Multi-Account Identity and Access Management Federation

More questions from this topic