SAML, and why it is still around

Origins and the OASIS standard

SAML 1.0 was published by OASIS in 2002, and SAML 2.0, the version everyone operates today, was ratified in 2005. That places it several years before OAuth and most of a decade before OpenID Connect. It was designed when XML was the common language of inter-system communication, so expressing identity assertions as signed XML documents was conventional at the time. That vocabulary is the source of SAML's present reputation for being awkward: every assertion is an XML document, every signature is an XML Digital Signature with its namespace and canonicalisation complexity, and every binding base64-encodes XML inside HTTP. The mechanism works at scale; it does not feel modern.

The roles

SAML uses its own names for the federation roles of Chapter 9, and a defender needs both vocabularies because the same architecture diagram uses both. The identity provider (IdP) is the same role: it authenticates the user and issues assertions. The service provider (SP) is what OIDC calls the relying party: the application that defers authentication and accepts assertions. Workday, ServiceNow and the student information system are SPs, and dozens per organisation are common. The subject is the user, in SAML's vocabulary. The trust shape is the same as in OIDC: the SP holds the IdP's metadata and validates assertions against the IdP's signing key.

The SAML assertion

The artefact that does the work is the SAML assertion, an XML document containing statements about the subject. The three statement types are the authentication statement, the attribute statement, and the rarely used authorisation decision statement. The authentication statement says when and by what method the subject authenticated, carrying the AuthnContext that describes the assurance level, so an SP that cares about MFA can require an AuthnContext asserting MFA was used. The attribute statement carries claims: name, email, group memberships, employee number, department. Australian universities commonly pass affiliation (staff, student, alumni), department and a stable identifier.

The assertion is signed by the IdP using XML Digital Signature, conceptually similar to a JWT signature but operating over XML elements. The SP validates it against the IdP's public key from the federation metadata. Two elements deserve mention: the Conditions element carries NotBefore and NotOnOrAfter timestamps defining the validity window, and an SP that does not check them is open to replay; the audience inside Conditions names the intended SP, and an SP that does not validate audience is open to a token meant for a different SP.

Bindings and the Web Browser SSO profile

SAML defines several bindings for how messages move. The three seen in practice are HTTP-Redirect, which encodes a message in URL parameters and is used for small outbound requests; HTTP-POST, which delivers a message in an auto-submitting HTML form and is used for inbound assertions too large for a URL; and HTTP-Artifact, an indirect binding where the SP fetches the assertion from the IdP over a back channel. HTTP-POST is dominant for the response.

The profile a defender meets day to day is Web Browser SSO. The user reaches an SP with no session. The SP generates an AuthnRequest and redirects the browser to the IdP, or, if the user started at the IdP portal, the request is implicit. The IdP authenticates the user; as in OIDC, the protocol treats this step as a black box, and Conditional Access applies here when Entra is the IdP because the policy engine evaluates every sign-in regardless of protocol. The IdP creates a signed response containing the assertion and returns it to the browser by HTTP-POST to the SP's Assertion Consumer Service URL. The SP validates the signatures, checks the validity window, validates the audience, parses the statements, and creates a session. The IdP-initiated variant has the user start at the portal and click a tile; the IdP posts the assertion with no inbound request, so the SP relies entirely on the assertion's audience and validity window for protection.

Metadata and NameID

Federation metadata in SAML is an XML document describing one end of a federation to the other: the entity ID, the bindings and endpoints, the certificates, and the supported NameID formats. Each side loads the other's at setup. SAML metadata is long-lived in a way OIDC metadata is not; certificates inside it can be valid for years, and rotation requires a coordinated change at both ends. Federations break, often, when a certificate quietly expires and no one was monitoring expiry dates. That is the single most common SAML outage.

The NameID identifies the subject inside the assertion. A persistent NameID is a stable opaque identifier reused across sessions, the basis of cross-session correlation. A transient NameID is a one-time identifier, so each session is uncorrelated from the SP's view. An email NameID is the address. The choice has privacy and joinability implications, and it matters for shadow AI when correlating SAML sign-in events to other telemetry: if the log shows a transient NameID and the correlation needs a persistent identifier, the join has to happen on a different attribute.

The shadow AI lens

Most consumer AI tools speak OIDC, not SAML, because AI vendors target the developer mass market: easy to integrate, JSON-based, JavaScript-friendly. The 'sign in with Google', 'sign in with Microsoft' and 'sign in with Apple' buttons on consumer AI tools are OIDC. Where SAML shows up in AI tooling is at the enterprise tier: ChatGPT Enterprise, Claude for Work, Microsoft Copilot, Google Gemini Enterprise usually support SAML, sometimes only SAML, because large customers require it, and Australian government procurement has historically required SAML support for whole-of-government arrangements. (medium; documented in some procurement rulebooks, not all, and practice varies by agency)

The control problem is therefore stratified by tier. A SAML-federated enterprise-tier AI tool is governable through the same federation that governs Workday and ServiceNow. An OIDC consumer-tier tool used under personal accounts is invisible at the corporate identity layer regardless of protocol. An OIDC consumer-tier tool signed into with 'Continue with Microsoft' is governable through the OIDC half of the estate, because Entra speaks both. That dual-protocol capability is what makes the workable picture work: Entra and Google Workspace both speak SAML and OIDC at once, and the same Conditional Access policies apply to both, so an organisation can federate Workday over SAML and claude.ai over OIDC to one tenant and target 'generative AI tools as a category' with one policy that bites both.

For Australian universities specifically, the SAML estate is not optional. The Australian Access Federation, operated by AARNet since 2009, lets researchers and students sign in to research services with their home-institution credentials, and underpins access to the Australian Research Data Commons, the National Computational Infrastructure, eResearch services and library and journal aggregators. (high) For a defender at a university, the SAML estate carries a large fraction of daily SSO traffic, and shadow AI controls written only for OIDC will leave it uncovered. The IdP-initiated flow is a specific surface worth flagging: whether enterprise-tier AI tools appear as tiles in the 'My Apps' portal is a policy choice many organisations have not consciously made, because the tile appeared when the SaaS was federated, not because someone decided it should be visible. And Entra's sign-in log records a Protocol field distinguishing SAML from OIDC, so detection rules for shadow AI activity need to be written protocol-agnostically or run as two parallel rules; mixing this up is a recurring source of incomplete detection.

Last updated 9 August 2026