SAML explained: enterprise and university single sign-on

SAML 2.0 is a standard that lets an organisation’s login system, called the identity provider, tell other services, called service providers, who a user is and which attributes they have. The user signs in once at the identity provider, and every connected service accepts the signed result. It is the technology behind many company and university single sign-on portals.

What SAML is for

Large organisations run dozens of applications: HR, mail, expense tools, learning platforms. Giving each one its own accounts would multiply passwords and make leaving employees hard to remove. With SAML, accounts live in one directory, and each application trusts a signed assertion from it. This is the idea explained more generally in single sign-on and identity federation.

SAML 2.0 was approved by the standards body OASIS in March 2005 (the specifications are published at docs.oasis-open.org). It predates smartphones and OAuth, which is why it uses XML and browser-based messages.

The roles

Role	What it does	Example
User (principal)	Wants to open an application	An employee
Identity provider (IdP)	Authenticates the user, issues assertions	Company directory login, university login
Service provider (SP)	The application that relies on the assertion	Expense tool, library database
Metadata	XML files that publish endpoints and certificates	Exchanged once when two parties connect

How a SAML login works

The most common variant is service-provider-initiated login through the browser.

1. The user opens the application (the service provider).
2. The application creates an authentication request and redirects the browser to the identity provider.
3. The identity provider authenticates the user, for example with a password plus second factor or a passkey.
4. The identity provider builds a signed XML assertion with the user’s identifier, the time of login and chosen attributes.
5. The browser posts the assertion to the service provider’s endpoint (the Assertion Consumer Service).
6. The service provider verifies the signature with the certificate from the identity provider’s metadata, checks the conditions, and logs the user in.

A heavily shortened assertion looks like this:

<saml:Assertion>
  <saml:Issuer>https://idp.example.edu</saml:Issuer>
  <saml:Subject><saml:NameID>user-4711</saml:NameID></saml:Subject>
  <saml:Conditions NotOnOrAfter="2026-10-06T09:19:00Z">
    <saml:AudienceRestriction>
      <saml:Audience>https://library.example</saml:Audience>
    </saml:AudienceRestriction>
  </saml:Conditions>
  <ds:Signature>...</ds:Signature>
</saml:Assertion>

Login can also start at the identity provider (a portal with tiles). That variant is more exposed to attacks and is often discouraged.

Everyday examples

• An employee opens a payroll or expense app from the company portal without a second login.
• A student reaches a publisher’s journal database with the university account, through an education federation that links many universities. National federations and the international eduGAIN service use SAML heavily.
• A government service lets staff of different agencies sign in with their own agency account.
• Cross-border eID in the EU: the eIDAS interoperability framework uses a SAML-based message profile between national nodes (see using your eID in another EU country).

Security aspects

• Validate the signature properly. Historically, many attacks (“XML signature wrapping”) fooled applications into trusting unsigned parts of a message. Use well-maintained libraries and test with the signature checks switched on.
• Check the conditions. Audience, validity window (NotOnOrAfter), recipient and InResponseTo must match, otherwise assertions can be replayed or sent to the wrong service.
• Prefer service-provider-initiated login and require signed or encrypted assertions where attributes are sensitive.
• Protect the identity provider. One compromised IdP opens every connected application, so use phishing-resistant sign-in and monitor it closely.
• Release minimal attributes. Send only what the application needs.
• Rotate certificates before they expire; metadata mismatch is the most common cause of sudden login failures.

SAML or OpenID Connect: how to choose

Pick SAML when you integrate with enterprise software or an education federation that already offers it, or when a customer’s IT department expects it. Pick OpenID Connect for new web apps, mobile apps and anything that also needs API access, because the libraries are simpler and the JSON tokens are easier to debug. If you build a product sold to organisations, supporting both is common. In every case the same basics apply: strong sign-in at the identity provider, exact validation of what arrives, and the smallest set of attributes.

Two practical habits help both administrators and users. Administrators should monitor certificate expiry dates and test a login after every metadata change. Users should enter their credentials only on the identity provider’s own page, and treat a login prompt that arrives by email link with suspicion.

Status and versions

SAML 2.0 has been stable since 2005, with later profiles and errata. Identity vendors ship SAML support as a baseline feature. For new web and mobile projects, OpenID Connect is the more usual choice; how it relates to its OAuth foundation is explained in OpenID vs OAuth.

How it relates to the other standards

SAML and OpenID Connect solve the same problem with different tools. SAML has richer enterprise features and a long track record. OIDC is lighter and works well with APIs. Many identity platforms speak both and translate between them. SAML is not a credential format for wallets and plays no direct part in OpenID4VP or OpenID4VCI.

Role in the EUDI Wallet

SAML is mainly relevant to the transition. Today, cross-border login under the eIDAS regulation runs through national eID nodes that exchange SAML messages. The EU Digital Identity Wallet is designed around a different model: the user holds credentials and presents them directly using OpenID4VP. Services will probably support both for some time, so SAML knowledge stays useful for anyone integrating public-sector systems.