A solutions architect has implemented a SAML 2 0 federated identity solution with their company's on-premises identity provider (IdP) to authenticate…

The scenario describes a user-specific failure in a SAML 2.0 federation setup. Since the architect's access works, the fundamental connection between the on-premises Identity Provider (IdP) and AWS is functional. The issue likely lies in the configuration specific to the test users. The three critical checkpoints for this scenario are:
1. IdP Assertion Mapping (F): The on-premises IdP must be configured to generate a SAML assertion that includes claims mapping the authenticated test users (or their groups) to a specific IAM role. A failure here means AWS never receives the instruction to grant the test users a role.
2. IAM Role Trust Policy (B): The destination IAM role must have a trust policy that explicitly designates the SAML provider as a trusted principal. This allows the role to be assumed by users authenticated by that IdP.
3. STS API Call (D): The federated web portal must correctly use the SAML assertion from the IdP to call the AssumeRoleWithSAML API, passing the correct role ARN and provider ARN. This is the action that exchanges the assertion for temporary AWS credentials.

A. SAML federation is for authenticating external identities, not for granting permissions to existing IAM users. This concept is misapplied.
C. The specific group name "AWSFederatedUsers" is arbitrary. The core issue is the correct mapping of any group to a role, not membership in a specifically named group.
E. The authentication flow does not require AWS to connect to the on-premises IdP. The user's browser mediates the communication between the IdP and AWS endpoints.

1. AWS Identity and Access Management User Guide. "Configuring a role for SAML 2.0 federation." This guide specifies that the role's trust policy must identify the SAML provider as the principal. This supports option B. The example policy shows: "Principal": { "Federated": "arn:aws:iam::ACCOUNT-ID-WITHOUT-HYPHENS:saml-provider/PROVIDER-NAME" }.

2. AWS Identity and Access Management User Guide. "Configuring SAML assertions for the authentication response." This section details the required claims within the SAML assertion, such as https://aws.amazon.com/SAML/Attributes/Role, which maps the user to an IAM role and SAML provider. This directly supports option F.

3. AWS Security Token Service API Reference. "AssumeRoleWithSAML." The documentation for this API action confirms that it is the mechanism used to obtain temporary security credentials using a SAML assertion. It requires the RoleArn, PrincipalArn (the SAML provider ARN), and the SAMLAssertion as parameters, which supports the check described in option D.

4. AWS Security Blog. "How to Implement Federated API and CLI Access Using SAML 2.0 and AD FS." The blog post outlines the end-to-end flow, stating, "The application then calls the AWS STS AssumeRoleWithSAML API and passes the SAML assertion, the ARN of the SAML provider, and the ARN of the IAM role to assume." This confirms the process described in options B, D, and F.