SAML: A Fractal of Bad Design

Why SAML Is Called a "Fractal of Bad Design"

SAML (Security Assertion Markup Language) has long been the de facto standard for enterprise Single Sign-On (SSO). Yet a recently viral Hacker News article titled SAML: A Fractal of Bad Design describes SAML as exactly that — a fractal of bad design. The implication is that no matter which level you zoom into, you find the same flawed design patterns repeating themselves.

The fractal metaphor is remarkably apt. Fractals are defined by self-similarity: the structure of the whole mirrors the structure of its parts. When the author calls SAML a "fractal of bad design," they're suggesting that from the top-level protocol architecture, down through the message format, all the way to the low-level signature verification details, every layer harbors the same kinds of complexity, ambiguity, and security pitfalls. This isn't an isolated bug — it's a systemic, structural problem.

Complexity, Layer Upon Layer

The Original Sin: XML and Signatures

SAML is built on XML and relies heavily on XML Digital Signatures (XML DSig) and XML Encryption — both widely recognized as minefields in the security world. XML signatures allow signing a subset of a document, and the verifying party must precisely determine "which parts were signed and which weren't." This flexibility sounds powerful but opens the door to attackers.

The classic XML Signature Wrapping (XSW) attack stems directly from this: an attacker can inject a forged assertion into the document while preserving the original legitimate signature node, so the verification logic "sees" the signed portion while the application logic "uses" the forged one. This mismatch between what is signed and what is consumed is a recurring vulnerability in SAML implementations.

XSW attacks deserve a closer look. A SAML assertion typically contains an <Assertion> element whose ID attribute is covered by the signature. Attackers exploit inconsistencies between how XML parsers and signature verification libraries locate nodes — moving a legitimate signed assertion to a non-functional position in the document (e.g., under an <Extensions> node) and inserting a forged assertion in its place. The signature library still finds the valid signature and passes verification, while the business logic reads the attacker's fabricated identity claims. After these attacks were systematically studied around 2012, researchers found variants in multiple mainstream SAML implementations, including Shibboleth and OpenSAML. The root cause: XML DSig allows referencing arbitrary document subsets via XPath/XPointer, so a successful verification only means "a signature on some fragment is valid" — it does not guarantee that the node the application consumes is that same fragment.

Spec Ambiguity and Implementation Fragmentation

The SAML specification is massive, riddled with optional features and extension points. Different Identity Providers (IdPs) and Service Providers (SPs) routinely interpret the spec differently, leading to endless interoperability headaches. To get two systems talking, developers often relax validation or skip checks — and every such compromise can introduce a new security gap.

This is the deeper meaning of the fractal metaphor: complexity isn't concentrated in one patchable place; it's diffused throughout every corner of the protocol. Fix a signature validation bug, and you may leave new problems in assertion parsing, timestamp checking, or Audience Restriction handling.

Why This Old Problem Still Matters

The article garnered 45 upvotes and several comments on Hacker News, demonstrating that even though SAML is "old technology," the issues it raises remain practically relevant. Vast numbers of enterprise systems, government services, and SaaS platforms still depend heavily on SAML for identity federation and SSO — any implementation-level slip can escalate into a serious account-takeover risk.

A recurring consensus in the discussion: SAML's problem is largely not "can it be fixed" but rather "complexity itself is the risk." The larger a protocol, the more optional features it has, and the more complex its parsing paths — the higher the bar for correct implementation, and the greater the probability of error. Security and complexity tend to be inversely related.

Modern Alternatives

Because of SAML's pain points, the industry has increasingly gravitated toward JSON-based OAuth 2.0 and OpenID Connect (OIDC) for authentication and authorization. Compared to SAML:

• They use JSON and JWT instead of XML, making parsing simpler and less ambiguous;
• The signing scheme (JWS) is more straightforward, with clearer boundaries between what is signed and what is verified;
• They offer much better support for mobile, single-page applications, and API-driven scenarios;
• The spec ecosystem is more focused, and mainstream library implementations are generally of higher quality.

This doesn't mean OIDC/JWT is trap-free — there are historical issues like the alg: none attack and key confusion vulnerabilities — but overall, its design philosophy is better suited to the needs of modern distributed systems.

OpenID Connect (OIDC) builds on the OAuth 2.0 authorization framework, adding an identity layer via the ID Token (a JWT-format token). A JWT consists of three Base64URL-encoded segments — header, payload, and signature — where the signature covers the complete header and payload, eliminating the XSW-style "signed object vs. consumed object" mismatch. That said, JWT is not without flaws: early specs allowed setting the signing algorithm to none, and some implementations would accept unsigned tokens outright; the alg: RS256 vs. HS256 confusion attack could trick a server into using its public key as an HMAC secret to verify an attacker-crafted token. Most of these issues have been fixed in mainstream libraries or mitigated through best practices (e.g., whitelisting allowed algorithms), but they demonstrate that "simpler design" doesn't mean "zero defects" — you still need to pay attention to the security maintenance status of the libraries you use.

Practical Takeaways for Developers

For teams still maintaining or integrating SAML systems, this article offers several lessons worth keeping in mind:

• Never implement SAML or XML signature verification yourself — always use mature, well-audited libraries;
• Strictly validate the signature scope, Audience Restriction, validity time window, and IdP source of every assertion;
• For new projects, prioritize evaluating more modern, simpler protocols like OIDC;
• Treat complexity itself as a security cost, and actively avoid unnecessary flexibility in architectural decisions.

"A fractal of bad design" is a sharp critique, but the engineering philosophy behind it is worth reflecting on: good security protocols should strive to be simple, unambiguous, and hard to misuse — not endlessly layered with features and optional configurations.

Note: This article is based on a Hacker News discussion thread and its title. The original content was limited in detail; the specific SAML vulnerabilities discussed here draw on widely recognized issues in the industry and are provided for reference.