SAML: A fractal of bad design

Born in academic circles and nurtured within corporate IT departments, the Security Assertion Markup Language (SAML) authentication protocol remains a popular choice for many organizations. As software-as-a-service (SaaS) companies emerged in the late aughts, IT departments sought a method to enable users to authenticate across multiple web services.

This led to the success of SAML and the burgeoning single sign-on (SSO) industry. However, SAML's complexity has proven its undoing, making it a candidate for deprecation in favor of modern alternatives like OpenID Connect (OIDC).

SAML's origin can be traced back to the Organization for the Advancement of Structured Information Standards (OASIS) Security Services Technical Committee (SSTC). Created in 2002, SAML was intended to address the need for user authentication across an increasing number of web services as the internet transitioned from Web 1.0 to Web 2.0.

Academic institutions played a pivotal role in driving this movement, with notable projects such as Central Authentication Service (CAS) in 2002 at Yale, Shibboleth IdP in 2003 by Internet2, ADFS in 2003 by Microsoft, and simpleSAMLphp around 2007 by Uninett, a Norwegian company with ties to academia. These projects all eventually embraced SAML.

The SAML protocol evolved through various iterations, incorporating contributions from several organizations, including Netegrity's Security Services Markup Language (S2ML), Securant's AuthXML, VeriSign's Information Technology Markup Language (ITML), and Jamcracker's X-TASS. Despite its initial promise, SAML's design-by-committee approach resulted in a protocol marred by complexity and a reliance on insecure foundations.

One of the primary concerns with SAML is its reliance on XML, an XML-based markup language notorious for its complexity and security vulnerabilities. XML, despite its redeeming qualities, is far more intricate than newer alternatives like JSON, which poses challenges for the development of secure SAML implementations. Moreover, the protocol's foundation is built upon XML signature validation, a process deemed deeply flawed and prone to errors.

Most SAML implementations rely on libxmlsec, a complex C codebase that few developers actively scrutinize.

The security research community has exposed numerous flaws in SAML, including XML signature wrapping (XSW) attacks. While earlier research into XSW and SAML began as early as 2005, it was the 2012 paper "On Breaking SAML: Be Whoever You Want to Be" that laid the groundwork for automated XSW attacks. Despite its significance, XSW remains a persistent threat to SAML implementations.

Furthermore, SAML's design is riddled with additional security bug classes, such as XML External Entity (XXE) injection, entity expansion ("billion laughs"), DTD retrieval (SSRF), XPath/XQuery/XInclude/XSLT/CDATA injection, and more. Addressing these vulnerabilities and the protocol's inherent complexity is no simple task, as developers must first ensure their SAML libraries can handle all these bug classes before even considering the protocol's core functionality.

The sheer complexity of XML compared to more streamlined alternatives like JSON further exacerbates SAML's design flaws.

In conclusion, SAML's fractal design flaws reveal a protocol that was born out of committee-driven development and academic experimentation, but has since become a cumbersome and insecure choice for modern authentication needs. The time has come for organizations to retire SAML and embrace more secure, streamlined alternatives like OpenID Connect.