SAML 2.0 establishes federation between an identity provider, or IdP, and a service provider, or SP. The IdP authenticates the user, potentially enforcing multifactor authentication and device policies, and issues an XML assertion describing that authentication and selected identity attributes. The SP validates the assertion against its configured trust relationship and establishes access. The user's password normally stays with the IdP rather than being disclosed to the destination service.
Trust is established through configuration, not simply because an assertion contains a recognizable username. Administrators exchange metadata containing entity identifiers, endpoints, and signing certificates. The receiving service must validate the applicable signatures, issuer, audience, recipient, and validity conditions. Request correlation and replay protections are also important where applicable to the selected flow. TLS protects transport, but signing does not conceal assertion contents; encryption is a separate capability whose support depends on the integration.
In a typical browser-based flow, a user opens a cloud application, is redirected to the IdP, authenticates, and returns through the browser with a SAML response submitted to the application's assertion consumer service endpoint. IdP-initiated access can instead begin from an application tile in a corporate portal. The application then creates its own session. SAML assertion validity and application session lifetime are separate controls, so a short-lived assertion does not necessarily mean a short-lived application session.
For direct federation into AWS accounts, an administrator creates an IAM SAML identity provider using the corporate IdP's metadata and configures IAM roles that trust that provider. The trust policy permits sts:AssumeRoleWithSAML and should constrain the intended SAML audience. The IdP supplies AWS-specific attributes identifying permitted role and provider ARN pairs. AWS STS validates the request and issues temporary role credentials; browser federation can use these credentials to establish console access. IAM role policies and other applicable AWS policy controls determine the resulting permissions, not the user's password or the mere presence of a role name in an assertion.
At organizational scale, AWS IAM Identity Center can use an external SAML 2.0 IdP for authentication while administrators manage AWS account access through group assignments and permission sets. For example, a platform engineering group can receive operational access in development accounts and more restricted access in production. Identity Center provisions corresponding IAM roles in assigned accounts. User and group provisioning is a separate concern: SCIM or supported manual processes supply identities and memberships; SAML authentication alone is not directory synchronization.
Federation reduces the need for individual IAM users and long-lived access keys, but it introduces dependence on IdP availability, correct attribute mappings, signing-certificate rollover, and consistent clocks. Automate configuration where practical, test certificate changes before cutover, and maintain tightly controlled emergency access. Disabling a user at the IdP generally prevents future authentication but does not automatically invalidate every existing application session or STS credential. Session limits and service-specific revocation procedures therefore remain necessary.
Common misconceptions include treating SAML as an authorization policy language, a provisioning protocol, or a universal replacement for OAuth and OpenID Connect. Its principal cloud use is enterprise federation, especially browser-based workforce access. Modern command-line access can use Identity Center's supported login flows rather than manually handling SAML assertions. Workloads should normally use workload roles or appropriate workload federation rather than automate human SAML sign-in. Enforce MFA at the IdP and verify how authentication assurance is conveyed; do not assume a federated session automatically carries AWS-native MFA context. Correlate IdP authentication records with cloud audit events and use meaningful session identifiers to preserve accountability.
Amazon Cognito