Examkin

Question

Difficulty: Very hardMulti-Account Identity and Access Management Federation

A financial technology enterprise manages its multi-account environment using AWS Organizations. The security team mandates that all human operators must access AWS member accounts exclusively via SAML 2.0 federation with the corporate Identity Provider (IdP). To prevent backdoors, the architect must ensure that no external AWS accounts outside the organization o-1234567890 can perform cross-account role assumption into the member accounts, while internal cross-account role assumption between member accounts remains fully functional. The corporate SAML provider CorporateIdP has already been created in the member accounts.

Which combination of an IAM role trust policy in the member accounts and a Service Control Policy (SCP) at the Organization root will securely achieve this goal?

  1. Configure the IAM role trust policy in the member accounts with the Action set to "sts:AssumeRoleWithSAML" and the Principal set to the CorporateIdP SAML provider ARN. Apply an SCP at the Organization root that denies the Action "sts:AssumeRole" for all resources with a condition of StringNotEqualsIfExists for "aws:PrincipalOrgID" set to "o-1234567890".Answer
  2. B
    Configure the IAM role trust policy in the member accounts with the Action set to "sts:AssumeRole" and the Principal set to the CorporateIdP SAML provider ARN. Apply an SCP at the Organization root that denies the Action "sts:AssumeRole" for all resources with a condition of StringNotEqualsIfExists for "aws:PrincipalOrgID" set to "o-1234567890".
  3. C
    Configure the IAM role trust policy in the member accounts with the Action set to "sts:AssumeRoleWithSAML" and the Principal set to the CorporateIdP SAML provider ARN. Apply an SCP at the Organization root that denies the Action "sts:AssumeRole" for all resources with a condition of StringNotEquals for "aws:PrincipalOrgID" set to "o-1234567890".
  4. D
    Configure the IAM role trust policy in the member accounts with the Action set to "sts:AssumeRoleWithSAML" and the Principal set to the CorporateIdP SAML provider ARN. Apply an SCP at the Organization root that denies the Actions "sts:AssumeRole" and "sts:AssumeRoleWithSAML" for all resources with a condition of StringNotEqualsIfExists for "aws:PrincipalOrgID" set to "o-1234567890".

Answer

Configure the IAM role trust policy in the member accounts to use the "sts:AssumeRoleWithSAML" action for the SAML provider principal. To restrict cross-account access, apply a root-level SCP that denies the "sts:AssumeRole" action using the StringNotEqualsIfExists condition operator for the "aws:PrincipalOrgID" context key.
The correct option outlines the appropriate configuration where the IAM role trust policy allows the "sts:AssumeRoleWithSAML" action for the federated SAML provider. Furthermore, the Service Control Policy at the Organization root blocks external "sts:AssumeRole" requests by asserting that any caller whose "aws:PrincipalOrgID" is not equal to the company's Organization ID is denied. By using the "StringNotEqualsIfExists" operator, the policy ensures that external standalone accounts, which completely lack the "aws:PrincipalOrgID" key in their requests, are also evaluated as a match for the condition and successfully denied access.

Step-by-Step Solution

1
Analyze SAML 2.0 trust relationship requirement
Identify that the trust policy of IAM roles designed for direct SAML federation must specify the principal as the SAML provider ARN and use the "sts:AssumeRoleWithSAML" action.
SAML federation authentication bypasses the standard AWS principal framework and uses a dedicated security token service API.
2
Evaluate the behavior of aws:PrincipalOrgID in Service Control Policies
Determine that aws:PrincipalOrgID identifies the Organization to which the calling principal belongs. If the caller is external or not part of an organization (such as a standalone account), this key will not be present in the request context.
This is critical for preventing cross-account access from unauthorized external accounts.
3
Select the correct conditional evaluation operator
Choose the StringNotEqualsIfExists operator rather than StringNotEquals.
If StringNotEquals is used, a request lacking the aws:PrincipalOrgID key (like one from a standalone external account) will evaluate to false and bypass the Deny. StringNotEqualsIfExists evaluates to true when the key is missing, securing the endpoint.
4
Validate the SCP action scope against SAML federation
Ensure the SCP only restricts the "sts:AssumeRole" action and does not include "sts:AssumeRoleWithSAML".
Including sts:AssumeRoleWithSAML would block federation because the incoming SAML request does not contain the aws:PrincipalOrgID key at the time of evaluation.

Key Concept

Using Multi-Account IAM Federation with SAML 2.0 alongside Service Control Policies requires aligning the sts:AssumeRoleWithSAML API with condition key evaluations. In SCPs, using conditional operators like StringNotEqualsIfExists prevents authentication bypasses by ensuring missing context keys (such as those from standalone external accounts) trigger the Deny rule.
Rate this question

Topics

Multi-Account Identity and Access Management Federation

More questions from this topic