SAML
Security Assertion Markup LanguageSAML is enterprise single sign-on, done in XML. An application redirects the browser to the company’s identity provider, which authenticates the user and posts back a digitally signed assertion — the browser carries the proof, and no password ever reaches the application.
SAML lets one identity provider vouch for a user to many applications — the assertion is signed XML, carried by the browser.
How it works
The two servers may never talk to each other: the browser is the courier. Trust rests entirely on the IdP’s signing certificate being known to the SP in advance — exchanged once, in metadata.
What SAML does, step by step
With no session, the SP builds an AuthnRequest and redirects the browser to the identity provider.
The IdP checks the user however the organisation requires — and reuses its own session if there is one.
It builds an XML assertion naming the subject and attributes, signs it, and posts it back through the browser.
The SP checks the signature, audience, conditions and timestamps, then creates a local session.
In cybersecurity
SAML’s security is entirely a matter of validating the XML signature correctly — and XML signature validation has been a rich source of critical bugs for twenty years.
XSW attacks move the signed element so a parser validates one part and reads another.
Comment injection has repeatedly let attackers change the asserted username past a valid signature.
An assertion minted for another SP must be rejected, however genuine its signature.
NotBefore, NotOnOrAfter and single-use IDs are what stop an old assertion being replayed.
IdP signing certificates expire and take every integration down at once — track and rotate them.
An unsolicited assertion has no request to correlate with; prefer SP-initiated flows.