Federation and single sign-on trust¶
Federation is trust extended past the edge of one organisation. A service provider agrees to believe whoever an identity provider vouches for, and the vouching is a signed assertion: a SAML (Security Assertion Markup Language) statement or an OpenID Connect (OIDC) token saying this user authenticated, here are their claims. The service provider does not re-check the password; it checks the signature. That is the whole of the trust, and it collapses to a single question: who can produce a signature the service provider will believe?
The signing key is the identity¶
An identity provider signs its assertions with a private key, and whoever holds that key can sign anything. Golden SAML is the name for stealing an Active Directory Federation Services (ADFS) token-signing certificate and forging SAML assertions for any user, to any service that trusts the federation, with any claims the attacker wants. It needs no password, survives password resets, and passes multifactor authentication because the assertion simply states that the factor was met. The SolarWinds intrusion used this to move from a compromised network into cloud services that trusted its federation. The service providers behaved correctly throughout: they honoured a signature that was, cryptographically, genuine.
Adding a trusted issuer¶
The trust can be extended rather than stolen. In a cloud tenant, adding a federated domain with an attacker-controlled signing key installs a new issuer the tenant will honour, and from then on the attacker mints tokens for any user in it. AADInternals tooling automates exactly this against Entra ID as a backdoor: the federation trust persists independently of every user’s password, and removing it requires noticing it, which is harder than it sounds in a tenant that already runs legitimate federations.
Cross-tenant and guest trust¶
Federation also runs sideways, between organisations. Guest access, business-to-business (B2B) collaboration and cross-tenant access settings extend a measure of trust to principals from partner tenants, and that trust is only as sound as the partner. A guest account with more reach than intended, or a partner tenant quietly compromised, is a trusted route in, one the home tenant did not create and may not watch. The consent a user grants to one application is the same shape, a step smaller: a consent-phishing route scopes the trust to a single app rather than the whole tenant.
What the relying party forgets to check¶
Where the signatures hold, validation gaps take their place. A relying party that does not pin the expected issuer, or checks the audience loosely, can be handed a token minted for somewhere else. OIDC and SAML both carry the bindings, issuer and audience among them, that limit a token to its intended service; in practice these are sometimes left unchecked, and a token good for one relying party is replayed at another that shares the assumption but not the scrutiny.
Mapping the federation before forging it¶
Federation is discoverable before it is abused. A tenant’s federated domains, the identity provider behind them, and often the federation servers themselves surface in DNS (Domain Name System), in the OpenID configuration it publishes, and in the realm-discovery endpoints queried at sign-in, before any password is entered. From inside, a single directory read lists every federation trust and the certificates behind it. An attacker learns which domains are federated, which provider signs for them, and therefore which key is worth stealing, without touching an account.
The second signer survives rotation¶
The controls exist and move slowly. A token-signing certificate can be rotated, which invalidates a stolen one, but rotation is infrequent and a backdoor certificate added as a second signer simply survives it. New federated domains and changes to trust configuration can be alerted on, yet in a tenant already running legitimate federations the malicious one hides in the traffic of the honest ones. Conditional access, token protection and a move to cloud-native authentication each narrow the window, and each depends on the organisation noticing the trust at all. A federation compromise is quiet precisely because everything it produces is, by the tenant’s own rules, valid.