What is Security Assertion Markup Language (SAML)?
Security Assertion Markup Language 2.0 is an OASIS XML framework for exchanging authentication, attribute, and authorization decision assertions between a SAML authority and a relying party. Browser SSO commonly uses an identity provider, a service provider, a signed assertion, and defined bindings and profiles. A SAML assertion does not contain the user's reusable credential. Its validity depends on correct signature, issuer, audience, recipient, time, request-correlation, and binding checks.
Why it matters
SAML lets an organization use one identity authority with many service providers. The service provider can accept a verified federation assertion instead of collecting the user's primary credential.
How it works
- The service provider starts an authentication request, or the user starts a supported identity-provider flow.
- The identity provider authenticates the user and returns a SAML response and assertion through a defined browser binding.
- The service provider validates the response, assertion, signature, conditions, and request context before it creates a local session.
Example
An employee opens a SaaS application, authenticates at the company identity provider, and returns with a signed SAML assertion that the service provider validates.
Pomerium boundary
Pomerium currently integrates with identity providers through OAuth 2.0 and OpenID Connect, not through a direct SAML identity-provider connection. An organization that uses SAML must use an identity service or broker that provides an OIDC interface to Pomerium.
Limits and non-claims
- A signed SAML assertion is not encrypted unless the deployment also uses assertion encryption, and browser flows still require protected TLS channels.
- Missing audience, recipient, time, signature, or request-correlation checks can let an invalid assertion succeed.
- SAML SSO authenticates a federation session but does not replace local application authorization, session, and logout controls.
Evaluation checklist
- Does the service provider validate signature, issuer, audience, recipient, time, and request correlation?
- How do assertion subjects and attributes map to one local account and current permission set?
- Can XML wrapping, replay, weak signing rules, unsolicited responses, or stale attributes bypass checks?
