SAML: A Recursive Nightmare of Design

Originally conceived in the halls of academia and scaled within corporate IT infrastructures, the Security Assertion Markup Language (SAML) remains a cornerstone of organizational authentication.

As the late 2000s saw the explosion of Software-as-a-Service (SaaS), IT departments were desperate for a standardized method to authenticate users across a multitude of external web services. SAML and the burgeoning Single Sign-On (SSO) sector stepped in to fill this void.

However, SAML is currently buckling under the sheer mass of its own intricacy. It is high time we keep patching it deprecate it and transition toward streamlined, modern alternatives like OpenID Connect (OIDC).

In this analysis, I will dissect SAML's "design-by-committee" roots, its ascent through academic and corporate hierarchies, its gradual collapse under the scrutiny of security researchers, and the necessity of its replacement.

---

SAML 101: A Foundation of Dust

The danger of SAML lies in its deceptive simplicity. On the surface, it seems intuitive, but its underlying architecture is precarious.

"What s insidious about SAML is that it really is mostly straightforward to understand, but it s built on a foundation of sand, bone dust, and ash; it works … if you assume XML signature validation is reliable. But XML signature validation is deeply cursed, and is so complicated that most fielded SAML implementations are wrapping libxmlsec, a gnarly C codebase nobody reads." — Thomas Ptacek, 2023

The Genesis of SSO

According to Wikipedia, SAML is essentially an XML-based language used for security assertions. It was birthed in 2002 by the OASIS Security Services Technical Committee (SSTC).

While XML has some utility, it is vastly more complex than modern formats like JSON. Furthermore, the process of creating SAML—a committee of various subcommittees—was a textbook example of "kitchen-sink" design (reminiscent of the waterfall methodology or big design up front).

The result? Four distinct XML security protocols were crammed into one. The "intellectual property" contributed to the SSTC included:

From Campus to Commerce

The demand for such a protocol was genuine. As the web transitioned from Web 1.0 to Web 2.0, the need for seamless authentication across services grew. Academia led the charge:

• 2002: Central Authentication Service (CAS) at Yale.
• 2003: Shibboleth IdP via Internet2 (a research university consortium).
• 2003: ADFS by Microsoft.
• 2007: simpleSAMLphp by Uninett (Norway).

Once universities provided the proving ground, the commercial sector transformed this into a multi-billion dollar industry.

I experienced this firsthand while working on Duo’s first on-premises Access Gateway (DAG). Because it was built on simpleSAMLphp and the SAML protocol, I spent years immersed in its dense specifications. I was present when the XML comment bypass was discovered by Kelby Ludwig—a glimpse into the protocol's inherent fragility.

---

A Crack in the Armor

The "Achilles' heel" of SAML is XML Signature Wrapping (XSW). While research into signature wrapping and SAML existed as early as 2005, the definitive blow came with the 2012 paper "On Breaking SAML: Be Whoever You Want to Be." This research moved beyond theory, providing an automated method to identify XSW vulnerabilities.

This is precisely why we utilized simpleSAMLphp; at the time, it was one of the few implementations resilient to XSW.

The XML Burden

To understand why SAML is flawed, one must understand that it is built upon XML, which has a disastrous security track record. A SAML library must defend against a laundry list of XML-specific attacks before it even begins processing authentication:

• XXE (XML External Entity)
• Billion Laughs (Entity Expansion)
• SSRF (via DTD retrieval)
• Injection Attacks (XPath, XQuery, XInclude, XSLT, CDATA)

The mathematical reality of the design can be viewed as: $\text{Total Complexity} = \text{SAML Logic} + \sum(\text{XML Vulnerability Classes})$

XML vs. JSON: A Study in Complexity

The disparity in complexity between the two formats is stark:

Complexity is generally the enemy of security.