Skip to content
REDMAW

SaaS & Identity

SAML Assertion Forgery

A broken SAML trust boundary can let an attacker create or manipulate an assertion that a service provider accepts as a legitimate identity or role.

RedMaw

Definition

In SAML, an identity provider issues a signed assertion and a service provider accepts it as proof of identity. Forgery becomes possible when the service provider's validation is incomplete, either of that signature or of what the signature actually covers.

Where validation typically weakens

  • Signature verification that does not cover the elements being trusted
  • Acceptance of assertions from an unintended or unpinned issuer
  • Insufficient handling of document structure and canonicalization
  • Missing validation of audience, recipient, timing or replay conditions

Why the consequence is disproportionate

Enterprise SSO is deliberately a central trust point. An accepted forged assertion does not merely authenticate a session. It can assert a role, a group membership or an administrative identity, and it does so through the mechanism the organization built specifically to be trusted.

Where it leads
  1. Attacker
  2. Forged Assertion
  3. SaaS / Application
  4. Privileged Identity
  5. Sensitive Data

Each hop validated by successful exploitation

Tags

  • saml
  • sso
  • authentication

Validation

How RedMaw validates this attack

Validation runs only inside authorized scope, with agreed exploitation limits.

  1. 01Establish which elements the service provider actually validates
  2. 02Test issuer, audience, timing and replay conditions
  3. 03Determine whether a manipulated assertion is accepted
  4. 04Establish what identity or role an accepted assertion confers

Stop assuming you are secure. Prove it.

Continuously test what an attacker can actually reach across your applications, SaaS identities, internal infrastructure and AI systems.