SAML identity federation is the use of the Security Assertion Markup Language, version 2.0, to let one organization’s identity provider sign users in to another organization’s applications. It remains one of the most widely deployed federation standards in workplaces, universities and government services.
This guide explains how SAML builds that trust in practice: the assertion format, the sign-in flows, the role of metadata and certificates, and the validation mistakes that have caused real vulnerabilities. It is aimed at administrators and developers who maintain SAML connections, and at readers who want to understand what happens behind many corporate sign-in pages.
The XML Standard Still Running Enterprise Sign-In
SAML 2.0 emerged before smartphones and single-page web apps became common, and it shows its age in places. It uses XML, a verbose text format with nested tags, and it was designed mainly for browser-based sign-in to web applications rather than mobile apps or APIs.
Despite that, SAML remains everywhere. Many business applications, research portals and public services support it, and large organizations have years of working configurations. Replacing a stable SAML connection rarely makes sense unless there is a specific need, such as supporting a native mobile app.
Understanding SAML is therefore a practical skill rather than a history lesson. Administrators still configure new SAML connections regularly, developers still maintain applications that consume SAML assertions, and security teams still investigate SAML misconfigurations. Its concepts of signed statements, metadata and trust anchors also carry over directly to newer standards.
Identity Providers and Service Providers in SAML Terms
SAML names two main parties. The identity provider, or IdP, authenticates the user and issues statements about them. The service provider, or SP, is the application the user wants to reach; in general federation language it is called a relying party.
A third party, the user’s browser, carries messages between them. In the most common setup, the identity provider and service provider never talk to each other directly during sign-in. Instead, each message is passed through the browser as a redirect or an automatically submitted web form. This keeps network requirements simple across organizational boundaries.
Because messages travel through the browser, they could in principle be read or altered by the user or by malware on the device. That is why SAML relies so heavily on digital signatures, and sometimes encryption. The service provider must assume that anything arriving through the browser could have been tampered with until it verifies the signature.
Anatomy of a SAML Assertion
The assertion is the signed XML document an identity provider sends to vouch for a user. Understanding its parts makes configuration screens and troubleshooting logs far less mysterious, because most settings map directly to one of these elements.
- Issuer: the entity ID of the identity provider that created the assertion.
- Subject and NameID: the identifier for the user, in a format both sides agreed on.
- Conditions: validity times and an audience restriction naming the intended service provider.
- Authentication statement: when the user signed in and the method used, called the authentication context.
- Attribute statement: user details such as email, display name or group membership.
- Signature: an XML digital signature that protects the assertion, the response or both.
Assertions arrive wrapped inside a response message that also carries a status and a reference to the original request. Service providers should validate the response and the assertion together rather than reading attributes from an unchecked part of the document.
How a SAML Sign-In Travels
A SAML sign-in is a short sequence of messages carried by the browser. The exact path depends on who starts the process and which transport method, called a binding, each step uses. Knowing these variations helps diagnose failures quickly.
Service Provider-Initiated Sign-In
The user opens the application first. The service provider creates an authentication request with a unique ID and sends the browser to the identity provider. After authenticating the user, the identity provider returns a response referencing that request ID. The service provider can confirm that the response answers a request it actually made, which helps block replayed or unsolicited responses.
Identity Provider-Initiated Sign-In
The user starts from a portal at the identity provider and clicks an application tile. The identity provider sends an unsolicited response straight to the service provider. This is convenient for users but removes the request-and-response pairing, so service providers must apply strict time limits and replay checks, and some choose to disable this mode entirely.
Bindings: Redirect and POST
The HTTP-Redirect binding places a compressed message in the web address and suits small requests. The HTTP-POST binding sends larger messages, such as signed responses, through an automatically submitted form. Most deployments use redirect for requests and POST for responses, a pattern worth recognizing when reading browser traces.
Browser developer tools can display these messages, which helps administrators confirm what was actually sent.
Metadata as the Foundation of SAML Trust
SAML trust is configured through metadata, an XML document each party publishes about itself. Identity provider metadata lists its entity ID, sign-in endpoints and signing certificates. Service provider metadata lists its entity ID, the address where it receives responses and any certificates for encrypted assertions.
Exchanging metadata tells each side where to send users and which keys to trust. Many configuration problems come from manual copying of individual values, such as a certificate pasted into the wrong field or an endpoint missing a trailing path. Importing complete metadata files reduces those errors considerably.
Where possible, consume metadata from a stable, encrypted URL and refresh it automatically. Large federations publish signed aggregate metadata covering all members, and participants verify that signature before trusting any entry. Whatever the method, treat metadata as security-critical configuration, controlled by change management rather than edited casually.
Signing, Encryption and Certificate Lifecycles
Every SAML response should be signed by the identity provider, and service providers should require a valid signature before accepting anything. Signatures use the identity provider’s private key, and the service provider verifies them with the public key from metadata, usually packaged as an X.509 certificate.
Encryption is a separate, optional layer. When enabled, the identity provider encrypts the assertion with the service provider’s public key, so only that service can read the attributes. This adds protection for sensitive attributes passing through browsers and logs, at the cost of more complex troubleshooting.
Certificates eventually need replacing, whether because of expiry, policy or suspected compromise. Plan rotations ahead: publish the new certificate in metadata alongside the old one, confirm partners have picked it up, switch signing to the new key, then remove the old certificate. Untracked expiry dates are among the most common causes of sudden SAML outages.
Sessions and Single Logout in SAML
After a successful SAML sign-in, two sessions exist: one at the identity provider and one at the service provider. The assertion may suggest how long the service provider session should last, but each application ultimately decides its own lifetime and idle timeout.
SAML defines a Single Logout profile intended to end sessions at every connected service provider when the user signs out at one place. In practice it is fragile. It depends on every participant supporting it correctly, and a single unresponsive application can leave sessions running without the user noticing.
Because of that, administrators should not rely on Single Logout alone. Keep service provider sessions reasonably short for sensitive applications, require fresh authentication before high-risk actions, and make sure offboarding processes revoke sessions where the application allows it. Users on shared computers should sign out at the identity provider and close the browser completely.
Validation Pitfalls Behind Real SAML Flaws
SAML’s flexibility makes validation tricky. XML documents can contain multiple assertions, nested elements and signatures that cover only part of the document. Vulnerabilities have arisen when service providers verified one signed element but read identity information from a different, unsigned element.
This family of weaknesses is known as XML signature wrapping. Conceptually, the attacker keeps a legitimately signed fragment intact so the signature check passes, while adding separate content that the application mistakenly treats as authoritative. The defense is to process only the exact element the signature covers and reject documents with unexpected structure.
Other pitfalls include accepting responses whose audience names a different service provider, ignoring expiry conditions, trusting certificates embedded in the message instead of those in metadata, and parsing XML with features that allow external entities. Using a mature, actively maintained SAML library and keeping it updated addresses most of these risks.
NameID Formats and Attribute Release
The NameID is the identifier SAML uses for the user. Common formats include an email address, a persistent opaque identifier and a transient identifier that changes on every sign-in. The choice affects both account linking and privacy.
A persistent, opaque identifier unique to each service provider is often the best default. It stays stable for the same user, so accounts link reliably, but it differs between services, so two service providers cannot easily match their records. Email-based identifiers are convenient but change when names change and reveal more than necessary.
Attributes deserve the same restraint. Agree with each service provider on the minimum set it needs, map internal directory fields carefully to the names it expects and document every release. In research and education federations, shared attribute vocabularies help many services interpret the same values consistently, which simplifies onboarding without encouraging oversharing.
SAML Compared With OpenID Connect
Teams starting new integrations often ask whether to use SAML or OpenID Connect, which builds an identity layer on OAuth 2.0. Both can provide secure federated sign-in when implemented correctly. The better choice depends on the application and the partners involved.
- Format: SAML uses XML assertions; OpenID Connect uses compact JSON Web Tokens.
- Clients: SAML targets browser-based web apps; OpenID Connect also suits mobile and single-page apps.
- Ecosystem: SAML is entrenched in enterprise and academic federations; OpenID Connect is widely used for consumer sign-in.
- APIs: OpenID Connect pairs naturally with OAuth access tokens for calling APIs; SAML does not.
Many identity providers support both and can translate between them, so organizations rarely need to choose one exclusively. A common pattern is keeping SAML for established connections while building new applications on OpenID Connect.
Migration is not required simply because a newer standard exists. Move a SAML connection when there is a clear benefit, such as mobile support or API access, and test the replacement thoroughly before switching users over.
Keeping a SAML Federation Healthy Over Time
A SAML connection that works on launch day can fail quietly later. Start with an inventory listing each service provider, its owner, its metadata source, its certificate expiry dates and the attributes it receives. Review that list on a schedule and retire connections nobody uses.
Automate what you can. Refresh metadata from trusted URLs, alert on approaching certificate expiry, and keep SAML libraries patched. Test connections after every change with a dedicated account, and include negative tests, such as an expired or misaddressed response, to confirm the service provider still rejects bad input.
For users, the visible part is simple: sign in through the familiar company page, check the address bar and report anything odd. For administrators, steady maintenance keeps SAML identity federation reliable, so the standard can keep doing its quiet work for as long as the applications depending on it remain in service.