SAML Security Guide: Golden SAML and Signature Wrapping

Every SAML service provider grants access on the strength of one XML signature, so a stolen signing key or a sloppy signature check lets an attacker become any user, including administrators, without a password or MFA prompt. SAML 2.0 still carries a large share of enterprise single sign-on (SAML SSO), especially for older SaaS applications and on-premises federation servers such as AD FS. This guide explains how a SAML response is validated, how Golden SAML and XML signature wrapping work conceptually, how to protect and rotate signing certificates, what to log, and when to move to OpenID Connect. For the wider picture see the Identity Provider and SSO Security Guide. It is written for identity engineers, SAML application owners and detection teams.

Key takeaways

• The signing key is the identity system. Whoever holds a SAML signing key can mint assertions for any user with any claims and any lifetime, which is the core of a Golden SAML attack.
• Most SAML breaks are validation bugs at the service provider. Signature wrapping, unsigned assertions accepted, missing audience or destination checks and weak replay handling all live in the SP, not the IdP.
• Prefer SP-initiated SAML and treat unsolicited responses as a risk. OWASP calls IdP-initiated SSO "inherently less secure by design due to the lack of login CSRF protection".
• Certificate rotation needs a runbook, not a calendar reminder. Planned rollover keeps federation working; emergency rollover after compromise must happen twice in quick succession and be paired with session revocation.
• Detect forgery by what is missing. A forged token arrives at the application with a valid signature but no matching issuance event at the IdP, so correlating IdP and SP logs is the main detection.

How SAML single sign-on works

SAML 2.0 is the OASIS standard (core documents approved in March 2005) that lets a SAML identity provider (IdP) vouch for a user to a SAML service provider (SP). It is built from assertions, protocols, bindings that carry messages over HTTP, and profiles such as Web Browser SSO.

• SAML assertion: the signed XML statement about the user. It contains the Issuer, a Subject (the NameID), Conditions (NotBefore, NotOnOrAfter, AudienceRestriction), an AuthnStatement saying how and when the user authenticated, and an AttributeStatement carrying attributes such as email, groups or roles.
• SAML response: the protocol message that wraps one or more assertions and is posted back through the browser. It carries a Destination, an InResponseTo value and a status; the response, the assertion or both can be signed.
• SAML assertion consumer service (ACS) URL: the SP endpoint that receives the response, normally via the HTTP POST binding. The assertion consumer service URL is published in SP metadata and should be the only place the IdP sends responses.
• SAML RelayState: a value that travels with the flow so the SP can return the user to the page they asked for. The IdP must return RelayState unmodified, and OASIS warns that it "can leak details of the user's activities at the SP to the IdP".
• SAML metadata: XML each party publishes listing entity IDs, endpoints, bindings and signing and encryption certificates; it is how partners learn about a new signing certificate.

SP-initiated versus IdP-initiated SAML

In SP-initiated SAML the user visits the application, the SP sends an AuthnRequest with an ID, and the IdP answers with a response whose InResponseTo matches that ID. In IdP-initiated SAML the user starts at an IdP portal and clicks an application tile, so the SP receives an unsolicited SAML response with no InResponseTo to check. That is why IdP-initiated flows are weaker against login CSRF and injection, and why NIST SP 800-63C-4 requires the relying party to initiate the transaction at federation assurance level 2 (FAL2) and above.

XML signature wrapping and SAML validation flaws

SAML signature validation is hard because XML Signature signs a referenced element, not the whole document. XML signature wrapping (XSW), also called SAML signature wrapping, abuses the gap between the code that verifies the signature and the code that reads the identity: a genuinely signed element stays in the message so verification passes, while an unsigned assertion sits where the business logic finds it first. It is a classic route to SAML authentication bypass and SAML injection.

• The research baseline: the USENIX Security 2012 paper "On Breaking SAML: Be Whoever You Want to Be" analysed 14 major SAML frameworks and found critical signature wrapping flaws in 11 of them.
• It keeps recurring: CVE-2024-45409 in a widely used open source Ruby SAML library (NIST CVSS 9.8) let an unauthenticated attacker holding any signed SAML document from the IdP forge a response or assertion and log in as another user. It was fixed in versions 1.12.3 and 1.17.0.
• Other validation failures: accepting unsigned responses, trusting the certificate in KeyInfo instead of a pinned key, and parser differences that make two components read different NameIDs.

