SAML and Federation

SAML (Security Assertion Markup Language) is an XML-based standard for exchanging authentication and authorization data, dominant in enterprise SSO.

• It lets a corporate identity provider vouch for a user to many applications.
• SAML 2.0 predates OIDC and remains entrenched in B2B and workforce identity.

Understanding SAML is essential for defending enterprise federation, where a single trust flaw exposes every connected app.

SAML federation has two principal parties.

• Identity Provider (IdP) authenticates the user and issues assertions (Okta, Entra ID, Ping).
• Service Provider (SP) the application that trusts the IdP and grants access.

Trust is established out of band by exchanging metadata, including signing certificates and endpoint URLs.

The core artifact is the assertion, an XML document stating that the IdP authenticated a subject.

• Subject identifies the user (NameID).
• Conditions define validity window and intended audience.
• AuthnStatement records how/when authentication occurred.
• AttributeStatement carries roles, email, group claims.

The most common pattern is SP-initiated SSO.

• User hits the SP, which generates an AuthnRequest and redirects to the IdP.
• The IdP authenticates the user and POSTs a signed Response back to the SP Assertion Consumer Service (ACS).
• The SP validates the assertion and creates a local session.

SAML security rests on XML digital signatures. The IdP signs the assertion (and/or the response) with its private key; the SP verifies with the trusted certificate.

• Sign the assertion itself, not merely the outer response.
• Verify the signature against a pinned IdP certificate from metadata, not one embedded in the message.

Most SAML attacks target the signature validation logic.

XML Signature Wrapping is the signature attack class for SAML. The attacker keeps a validly signed element but adds a second, forged assertion that the application logic actually reads.

• The signature still verifies against the original fragment.
• But the business logic processes the injected, unsigned assertion.

Mitigation: use a hardened SAML library, validate that the signed element is the one consumed, and reject documents with multiple/ambiguous assertions.

An assertion must be bound to the intended SP. SAML provides explicit restrictions.

• AudienceRestriction names the SP entity ID the assertion is valid for.
• Recipient in SubjectConfirmation must match the ACS URL.

The SP must enforce these. Skipping the audience check lets an assertion minted for one app be replayed to another.

Assertions are short-lived, single-use credentials. SPs must enforce that.

• Honor NotBefore and NotOnOrAfter with tight clock skew.
• Track the assertion ID and reject any reuse within the validity window.
• Require TLS on the ACS endpoint.

Without replay tracking, a captured assertion can be submitted again before it expires.

Federation scales SSO across organizational boundaries, sometimes via hubs or brokers that translate between protocols.

• Each trust link is a potential weak point; a compromised IdP impersonates every user.
• Identity brokers may bridge SAML and OIDC, requiring careful claim mapping.

Apply least privilege to attribute mapping and monitor for unexpected new SP registrations.

Recurring SAML failure modes worth auditing:

• Signature not verified, or response signed but assertion not.
• Vulnerable to XML Signature Wrapping.
• Missing audience/recipient checks.
• No replay protection or overly long validity windows.
• XML External Entity (XXE) parsing on the SP.
• Trusting the certificate embedded in the message instead of pinned metadata.

Both deliver SSO, but differ in design.

• SAML XML, browser POST/redirect bindings, heavy in enterprise/workforce, mature tooling.
• OIDC JSON/JWT, REST-friendly, better for mobile and SPAs.

Many organizations run both. Defenders should know the assertion-validation rules for whichever protocol a given app uses, since the attack surface differs.

Select the best defense for the described attack.

Key takeaways:

• SAML is XML-based enterprise SSO between an IdP and SP using signed assertions.
• Security depends on correct XML signature validation against a pinned certificate.
• Defend against XML Signature Wrapping, replay, and XXE.
• Always enforce audience/recipient restrictions and validity windows.
• Federation scales trust but multiplies the blast radius of a compromised IdP.