SAML：一场糟糕设计的分形灾难

SAML 为何被称为“糟糕设计的分形”

SAML（Security Assertion Markup Language，安全断言标记语言）长期以来是企业单点登录（SSO）领域的事实标准。然而在近期一篇引发 Hacker News 热议的文章《SAML: A Fractal of Bad Design》中，作者将 SAML 形容为一种“糟糕设计的分形”——意思是无论你放大到哪个层级去审视它，都会发现同样的糟糕设计模式在反复出现。

“分形”这个比喻极为精准。分形的特征是自相似性：整体的结构与局部的结构一致。当作者说 SAML 是“坏设计的分形”时，暗示的是从最顶层的协议架构，到中间的消息格式，再到最底层的签名验证细节，每一层都埋藏着同样类型的复杂性、歧义与安全隐患。这并不是某个孤立的缺陷，而是一种系统性、结构性的问题。

复杂性的层层叠加

XML 与签名的原罪

SAML 建立在 XML 之上，并大量依赖 XML 数字签名（XML DSig）与 XML 加密。这两项技术本身就是安全领域公认的“地雷区”。XML 签名允许对文档的某个子集进行签名，而验证方需要精确地判断“究竟哪一部分被签名了、哪一部分没有”。这种灵活性看似强大，实则为攻击者打开了大门。

历史上著名的 XML Signature Wrapping（XSW）攻击正是源于此：攻击者可以在文档中插入伪造的断言，同时保留原始的合法签名节点，让验证逻辑“看”的是签名过的部分，而应用逻辑“用”的却是伪造的部分。这种签名对象与消费对象不一致的问题，几乎是 SAML 实现中反复出现的经典漏洞。

XML Signature Wrapping（XSW）攻击值得进一步说明。SAML 断言通常包含一个 <Assertion> 元素，其 ID 属性被签名覆盖。攻击者利用 XML 解析器与签名验证库在"定位节点"时行为不一致的特点，将一个合法的已签名断言移至文档的非功能性位置（例如 <Extensions> 节点下），再在原位置插入一个伪造的断言。签名验证库仍能找到那个合法的签名并通过验证，而业务逻辑读取的却是攻击者伪造的身份声明。这类攻击在 2012 年前后被系统性研究后，研究人员在多个主流 SAML 实现（包括 Shibboleth、OpenSAML 等）中均发现了变体漏洞。根本原因在于 XML DSig 规范允许通过 XPath/XPointer 指向文档中任意子集，验证成功只意味着"某个片段的签名有效"，并不保证"应用所消费的节点就是那个片段"。

规范的歧义与实现的分裂

SAML 规范篇幅庞大且充满可选项与扩展点。不同的身份提供商（IdP）与服务提供商（SP）在解读规范时往往产生偏差，导致互操作性问题层出不穷。开发者为了让两套系统“对接成功”，常常不得不放宽验证、绕过检查，而每一次妥协都可能引入新的安全缺口。

这正是“分形”比喻的深意所在：复杂性不是集中在某一处可以修补的地方，而是弥散在整个协议的每个角落。你修好了一个签名验证漏洞，却可能在断言解析、时间戳校验或受众限制（Audience Restriction）上留下新的问题。

社区讨论：老问题为何依然重要

这篇文章在 Hacker News 上获得了 45 个点赞与数条评论，说明尽管 SAML 是一项“老技术”，它引发的话题依然具有现实意义。大量企业级系统、政府服务和 SaaS 平台仍然深度依赖 SAML 完成身份联合与单点登录，任何一个实现层面的疏漏都可能演变为严重的账户接管风险。

讨论中反复出现的一个共识是：SAML 的问题很大程度上不是“能否修复”，而是“复杂度本身即风险”。一个协议越是庞大、可选项越多、解析路径越复杂，正确实现它的门槛就越高，出错的概率也越大。安全性与复杂性往往成反比。

更现代的替代方案

正因为 SAML 的种种痛点，业界近年来越来越倾向于采用基于 JSON 的 OAuth 2.0 与 OpenID Connect（OIDC） 作为身份认证与授权方案。相比 SAML：

使用 JSON 与 JWT 而非 XML，解析更简单、歧义更少；
签名方案（JWS）相对更直接，签名对象与验证对象的边界更清晰；
对移动端、单页应用和 API 场景的支持更友好；
规范生态更集中，主流库的实现质量普遍较高。

当然，这并不意味着 OIDC/JWT 就没有自己的陷阱（比如 alg: none 攻击、密钥混淆等历史问题），但整体而言，其设计出发点更符合现代分布式系统的需求。

OpenID Connect（OIDC）构建在 OAuth 2.0 授权框架之上，通过引入 ID Token（一种 JWT 格式的令牌）来完成身份认证层。JWT（JSON Web Token）由头部、载荷、签名三段 Base64URL 编码拼接而成，签名范围覆盖完整的头部与载荷，不存在 XSW 式的"签名对象与消费对象不一致"问题。然而 JWT 也并非无懈可击：早期规范允许将签名算法设为 none，部分实现会直接接受未签名的令牌；alg: RS256 与 HS256 的混淆攻击则可让服务端用公钥作为 HMAC 密钥来验证攻击者自签的令牌。这些问题大多已被主流库修复或通过最佳实践规避（如强制白名单允许的算法），但说明"更简单的设计"并不等于"零缺陷"，选型时仍需关注所用库的安全维护状态。

给开发者的实践启示

对于仍在维护或对接 SAML 系统的团队，这篇文章带来几点值得铭记的教训：

不要自己实现 SAML 或 XML 签名验证，务必使用经过充分审计的成熟库；
严格校验断言的签名范围、受众限制、有效时间窗口与 IdP 来源；
对新项目优先评估 OIDC 等更现代、更简洁的协议；
将“复杂度”本身视为一种安全成本，在架构选型时主动规避不必要的灵活性。

“糟糕设计的分形”是一句尖锐的批评，但它背后传递的工程哲学值得所有人思考：好的安全协议应当追求简单、明确、难以被误用，而不是无止境地堆叠功能与可选项。

说明：本文基于 Hacker News 上的一篇讨论帖及其标题所展开，原始内容信息有限，文中对 SAML 具体缺陷的展开结合了业界公认的常见问题，供读者参考。