Security Assertion Markup Language (SAML)

The Identity Provider (IdP) is the authoritative entity that authenticates a user and issues security assertions about their identity. It is the source of truth in a SAML federation.

• Primary Role: Authenticates users and generates SAML assertions containing authentication statements and user attributes.
• Trust Anchor: Service Providers (SPs) trust the IdP to correctly identify users.
• Common Examples: Enterprise directories like Microsoft Active Directory Federation Services (AD FS), Okta, Ping Identity, and Auth0.

The Service Provider (SP) is the application or service that the user wants to access. It relies on the Identity Provider for authentication decisions.

• Primary Role: Consumes SAML assertions from a trusted IdP to grant or deny access to its resources.
• SP-Initiated Flow: The user attempts to access the SP first, which redirects them to the IdP.
• IdP-Initiated Flow: The user starts at the IdP portal and selects the SP to access.

A SAML Assertion is an XML document issued by the IdP that contains statements about a user. It is the core credential passed to the Service Provider.

• Authentication Statement: Confirms the user was authenticated at a specific time using a particular method (e.g., password, multi-factor).
• Attribute Statement: Contains specific attributes about the user (e.g., email, group memberships, employee ID).
• Authorization Decision Statement: (Less common) Makes a yes/no decision about a user's right to access a specific resource.

The SAML Protocol defines the request-response framework for obtaining assertions. Bindings specify how these protocol messages are transported over standard protocols.

• SAML Protocol: Defines operations like <AuthnRequest> (SP asks for authentication) and <Response> (IdP returns assertion).
• HTTP Redirect Binding: Encodes messages into URL parameters for browser redirects.
• HTTP POST Binding: Encodes messages into an HTML form for automatic submission.
• SOAP Binding: Used for enterprise SOAP/XML web services.

SAML Metadata is an XML configuration file that enables automated trust establishment between an IdP and an SP by exchanging technical details.

• Contents: Includes entity IDs, X.509 certificates for signing/encryption, supported bindings, and endpoint URLs (e.g., Single Sign-On Service, Single Logout Service).
• Trust Fabric: SPs and IdPs exchange metadata files to pre-configure trust, eliminating manual key and endpoint configuration.
• Dynamic Consumption: Systems can fetch metadata from a trusted URL to automatically update configuration.

SAML relies on XML Signature (XMLSig) and optionally XML Encryption to ensure message integrity, authenticity, and confidentiality.

• Assertion Signing: The IdP cryptographically signs the SAML assertion, allowing the SP to verify it was issued by a trusted IdP and was not tampered with.
• Request Signing: An SP can sign <AuthnRequest> messages to prevent forgery.
• Message Encryption: Sensitive data, like name identifiers, can be encrypted within the assertion.
• Replay Attack Prevention: Relying on assertion IDs, issue instants, and optional recipient restrictions.

An Identity Provider (IdP) is the authoritative system that manages user identities and credentials, performing authentication and issuing security assertions. In a SAML flow, the IdP is the service that validates a user's credentials and generates the SAML assertion (containing authentication and attribute statements) for the relying Service Provider (SP). Examples include Okta, Microsoft Entra ID (Azure AD), and Ping Identity.

• Core Function: Authenticates users and creates trusted security tokens.
• SAML Role: Generates and signs SAML assertions.
• Trust Relationship: Must be pre-configured with Service Providers in a federation.

Single Sign-On (SSO) is an authentication scheme that allows a user to log in once and gain access to multiple, independent software systems without re-entering credentials. SAML is a primary protocol used to implement web-based SSO across security domains. The SAML assertion acts as a portable, verifiable proof of authentication that the Service Provider accepts, enabling seamless access.

• User Benefit: Eliminates multiple password prompts.
• SAML's Role: Provides the standardized, secure token exchange for federated SSO.
• Enterprise Scope: Enables SSO across cloud and on-premises applications.

A JSON Web Token (JWT) is a compact, URL-safe token format defined in RFC 7519, used to securely transmit claims between parties. Unlike SAML's XML-based structure, JWTs are JSON-based, making them smaller and easier to handle in HTTP headers (commonly the Authorization: Bearer header). While SAML is often used for web browser SSO, JWTs are the standard token for OAuth 2.0 and OpenID Connect, favored in API and mobile contexts.

• Format: Compact JSON structure (Header.Payload.Signature).
• Common Use: API access tokens and OIDC identity tokens.
• Contrast with SAML: Lighter weight, designed for APIs; SAML is more feature-rich for enterprise federation.

Federated Identity is a system of trust where multiple administrative domains agree to recognize user identities and authentication conducted by a trusted partner. SAML is a cornerstone standard for implementing federation, defining how authentication and authorization data is exchanged across these domains. It establishes a circle of trust between Identity Providers and Service Providers, allowing users to use credentials from their home domain to access services in another.

• Core Concept: Decouples identity management from service provision.
• SAML's Role: Provides the technical standard for secure cross-domain assertion passing.
• Business Benefit: Enables partnerships and cloud service integration without managing user passwords.

A Service Provider (SP) or Relying Party (RP) is the application or service that a user is trying to access. In the SAML flow, the SP relies on the Identity Provider (IdP) to authenticate the user. The SP consumes the SAML assertion, validates its signature against the trusted IdP, and uses the contained attributes (like user ID, email, group membership) to make access control decisions and create a local session.

• SAML Role: Consumes and validates SAML assertions.
• Key Actions: Redirects users to the IdP, processes POST or Redirect bindings, and establishes application sessions.
• Trust: Must be configured with the IdP's metadata (including its public signing certificate).