---
{
  "title": "SAML assertion security",
  "summary": "SAML exchanges identity assertions between an identity provider and a relying service.",
  "topic": "foundations",
  "level": "Intermediate",
  "updated": "2026-10-12",
  "published": "2026-10-04",
  "units": [
    7
  ],
  "aliases": [],
  "sources": [
    {
      "title": "OWASP: SAML Security",
      "url": "https://cheatsheetseries.owasp.org/cheatsheets/SAML_Security_Cheat_Sheet.html"
    }
  ],
  "editorialVersion": 2
}
---

## What it means

SAML exchanges identity assertions between an identity provider and a relying service. Security depends on validating signatures and the protocol's intended message, recipient, timing, and request relationships. XML parsing and trust in signing certificates form part of the verification boundary.

## A practical example

An enterprise portal verifies an assertion against its configured identity provider and checks that it is addressed to the portal. It consumes only the intended verified assertion and rejects expired or incorrectly correlated responses before establishing a session.

## What to check

Use maintained SAML libraries, trusted metadata, safe XML handling, and precise audience and recipient checks. Review certificate rollover and test replay and response-correlation behavior.

## A common pitfall

Finding a valid signature somewhere in an XML document does not prove that the application consumed the signed assertion. Verification and business processing must refer to the same intended element.

## Think it through

Why tie a login response to the intended service and request?

**Answer:** A valid assertion for another recipient or flow should not establish a session in this application.

## The assertion belongs to a particular trust relationship

A fictional company uses one identity provider for a payroll portal and a training portal. Both may trust the provider's signing keys, but an assertion intended for training should not automatically establish a payroll session. The receiver must validate the assertion under its own configured protocol relationship, including the intended recipient and applicable timing and request constraints.

XML introduces another important question: which element did the library verify, and which element did the application use? If those are different, finding a valid signature somewhere in the message gives misleading assurance. Supported SAML libraries should perform protocol validation, and application code should consume their validated result rather than reparsing an arbitrary part of the original XML.

Metadata and certificate changes are operational security events. A rollover must preserve trust in the legitimate provider without accepting an uncontrolled signing key. Document who can update federation configuration, how changes are verified, and how the service behaves when a certificate expires or the provider is unavailable.

## Review a login from request to session

For the company example, draw the browser navigation, the authentication request, the provider's response, and the portal's new session. Label where the portal validates the response and where it maps the asserted identity to a local account. Account matching deserves care because a valid assertion can still be mapped to the wrong local identity under a flawed rule.

Test expired, incorrectly addressed, and repeated responses using a controlled federation environment. Avoid manually implementing signature handling from a simplified example. The goal is a clear boundary between untrusted incoming XML and a verified identity result, followed by a separate authorization decision inside the portal.

## Related concepts

- [[identity-federation]]
- [[digital-signatures]]
- [[xml-security]]