What is SAML (Security Assertion Markup Language)?

What is SAML?

SAML (Security Assertion Markup Language) is an XML-based standard for passing authentication and attribute information about a user from an identity provider (IdP) to a service provider (SP). SAML V2.0 became an OASIS Standard on 15 March 2005. It is widely used for enterprise single sign-on (SSO): the user signs in once at the IdP, and the IdP vouches for them to each application with a signed assertion.

The two roles

• Identity provider (IdP): authenticates the user and issues assertions. This is the system that holds the accounts and enforces rules such as MFA. It is part of the wider topic of identity and access management.
• Service provider (SP): the application the user wants to reach. It consumes the assertion and decides whether to grant access.

How the SAML flow works (SP-initiated)

1. The user opens the SP and chooses to sign in with SSO.
2. The SP redirects the browser to the IdP with an authentication request (AuthnRequest).
3. The IdP authenticates the user, or reuses an existing IdP session.
4. The IdP builds a SAML response containing a signed assertion about the user.
5. The browser delivers the response to the SP's Assertion Consumer Service (ACS) endpoint, normally with an HTTP POST.
6. The SP validates the signature and the conditions, then creates its own local session.

In an IdP-initiated flow the user starts at the IdP, for example from an app dashboard, and the IdP sends an assertion without an AuthnRequest. The OASIS technical overview describes both. The messages travel over bindings such as HTTP Redirect, HTTP POST and HTTP Artifact.

What is inside an assertion

An assertion carries a subject, conditions and statements. The usual pieces are:

• Issuer and signature: who issued it, and proof that nothing was changed.
• Subject: who the assertion is about, often as a NameID such as an email address or an opaque identifier.
• Conditions: a validity window (NotBefore and NotOnOrAfter) and an AudienceRestriction naming the service provider the assertion is meant for.
• Authentication statement: how and when the user authenticated.
• Attribute statement: details such as name, email or group memberships that the SP can use for authorization.

Example

An employee opens the company's project tool. The tool redirects to the corporate IdP, the employee approves a push notification, and the IdP sends back an assertion with their email, the audience set to the project tool and a validity window of a few minutes. The tool checks the signature against the IdP certificate it has on file, confirms the audience is itself, checks the time window, maps the group attribute to a role and logs the employee in.

Common SAML pitfalls

• Clock skew. If the IdP and SP clocks differ by more than the tolerance, the validity window check fails. Keep both on NTP.
• Expired signing certificates. When the IdP certificate expires or is rotated and the SP still holds the old one, every SSO login fails at once. Track expiry dates.
• Audience or ACS mismatch. The entity ID or ACS URL configured on the IdP must match what the SP expects exactly.
• NameID format. If the IdP sends an identifier in a different format than the SP matches on, users are not found or are duplicated.
• Group mapping. A wrong attribute name or value leaves users without their role.
• Weak signature validation or no replay protection. Use a maintained SAML library, verify the signature over the right element, and reject assertions that were already used. The spec also defines a OneTimeUse condition.

SAML vs OAuth 2.0 vs OpenID Connect

• SAML 2.0: XML messages, built for browser SSO between organizations and applications.
• OAuth 2.0: an authorization framework that lets an app access resources on a user's behalf. It is not a login protocol by itself. Tokens such as the bearer token are common in API calls.
• OpenID Connect: an identity layer on top of OAuth 2.0 that uses JSON and JWTs.

SAML, APIs and testing

SAML is a browser-redirect protocol, so it protects the sign-in page rather than API calls. APIs behind an SSO-protected product usually accept a token, and that is what you test: see API security and the guide to OAuth2 load testing. LoadFocus API monitoring can authenticate the APIs it checks with OAuth bearer tokens. LoadFocus itself does not offer SAML or OIDC single sign-on: you sign in to LoadFocus with email and password or with Google.

FAQ: SAML

What does SAML stand for?

Security Assertion Markup Language. An assertion is a statement about a user that the issuing party claims to be true, such as who they are and how they signed in.

What is the difference between SAML and OAuth?

SAML tells an application who the user is. OAuth 2.0 lets an application act on a user's behalf. They solve different problems, and OpenID Connect adds identity on top of OAuth.

Why does SAML use XML?

SAML 2.0 was finalized in 2005, when XML was the standard format for this kind of exchange. Newer protocols such as OpenID Connect use JSON.

Is SAML secure?

The protocol is well specified, but most failures come from implementation: weak signature checks, missing audience or time checks, and no replay protection. Use a maintained library and do not parse the XML yourself.

How do I debug a SAML login that fails?

Capture the SAML response in the browser, decode the base64 payload and read the issuer, audience, validity window and NameID. Then compare them with the SP's configuration and check both clocks. Signature, audience, clock and certificate problems cover most failures.

Does LoadFocus support SAML single sign-on?

No. You sign in to LoadFocus with email and password or with Google. LoadFocus can test and monitor applications and APIs that sit behind SAML, by using the token those APIs accept.