Question

Difficulty: HardMulti-Account Identity and Access Management Federation

A company manages a multi-account AWS environment using AWS Organizations. The company needs to grant read-only access to a third-party compliance team. The compliance team authenticates using an external corporate SAML 2.0 Identity Provider (IdP). The compliance team must access resources across several target accounts in the 'Compliance' Organizational Unit (OU) without managing local AWS IAM user credentials in each account.

An administrator needs to configure the trust relationship so that the external compliance team can federate directly into the target accounts. Service Control Policies (SCPs) are applied to the 'Compliance' OU to restrict administrative access.

Which configuration strategy correctly establishes this federated access in a secure manner?

  1. In each target AWS account, create a SAML Identity Provider (IdP) referencing the compliance team's IdP metadata. Create an IAM role in each target account with a trust policy that allows the `sts:AssumeRoleWithSAML` action for the local SAML provider ARN, and attach the required read-only permission policies to these roles.Answer
  2. B
    Create a Service Control Policy (SCP) at the 'Compliance' OU level that explicitly allows the external SAML IdP's entity ID to access all member accounts. Attach the read-only permission policies directly to this SCP, allowing compliance users to bypass local IAM role creation in the target accounts.
  3. C
    In each target AWS account, create a SAML Identity Provider (IdP) referencing the compliance team's IdP metadata. Create an IAM role in each target account with a trust policy that specifies the SAML provider as the principal but allows the `sts:AssumeRole` action, and attach the required read-only permission policies to these roles.
  4. D
    Create the SAML Identity Provider (IdP) only in the management account of the organization. Create a centralized IAM role in the management account using `sts:AssumeRoleWithSAML`. Rely on the Organization's root SCP to allow this role to dynamically assume local administrator roles in target accounts in the 'Compliance' OU.

Answer

In each target AWS account, create a SAML Identity Provider (IdP) referencing the compliance team's IdP metadata. Create an IAM role in each target account with a trust policy that allows the `sts:AssumeRoleWithSAML` action for the local SAML provider ARN, and attach the required read-only permission policies to these roles.
The correct option correctly outlines that target accounts must have a local SAML Identity Provider configured and a corresponding local IAM role. The role's trust policy must explicitly allow the `sts:AssumeRoleWithSAML` action to process SAML assertions from the external provider.

Step-by-Step Solution

1
Register the SAML Identity Provider (IdP) in the target accounts.
Each target account is aware of the external SAML IdP and can validate assertion signatures.
This establishes trust between the target AWS accounts and the external identity provider.
2
Create an IAM role with a trust policy allowing `sts:AssumeRoleWithSAML` for the SAML provider.
An IAM role exists that is assumable by users authenticated by the external SAML IdP.
Federated users need an AWS role to assume in order to receive temporary security credentials.
3
Attach the required read-only IAM permissions policy to the created IAM role in each target account.
The federated session receives the appropriate read-only authorization.
This ensures the compliance team has the necessary access to inspect resources inside the target accounts.

Key Concept

To establish cross-account access via SAML 2.0 federation, each target AWS account must have a configured SAML Identity Provider and local IAM roles with trust policies specifying `sts:AssumeRoleWithSAML` as the action.
Rate this question