SAML 与联合身份

SAML（安全断言标记语言）是一种基于 XML、用于交换身份验证和授权数据的标准，在企业 SSO中占主导地位。

• 它允许企业身份提供方为用户向许多应用提供可信证明。
• SAML 2.0 早于 OIDC 出现，但在 B2B 和员工身份管理领域仍然根深蒂固。

理解 SAML 对防御企业联合身份体系至关重要，因为单一的信任漏洞就可能暴露所有已连接的应用。

SAML 联合身份体系包含两个主要参与方。

• 身份提供方（IdP）负责对用户进行身份验证并签发断言（Okta、Entra ID、Ping）。
• 服务提供方（SP）是信任 IdP 并授予访问权限的应用。

双方通过带外交换元数据来建立信任，其中包括签名证书和端点 URL。

核心产物是断言，它是一份声明 IdP 已对某个主体进行身份验证的 XML 文档。

• 主体用于标识用户（NameID）。
• 条件定义有效时间窗口和预期受众。
• AuthnStatement记录身份验证的方式和时间。
• AttributeStatement携带角色、电子邮件和群组声明。

最常见的模式是SP 发起的 SSO。

• 用户访问 SP，SP 生成 AuthnRequest 并重定向到 IdP。
• IdP 对用户进行身份验证，并将签名的 Response 通过 POST 返回给 SP 的断言使用者服务（ACS）。
• SP 验证断言并创建本地会话。

SAML 的安全性建立在XML 数字签名之上。IdP 使用其私钥对断言和/或响应进行签名；SP 使用受信任的证书进行验证。

• 请直接对断言进行签名，而不只是对外层响应签名。
• 请使用元数据中的固定 IdP 证书验证签名，不要使用消息中嵌入的证书。

大多数 SAML 攻击都针对签名验证逻辑。

XML 签名包装是 SAML 中的一类签名攻击。攻击者保留一个有效签名的元素，同时添加第二个伪造的断言，而应用逻辑实际读取的是这个伪造断言。

• 签名仍然可以通过对原始片段的验证。
• 但是，业务逻辑处理的是注入的、未签名的断言。

缓解措施：使用经过加固的 SAML 库，验证已签名的元素就是实际使用的元素，并拒绝包含多个或含义不明确断言的文档。

断言必须绑定到预期的 SP。SAML 提供了明确的限制。

• AudienceRestriction 指定断言对哪个 SP 实体 ID 有效。
• SubjectConfirmation 中的 Recipient 必须与 ACS URL 匹配。

SP 必须执行这些检查。跳过受众检查会使为一个应用签发的断言能够被重放到另一个应用。

断言是短期有效且只能使用一次的凭据。SP 必须强制执行这一点。

• 遵守 NotBefore 和 NotOnOrAfter，并将时钟偏差控制在很小范围内。
• 跟踪断言的 ID，并在有效时间窗口内拒绝任何重复使用。
• 要求 ACS 端点使用 TLS。

如果不跟踪重放，被捕获的断言就可能在过期前再次提交。

身份联合可跨越组织边界扩展 SSO，有时借助在协议之间进行转换的中枢或代理。

• 每条信任链路都可能成为薄弱点；IdP 一旦遭到入侵，攻击者就能冒充所有用户。
• 身份代理可能在 SAML 和 OIDC 之间搭桥，因此需要谨慎映射声明。

对属性映射实施最小权限，并监控是否意外注册了新的 SP。

值得审计的常见 SAML 失效模式：

• 未验证签名，或者仅对响应签名而未对断言签名。
• 易受 XML 签名包装攻击影响。
• 缺少受众/接收方检查。
• 没有重放保护，或有效期窗口过长。
• SP 上存在 XML 外部实体（XXE）解析。
• 信任消息中嵌入的证书，而不是已固定元数据中的证书。

二者都提供 SSO，但设计不同。

• SAML 基于 XML，使用浏览器 POST/重定向绑定，在企业/员工场景中广泛使用，工具链成熟。
• OIDC 基于 JSON/JWT，适合 REST，移动端和单页应用支持更好。

许多组织同时运行二者。无论给定应用使用哪种协议，防御人员都应了解其断言验证规则，因为攻击面不同。

核心要点：

• SAML 是基于 XML 的企业级 SSO，身份提供方和服务提供方之间通过已签名的断言进行通信。
• 安全性取决于是否使用已固定的证书正确执行 XML 签名验证。
• 防范 XML 签名包装、重放和 XXE。
• 始终强制执行 受众/接收方限制和有效期窗口。
• 身份联合扩大了信任范围，但 IdP 遭到入侵时，影响范围也会成倍扩大。