The OWASP SAML Security Cheat Sheet gives the defensive rules: validate the XML schema before processing and never download schemas from remote locations; select the verification key locally and ignore KeyInfo in the document; never select security elements with a generic tag search such as getElementsByTagName; use absolute XPath expressions or a hardened schema; and confirm the Reference URI resolves to the assertion that is actually used. The strongest control is not to write SAML parsing yourself: use a maintained library or platform SAML support and patch it as a critical dependency.

Golden SAML and SAML response forgery

Golden SAML is ATT&CK T1606.002 (Forge Web Credentials: SAML Tokens). MITRE describes an adversary with a valid token-signing certificate being able to "forge SAML tokens with any permissions claims and lifetimes". The tokens are new, created offline by the attacker, which separates the technique from stealing a real user's token. A forged assertion can also claim that MFA already happened.

How the signing key is obtained

• Theft from the federation server: an attacker with administrative access to an AD FS server, or the privileges that protect its configuration, exports the ADFS token signing certificate and its private key (ATT&CK T1552.004 Private Keys). This is why the AD FS farm, its service account and its database belong in tier zero.
• A new trust instead of a stolen key: an attacker with administrative rights in the cloud tenant adds their own federated domain or replaces the trusted signing certificate on an existing SAML federation trust, then signs with a key they generated. ATT&CK tracks this as T1484.002 Trust Modification, which in ATT&CK v20 sits under the Defense Impairment and Privilege Escalation tactics.
• Cloud IdP key compromise: any IdP signing key carries the same risk. The Microsoft Storm-0558 key breach showed what follows when a token-signing key leaves its protected boundary.

The SolarWinds compromise is the reference case: MITRE records APT29 creating tokens with compromised SAML signing certificates and changing domain federation trust settings to accept tokens signed with its own certificate. Password resets do nothing here, because no password is involved.

Limiting the blast radius

• Protect the key in hardware: Microsoft recommends protecting AD FS signing keys in a hardware security module, and notes that by default the keys never leave the federation servers and are never on Web Application Proxy machines. OWASP asks for FIPS 140-2 or 140-3 validated HSMs.
• Shrink administrative access: only Active Directory and AD FS administrators should have admin rights to AD FS servers, those servers should sit in a dedicated OU with their own GPOs, and administration should come from privileged access workstations (ATT&CK mitigation M1026).
• Reject MFA claims from the federated IdP: for Entra ID federation, Microsoft recommends setting federatedIdpMfaBehavior to rejectMfaByFederatedIdp unless MFA is genuinely performed by a third-party provider, so a forged "MFA done" claim does not satisfy Conditional Access.
• Reduce the number of signing keys: every federation server is another key to steal, so decommission unused ones.

Hardening the service provider and the connection

Use the table to set defaults and document exceptions.

• SAML audience restriction and destination: require both on every response. OWASP notes that an exact Destination check "prevents cross-SP assertion replay".
• SAML replay: keep assertion lifetimes to minutes, cache assertion IDs until NotOnOrAfter and reject repeats, and honour OneTimeUse where present. MITRE notes the default AD FS token lifetime is one hour.
• RelayState: if it carries a URL, validate it against an allowlist of the SP's own paths. Otherwise it becomes an open redirect.
• SAML attribute mapping: map roles from authoritative IdP attributes, send the minimum each SP needs, use an immutable NameID, and never let a user-editable attribute grant admin rights.
• Metadata hygiene: consume metadata over TLS from a fixed URL, not email, and alert on unexpected certificate changes.

Signing keys and SAML certificate rotation

A SAML signing certificate is usually self-signed and trusted by direct exchange, so rotation is a coordination problem rather than a PKI problem.

Planned rotation

1. Inventory: list every SAML application, certificate thumbprint, expiry, algorithm and SP owner.
2. Publish early: add the new certificate as secondary in metadata so partners trust it before it signs.
3. Pilot: switch a low-risk application first, test sign-in, then proceed by risk tier.
4. Promote and monitor: make the new certificate primary and watch for signature validation failures at SPs.
5. Roll back if needed: while the old certificate is valid, re-promote it if an SP fails, fix that SP and retry.
6. Retire: remove the old certificate from the IdP and from every SP trust store once no application depends on it.

Emergency rotation after suspected key compromise

MITRE mitigation M1015 is to rotate the AD FS token-signing certificate twice in rapid succession so that tokens signed with the previous certificate are no longer accepted. Pair it with session revocation, a review of federated domains and identity providers for additions, a check of application credentials added during the exposure window, and a server rebuild if needed. Accept outages for partners that do not consume metadata; a trusted stolen key is worse.

Detecting Golden SAML and SAML abuse

