An enterprise already runs its own SAML 2.0-compliant identity provider for internal employee logins and wants employees to obtain temporary AWS credentials to access resources in a single AWS account directly, by federating their existing identity provider straight into IAM, without adopting AWS's own managed workforce SSO service and without creating any IAM user for any employee. Which approach fits?
- Configure IAM Identity Center as the enterprise's identity provider, since it is the only supported way to federate any external identity provider with AWS
- Create an IAM user for every employee and have the identity provider place a long-lived AWS access key into each user's browser session
- Use AWS Directory Service to fully replace the enterprise's existing identity provider, since IAM cannot trust an external SAML provider directly
- Create a SAML identity provider entity in IAM that trusts the enterprise's identity provider, then create an IAM role whose trust policy allows that SAML provider to call AssumeRoleWithSAML, so authenticated employees receive temporary credentials scoped to that role without any IAM user ever being created
Why D? And why not the others?
Correct answer: D. Create a SAML identity provider entity in IAM that trusts the enterprise's identity provider, then create an IAM role whose trust policy allows that SAML provider to call AssumeRoleWithSAML, so authenticated employees receive temporary credentials scoped to that role without any IAM user ever being created
IAM natively supports registering an external SAML 2.0 identity provider as a SAML provider resource and creating an IAM role whose trust policy allows that provider's authenticated principals to call AssumeRoleWithSAML, which returns temporary security credentials scoped to the role, entirely independent of IAM Identity Center and without ever creating an IAM user for an employee. The option requiring IAM Identity Center is wrong because direct SAML federation into IAM roles predates Identity Center and works without it; Identity Center is one option among several for federation, not the only one. The option of creating an IAM user per employee and injecting a long-lived access key is wrong because it reintroduces exactly the long-lived, hard-to-rotate credentials that federation is meant to eliminate. The option of replacing the identity provider with AWS Directory Service is wrong because that service is a managed directory for different scenarios, such as domain-joined workloads, and IAM can already trust an external SAML provider directly without needing any such replacement.
Source: AWS IAM documentation: Creating IAM SAML identity providers and AWS STS AssumeRoleWithSAML (https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_saml.html)