Blog · Guides

What is SAML, and why enterprises still run on it

SAML 2.0 explained: assertions, the identity provider and service provider, bindings and metadata, how a browser SSO login actually works, and where SAML stops.

Casdoor Team · November 1, 2026 · 3 min read

This guide is written by the team that builds Casdoor and describes the standards as published (listed under Sources), with notes on how Casdoor implements them as of November 1, 2026. Spotted a mistake? Tell us.

SAML (Security Assertion Markup Language) is an XML-based standard for exchanging authentication and authorization data between an identity provider and an application. Version 2.0, published by OASIS in 2005, is the version everyone means when they say "SAML".

It is the protocol that made enterprise single sign-on work, and it is still the one procurement asks for. This article explains what is in it and how a login flows.

The two parties

  • Identity provider (IdP) — holds the accounts and authenticates the user. Examples: Okta, Microsoft Entra ID, Google Workspace, Keycloak, Casdoor.
  • Service provider (SP) — the application the user wants. Examples: Salesforce, Slack, Grafana, an internal admin console.

The SP trusts the IdP because the two have exchanged metadata: endpoints, entity IDs and signing certificates.

Assertions: what SAML actually sends

A SAML response carries one or more assertions — XML statements signed by the IdP:

  • Authentication assertion — "this user authenticated at this time, by this method."
  • Attribute assertion — "this user has these attributes": email, name, groups, roles, department.
  • Authorization decision assertion — "this user may access this resource." Rarely used in practice; applications usually make their own authorization decisions from attributes.

An assertion contains:

Element Meaning
Issuer Which IdP issued it
Subject / NameID Who it is about
Conditions Validity window (NotBefore, NotOnOrAfter) and AudienceRestriction
AuthnStatement How and when the user authenticated, plus a SessionIndex
AttributeStatement The user's attributes
Signature XML digital signature over the assertion or the response

How a browser SSO login works

The standard profile is Web Browser SSO:

  1. The user opens the SP.
  2. The SP redirects the browser to the IdP with a SAML AuthnRequest.
  3. The IdP authenticates the user, or reuses an existing session.
  4. The IdP returns a SAML Response containing the assertion.
  5. The SP validates the signature, the audience, the recipient and the time window, then starts its own session.

Bindings are how the messages travel: HTTP-Redirect (the message is deflated into a query parameter) and HTTP-POST (an HTML form auto-submits the message). Most integrations use Redirect for the request and POST for the response.

There is also IdP-initiated SSO, where the IdP sends an unsolicited response from a portal. See SP-initiated vs IdP-initiated SSO.

Metadata and certificates

SAML runs on a trust relationship expressed in metadata:

  • The IdP publishes a metadata XML with its entity ID, SSO endpoint, SingleLogoutService and signing certificate.
  • The SP publishes its own metadata with its entity ID and Assertion Consumer Service (ACS) URL.
  • Each side imports the other's metadata.

Certificates expire, which is why "SSO stopped working" is so often a certificate rotation that only one side performed. Plan for overlapping certificates during rotation.

What SAML is good at

  • Enterprise SSO across SaaS and internal applications.
  • Rich attribute exchange for provisioning roles and groups at login.
  • Broad support in enterprise software; the checklist item is usually "SAML 2.0".

Where SAML stops

  • It is browser-centric. SAML is designed around redirects and forms, not API calls or mobile apps.
  • It does not provision accounts by itself. Creating, updating and deactivating users is SCIM's job. See SCIM vs SAML.
  • Single logout is unreliable in practice, because it depends on every SP implementing it and on browser cookie behavior. See SAML single logout.
  • It is verbose. XML signatures have a long history of parsing pitfalls, which is one reason newer systems prefer OIDC.

SAML vs OIDC

Both do browser SSO. The short version:

  • SAML: XML, enterprise-first, attribute-rich, the thing big customers ask for.
  • OIDC: JSON, API-friendly, built on OAuth, the default for new applications.

Most identity providers support both, and most companies use both — SAML for the applications that require it, OIDC for everything new. See SAML vs OIDC and OAuth vs SAML.

Setting it up

If you are the service provider, you need an ACS endpoint and assertion validation. If you are the identity provider, you need metadata, signing keys and attribute mapping. Casdoor does the second: it is a SAML 2.0 identity provider with a metadata URL per application, configurable attributes and single logout. See set up Casdoor as a SAML IdP.

Casdoor is open source and self-hostable, with a hosted option from $9 per month and no per-user fees.