SAML.

SAML (Security Assertion Markup Language), standardised as OASIS SAML 2.0 in 2005, defines how a trusted identity provider (IdP) issues digitally signed XML assertions describing a user's identity and attributes to a service provider (SP), enabling web single sign-on across security domains. SAML 2.0 supports HTTP-Redirect and HTTP-POST bindings; the SP must validate the assertion's XML signature, Audience, NotOnOrAfter time conditions and InResponseTo before creating a session.

Attacks and weaknesses

Two failure classes dominate. XML Signature Wrapping (XSW) and comment-injection bugs let an attacker smuggle attacker-controlled data past signature verification. In February 2018 Duo Labs disclosed a broad class of these flaws across popular toolkits — CVE-2017-11427 (python-saml), CVE-2017-11428 (ruby-saml), CVE-2017-11429 (saml2-js) and CVE-2017-11430 (omniauth-saml) — where a <!-- --> comment inserted into the NameID truncated the parsed subject, letting an authenticated user log in as another. Golden SAML, described by CyberArk in 2017, is post-compromise: an attacker who steals an AD FS token-signing private key can forge arbitrary assertions that bypass passwords and MFA. APT29 used exactly this in the 2020 SolarWinds/SUNBURST campaign to mint federated tokens that appeared as normal sign-ins.

Defences: enforce signed responses and assertions, strict audience/recipient checks, hardware-protect (HSM) the token-signing key, rotate it, and monitor for anomalous federated logins. For new integrations OpenID Connect is often preferred.

flowchart LR
  U[User browser] -->|1 access resource| SP[Service provider]
  SP -->|2 AuthnRequest redirect| IdP[Identity provider]
  IdP -->|3 authenticate user| IdP
  IdP -->|4 signed SAML assertion| U
  U -->|5 POST assertion| SP
  SP -->|6 verify signature + conditions| SP
  SP -->|7 session granted| U