Examkin

Question

Difficulty: HardMulti-Account Identity and Access Management Federation

An enterprise is implementing a multi-account strategy using AWS Organizations. The solutions architect is configuring federated access for a remote team of data engineers who must access Amazon S3 buckets across multiple target member accounts. The authentication flow must use the company's external SAML 2.0-compliant Identity Provider (IdP). The solutions architect has created the SAML identity provider object in each target AWS account. The data engineers must authenticate via the IdP and assume a specific cross-account IAM role named DataEngineerRole in the target accounts. However, during testing, the data engineers receive an "Access Denied" error immediately after authenticating with the IdP and attempting to redirect to the AWS Management Console. Which combination of configuration adjustments must the solutions architect perform to resolve this issue?

  1. A
    Attach a Service Control Policy (SCP) to the target accounts' Organizational Unit (OU) that explicitly allows the sts:AssumeRole action for the external Identity Provider. Remove the local trust policy from the target DataEngineerRole to allow the role to inherit permissions from the parent OU.
  2. Update the trust policy of DataEngineerRole in each target account to allow the sts:AssumeRoleWithSAML action for the federated SAML provider principal. Ensure the SAML assertion sent by the Identity Provider includes the https://aws.amazon.com/SAML/Attributes/Role and https://aws.amazon.com/SAML/Attributes/RoleSessionName attributes.Answer
  3. C
    Update the trust policy of DataEngineerRole to grant the sts:AssumeRole action to the AWS account root principal of the identity provider's host account. Configure the Identity Provider's SAML assertion to pass the user's corporate email address as the RoleSessionName and target the default AWS STS endpoint.
  4. D
    Configure the Identity Provider to authenticate using OpenID Connect (OIDC) protocols. Update the target IAM role trust policy to allow the sts:AssumeRoleWithWebIdentity action, referencing the OIDC provider's client ID, and map the SAML attributes to the OIDC subject claim.

Answer

Update the trust policy of the target IAM role to allow the sts:AssumeRoleWithSAML action for the federated SAML provider principal, and ensure the SAML assertion contains the mandatory Role and RoleSessionName attributes.
The correct solution involves configuring the target IAM role's trust policy to use the sts:AssumeRoleWithSAML action and reference the SAML provider's ARN as the trusted federated principal. Additionally, the external IdP must pass the mandatory AWS SAML attributes (Role and RoleSessionName) in its assertion so that AWS STS can validate the signature and generate temporary credentials.

Step-by-Step Solution

1
Examine the IAM role's trust policy inside the target accounts.
Identify that the trust policy must trust the SAML provider resource and allow the sts:AssumeRoleWithSAML action, which is required for external identity provider assertions.
Standard role assumption (sts:AssumeRole) is meant for internal AWS IAM principals, whereas external SAML IdPs require the specific STS SAML API.
2
Configure the external SAML Identity Provider's claims mapping.
Add the mandatory AWS-specific attributes: Role (mapping to the SAML provider ARN and the target IAM role ARN) and RoleSessionName (mapping to a unique user identifier).
AWS STS requires these attributes in the SAML assertion to successfully evaluate permissions and map the federated session.

Key Concept

SAML 2.0 Federation Trust Policy and Attributes
Estimated Time:2m 30s
Rate this question

Topics

Multi-Account Identity and Access Management Federation

More questions from this topic