SAML
本文约需 2 分钟阅读
SAML (Security Assertion Markup Language) 是一种基于 XML 的开放标准,用于在不同域之间安全地交换认证与授权信息。SAML 2.0 于 2005 年由 OASIS 制定,作为企业环境中单点登录 (SSO) 的事实标准已被使用 20 多年。即使OpenID Connect (OIDC) 在面向现代应用的场景中崛起,由于与既有企业系统的兼容性,对 SAML 的需求依然根深蒂固。
SAML 2.0 的认证流程
SAML 的认证流程有两种模式:SP-initiated (由 SP 发起) 和 IdP-initiated (由 IdP 发起)。在实务中,SP-initiated 被使用得远多于另一种。
SAML 断言的结构
SAML 断言是 IdP 用于将用户认证结果传达给 SP 的 XML 文档。它主要由三个要素构成。
描述用户在何时、以何种方式被认证。包含认证时刻和认证方式 (密码、MFA 等)。
存储用户的属性信息 (电子邮件地址、所属部门、角色等)。SP 利用这些信息进行访问控制。
描述对特定资源的访问是否被允许。在实务中很少使用,授权通常由 SP 一侧判断。
与 OIDC 的比较
SAML 与 OIDC 都是实现联合认证的协议,但二者在设计理念和技术基础上有很大差异。在新项目中,OIDC 往往是首选,但在既有企业环境中,SAML 成为必需的情况也不少。
| 观点 | SAML 2.0 | OIDC |
|---|---|---|
| 数据格式 | XML | JSON / JWT |
| 制定年份 | 2005 年 | 2014 年 |
| 主要用例 | 企业 SSO | Web 与移动应用 |
| 实现复杂度 | 高 (XML 签名、证书管理) | 低 (基于 JSON) |
| 移动端支持 | 困难 (以浏览器重定向为前提) | 原生支持 |
| 令牌大小 | 大 (数 KB) | 小 (数百字节) |
SAML 在遗留系统中持续被使用的原因
尽管 OIDC 更现代且更易于实现,SAML 在企业环境中仍被广泛使用,原因有多个。第一,Salesforce、Workday、ServiceNow 等主流 SaaS 多年来一直支持 SAML,将既有的集成配置迁移到 OIDC 的成本很高。第二,企业内部的 Active Directory 联合身份验证服务 (AD FS) 以 SAML 为前提构建,基础设施的更新并不容易。第三,审计与合规要求有时会要求使用「久经验证的协议」。企业密码策略的文章中也提到了 SSO 协议的选型。
SAML 特有的脆弱性 - XML 签名包装攻击
由于 SAML 基于 XML,它存在一种特有的脆弱性,称为 XML 签名包装 (XML Signature Wrapping, XSW)。在这种攻击中,攻击者将已签名的合法断言在 XML 文档内移动,并将自己伪造的断言插入到签名验证范围之外的位置。如果 SP 的 XML 解析器在签名验证和取值引用时查看了不同的节点,攻击者就有可能以任意用户身份登录。严格实现电子签名的验证逻辑并防止 XPath 注入,是对策的关键。
- 在签名验证时,仅将特定元素作为验证对象,而非整个 XML 文档
- 将 SAML 库保持在最新版本,并应用已知 XSW 脆弱性的补丁
- 在 SP 一侧对接收的断言进行严格的 schema 校验
- 如有可能,使用加密断言 (EncryptedAssertion)
常见误解
存在「SAML 很旧,所以不安全」这样的误解,但协议本身的安全设计是稳健的。问题源于实现上的缺陷 (签名验证不严、证书轮换遗漏等),而非 SAML 规范本身。请在初创企业安全检查清单中确认引入 SSO 时的实现检查要点。Web 安全相关书籍 (Amazon)也可作为参考。
现场使用案例
「我们公司以 Microsoft Entra ID 作为 IdP,与 30 多个 SaaS 进行 SAML 集成。新引入的 SaaS 优先采用 OIDC,但与既有的 Salesforce 和 ServiceNow 的集成仍以 SAML 方式运行。两种协议的共存,包括OAuth 的权限管理在内,都很复杂,但分阶段迁移是现实的选择。」
这篇文章对您有帮助吗?