What is SAML?

What is SAML?

SAML, the Security Assertion Markup Language, is an open standard for exchanging authentication and authorization data between two parties: an identity provider (IdP) that signs users in, and a service provider (SP) that offers an application. The current version, SAML 2.0, was published by OASIS in 2005 and remains the most common way enterprises give staff single sign-on to web applications, including SaaS products run by other companies.

The core idea is a signed statement. Instead of collecting a password itself, the application accepts a SAML assertion, an XML document signed by the IdP, that says who the user is, when and how they authenticated, and which attributes they hold, such as department or group membership.

How a SAML login works

The most common pattern is a service-provider-initiated login through the browser:

1. The user opens the application, for example a cloud HR system.
2. The application has no session for the user, so it redirects the browser to the IdP with a SAML authentication request.
3. The IdP authenticates the user, with a password and MFA or by reusing a session it already has.
4. The IdP returns a signed assertion through the browser, usually as a form posted to the application's assertion consumer service (ACS) URL.
5. The application verifies the signature with the IdP's public certificate, checks that the assertion is addressed to it and still inside its validity window, and starts its own session.

The password never reaches the application, and the IdP and SP don't need to talk directly during the login, because the browser carries the messages. Trust is set up beforehand by exchanging metadata: entity IDs, endpoint URLs and the IdP's signing certificate. In an IdP-initiated login, the user starts at the IdP's portal and clicks the application's tile instead.

What an assertion contains

A typical assertion includes an Issuer element naming the IdP, an XML digital signature, a Subject with the user's identifier, Conditions with NotBefore and NotOnOrAfter times and an audience restriction naming the one SP allowed to use it, and an AttributeStatement with facts the SP can use for its own authorization decisions. Short validity windows, audience restrictions and one-time-use checks on assertion IDs limit what an attacker can do with a captured assertion.

Securing SAML

• Protect the IdP's signing key. Anyone holding it can forge assertions for any user at every connected application, a technique called Golden SAML. Keep the key in an HSM or a managed key service and alert on changes to federation settings and certificates.
• Validate everything on the SP side: signature, issuer, audience, time window and replay. XML signature wrapping attacks have succeeded against SPs that verified a signature but read the user's identity from an unsigned part of the document.
• Harden the IdP itself with phishing-resistant MFA, because one compromised IdP account opens every application behind it.
• Use TLS on every endpoint so assertions are not exposed in transit.

SAML vs. OAuth vs. OpenID Connect

Kerberos provides SSO inside a Windows domain using tickets, and LDAP is a directory query protocol, not an SSO protocol.

SAML on the CompTIA Security+ exam

SAML falls under objective 4.5 on SY0-801, with federation, single sign-on and the other identity protocols. A scenario where employees reach a partner's or SaaS vendor's web application with their company credentials, where the vendor never sees the passwords, or where the question mentions XML assertions points to SAML. If an app needs permission to act on a user's data through an API, the answer is OAuth instead. If the stem describes a consumer or mobile "sign in with" login built on OAuth, choose OpenID Connect. Know the roles too: the identity provider authenticates the user and issues the assertion, and the service provider, sometimes called the relying party, consumes it.