AD FS auditing is off by default: grant the service account the "Generate security audits" right, enable the "Application Generated" audit subcategory (ATT&CK mitigation M1047), and enable success and failure audits in the federation service properties. The default AuditLevel Basic logs no more than five events per request; Verbose logs everything.

MITRE's detection strategy for forged SAML tokens (DET0148) is essentially correlation: valid signature at the application, but no matching authentication or issuance trail at the IdP. Send AD FS, domain controller and IdP logs to one place, build that join, and alert on federation changes in real time. See the ITDR Guide.

Metrics that show it is working

• Signing coverage: percentage of SAML applications with signed assertions using SHA-256 (target 100 per cent, with dated exceptions).
• Certificate runway: number of SAML signing certificates within 60 days of expiry without a scheduled rollover (target zero).
• Unsolicited exposure: count of applications that still accept IdP-initiated responses, trending down.
• Correlation rate: percentage of SP SAML sign-ins matched to an IdP issuance event; investigate the remainder.
• Change response: median time from a federation trust change to human review (target under one hour for tier-zero changes).

SAML vs OIDC and SAML to OIDC migration

SAML is not broken, but OpenID Connect is usually the better default for new work.

• Keep SAML when: the application only supports SAML, it is stable and low risk, and the SP validation can be verified.
• Migrate to OIDC when: you are building or re-platforming the application, it needs API or mobile access, or its SAML library has a poor security record.
• Retire the federation server when: AD FS exists mainly to federate a Microsoft 365 tenant. Microsoft recommends password hash synchronisation for cloud authentication and supports staged rollout with cloud-only groups before domains are converted from federated to managed; conversion can take up to 60 minutes per domain, and rollback converts the domain back to federated. Remove the Microsoft 365 relying party trust once it shows no new requests.
• Size matters: small organisations gain most by removing self-hosted federation servers entirely. Large estates should migrate by risk tier, starting with sensitive applications and those accepting unsolicited responses.

For OIDC design details see the OAuth 2.0 and OpenID Connect Guide.

Framework mapping

Common failure patterns

• Federation servers treated as ordinary servers: AD FS hosts with shared GPOs and broad admin rights, the path to key theft seen in the SolarWinds compromise.
• Home-grown or unpatched SAML parsing: hand-rolled XML handling or old library versions leave signature wrapping open.
• Trusting the IdP's MFA claim: cloud policies that accept a federated "MFA done" claim, so a forged assertion bypasses MFA entirely.
• Expired certificate outages that train teams to rush: no inventory or owners, so emergency rotation is delayed for fear of breaking partners.
• Unwatched federation changes: no alert on new federated domains, identity providers or signing certificates, so an attacker-added trust persists.

Practitioner checklist

• Inventory every SAML application with its IdP, signing certificate, expiry, algorithm, initiation mode and owner.
• Treat AD FS and any self-hosted IdP as tier zero: dedicated OU and GPOs, PAW-only administration, HSM-protected signing keys, gMSA service account.
• Require signed assertions with SHA-256, pinned IdP keys, and Destination, Audience, InResponseTo and time window checks at every SP.
• Disable IdP-initiated SAML where it is not needed; where it remains, enforce replay caching and a RelayState allowlist.
• Set federatedIdpMfaBehavior to rejectMfaByFederatedIdp for federated Entra ID domains unless a third-party MFA provider is in use.
• Write and test planned and emergency certificate rotation runbooks, including the double rotation and session revocation steps.
• Enable AD FS auditing and alert on federation trust changes; correlate SP sign-ins with IdP issuance events.
• Plan SAML to OIDC migration and AD FS retirement by risk tier, using staged rollout and a documented rollback.

Standards and references

• OASIS: Security Assertion Markup Language (SAML) V2.0 Technical Overview
• NIST: SP 800-63C-4 Digital Identity Guidelines, Federation and Assertions
• MITRE ATT&CK: T1606.002 Forge Web Credentials: SAML Tokens
• MITRE ATT&CK: T1484.002 Domain or Tenant Policy Modification: Trust Modification
• OWASP: SAML Security Cheat Sheet
• Microsoft Learn: Best practices for securing AD FS and Web Application Proxy
• Microsoft Learn: Obtain and configure token signing and token decryption certificates for AD FS
• USENIX: On Breaking SAML: Be Whoever You Want to Be

Related NHI Mgmt Group resources: Identity Provider and SSO Security Guide · OAuth 2.0 and OpenID Connect Guide · Active Directory and Entra ID Hardening Guide · ITDR Guide · Cryptographic Key Management Guide