Question

Difficulty: HardMulti-Account Identity and Access Management Federation

A financial services firm is implementing single sign-on (SSO) to a multi-account AWS environment under AWS Organizations. The firm integrates its external SAML 2.0 Identity Provider (IdP) directly with the member accounts. A security engineer creates an IAM SAML identity provider in each member account and maps it to the external IdP metadata. The engineer then configures an IAM role in each member account for federated users. However, when users attempt to federate, the identity provider returns a failure during the SAML assertion phase.

A review of the configuration shows that:
1. An SCP is attached to the Organizational Unit (OU) containing these member accounts with a statement that allows `sts:AssumeRoleWithSAML` for all resources.
2. The trust policy of the IAM role in the member account is configured as follows:

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::123456789012:saml-provider/CorporateIdP"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"SAML:aud": "https://signin.aws.amazon.com/saml"
}
}
}
]
}

Which action must the security engineer take to resolve the federation failure?

  1. A
    Modify the SCP attached to the OU to explicitly grant `sts:AssumeRole` to the SAML provider ARN.
  2. B
    Modify the Action in the IAM role trust policy to `sts:AssumeRoleWithWebIdentity` and update the audience condition.
  3. Change the Action in the IAM role trust policy in each member account to `sts:AssumeRoleWithSAML`.Answer
  4. D
    Update the Principal in the IAM role trust policy to reference the AWS Organizations management account root ARN.

Answer

Change the Action in the IAM role trust policy in each member account to `sts:AssumeRoleWithSAML`.
The correct action is to change the Action in the IAM role trust policy to `sts:AssumeRoleWithSAML`. For SAML 2.0 identity federation, AWS STS requires that the role's trust policy explicitly lists the `sts:AssumeRoleWithSAML` action. Since the current policy uses `sts:AssumeRole`, the request is denied because standard role assumption does not accept SAML assertions.

Step-by-Step Solution

1
Analyze the IAM role trust policy in the member account.
Identify that the trust policy incorrectly specifies `sts:AssumeRole` in the Action block.
SAML federation requires the Security Token Service (STS) action to match the authentication protocol, which is `sts:AssumeRoleWithSAML`.
2
Evaluate the role of the Service Control Policy (SCP).
Confirm that the SCP already allows `sts:AssumeRoleWithSAML` but note that it does not grant permissions directly.
SCPs act as a filter and cannot bypass the requirement for a correct trust policy within the IAM role.
3
Update the IAM role trust policy.
Change the Action to `sts:AssumeRoleWithSAML`.
This allows the STS service to process the incoming SAML assertion and successfully issue temporary credentials.

Key Concept

SAML 2.0 identity federation requires the use of the `sts:AssumeRoleWithSAML` API action in both the client request and the IAM role's trust policy, while SCPs restrict but do not grant these permissions.
Estimated Time:2m 0s
Rate this question