SAML

SAML is an OASIS standard: version 1.0 was approved in November 2002, and SAML 2.0 in March 2005, merging SAML 1.1, the Liberty Alliance ID-FF 1.2 and Shibboleth work. The 2.0 specification set is split into Core (assertions and protocols), Bindings, Profiles, Metadata and conformance documents. An assertion is an XML document issued by an IdP containing a Subject with a NameID (persistent, transient, emailAddress or unspecified format) and SubjectConfirmation data, Conditions (NotBefore, NotOnOrAfter, AudienceRestriction), and statements: an AuthnStatement with AuthnInstant, SessionIndex and an AuthnContextClassRef describing how the user authenticated, and usually an AttributeStatement carrying attributes such as email, groups or employee number.

The Web Browser SSO profile is what most deployments use. In the SP-initiated variant the service provider creates an AuthnRequest and sends it through the HTTP-Redirect binding (DEFLATE-compressed, base64-encoded, URL-encoded, with any signature carried in query parameters), preserving application state in RelayState. The IdP authenticates the user and returns a Response through the HTTP-POST binding, as an auto-submitting HTML form aimed at the SP's Assertion Consumer Service URL. The Artifact binding instead passes a short reference that the SP resolves over a back channel with SOAP. IdP-initiated SSO sends an unsolicited Response with no InResponseTo to check, which weakens protection against replay and login injection.

Security rests on XML Signature. The Response, the Assertion or both carry an enveloped signature whose Reference points to an ID attribute, computed over exclusive canonicalisation. That indirection enables XML Signature Wrapping: Somorovsky and colleagues ("On Breaking SAML", USENIX Security 2012) found 11 of 14 frameworks they tested vulnerable to injecting an unsigned assertion next to the signed one. In 2018 Duo Labs showed that XML comments inside a NameID could make several libraries read a truncated identity. A correct SP processes only the element whose signature it verified, checks Destination, Recipient, Audience, validity window with small clock skew and InResponseTo, keeps a replay cache of assertion IDs and disables DTD processing to prevent XXE. EncryptedAssertion with AES-CBC has been broken by chosen-ciphertext attacks, so AES-GCM is preferred. Theft of the IdP's signing key enables Golden SAML forgery.

Operationally, trust is configured by exchanging metadata with entity IDs, endpoints and certificates, and certificate rollovers are a common cause of outages. Single Logout exists but is unreliable across many SPs. SAML suits browser-based enterprise SaaS and is weak for native mobile apps and APIs, where OpenID Connect and OAuth fit better. In Denmark, the OIOSAML profiles (currently 3.0.3 alongside 2.1.0) govern integration with NemLog-in, and the research federation WAYF also builds on SAML.