安全性断言标记语言 SAML

级别：入门

Frank Cohen（[email protected]）
创始人，PushToTest
2003 年 10 月

2003 年初，OASIS 小组批准了安全性断言标记语言（Security Assertion Markup Language，SAML）规范。由于来自 25 家公司的 55 名专家参与了该规范的制定，因此人们会认为 SAML 能做任何事情，并且能被很好地理解。但事实并非如此，软件开发社区存在着很多对 SAML 的误解。在本文中，Frank Cohen 详细说明并澄清了有关 SAML 的很多不实说法和误解。

作为一个新生事物，新的安全性断言标记语言（SAML）规范正在被人们拿来与现有的单点登录技术、认证服务和目录服务进行比较。SAML 是第一个可能成为多个认证协议的规范以利用 Web 基础结构（在这种 Web 基础结构中，XML 数据在 TCP/IP 网络上通过 HTTP 协议传送）。

OASIS 小组开发 SAML 的目的是作为一种基于 XML 的框架，用于交换安全性信息。SAML 与其它安全性方法的最大区别在于它以有关多个主体的断言的形式来表述安全性。其它方法使用中央认证中心来发放证书，这些证书保证了网络中从一点到另一点的安全通信。利用 SAML，网络中的任何点都可以断言它知道用户或数据块的身份。然后由接收应用程序作出决定，如果它信任该断言，则接受该用户或数据块。任何符合 SAML 的软件然后都可以断言对用户或数据的认证。对于即将出现的业务工作流 Web 服务标准（在该标准中，安全的数据需要流经几个系统才能完成对事务的处理）而言，这很重要。

尽管 SAML 刚刚被批准没多久，但是却有许多有关 SAML 的不实说法和误解要澄清。我认为，如果您真正了解了当今的某个新兴标准，那么它肯定已经过时了。

本文讨论了有关 SAML 的一些比较常见的不实说法和误解。

误解：SAML 是一个完整的身份管理解决方案。

SAML 作为身份管理解决方案中服务器之间的通信协议发挥了重要作用；但是，SAML 并不是完整的解决方案。在信息系统安全性领域，近来出现的身份管理是一个新术语，它涵盖了下面这些计算领域：

• 准备（provisioning）— 将新用户添加到企业内部信息系统和外部合作伙伴信息系统的网络操作系统目录和应用程序服务器目录中。
• 密码管理 — 使用户能够用一组凭证登录到公司的信息系统。此外，使用户能够自己管理其密码、用户帐户数据和特权。
• 访问控制 — 使系统能够识别用户组的安全性策略。例如，某项安全性策略防止某个人更改他或她的职位，但能将职位更改请求发送给具有相应权限的人。

SAML 是两台服务器需要共享认证信息时使用的协议规范。SAML 规范中没有任何内容提供了实际的认证服务，认证服务是由商业目录服务器提供的。

不实说法：企业之间的 Web 单点登录很好理解并且易于实现。

SAML 是旨在减少构建和操作信息系统（这些系统在许多服务提供者之间相互操作）所花费成本的众多尝试之一。在当今竞争激烈且迅速发展的环境中，出现了通过浏览器和支持 Web 的应用程序为用户提供互操作性的企业联合。例如，旅游网站允许用户不必进行多次登录即可预订机票和租车。今天，一大群软件开发人员、QA 技术人员和 IT 经理都需要处理复杂的和不可靠的后端系统，这些系统提供了企业之间的联合安全性。

在典型的支持 Web 的基础结构中，运行业界领先的企业系统的软件需要处理权限服务器之间的浏览器重定向、服务器域之间的 HTTP post 命令、公钥基础结构（public key infrastructure，PKI）加密和数字证书，以及声明任何给定用户或组的信任级别的相互同意（mutually agreed-upon）机制。SAML 向软件开发人员展示了如何表示用户、标识所需传送的数据，并且定义了发送和接收权限数据的过程。

不实说法：SAML 是一个复杂的设计。

SAML 为那些需要在 Web 基础结构（XML/HTTP/TCP）上设计和构建可伸缩联合系统的系统架构设计师提供了一个蓝图。即使您决定不使用 SAML，但 SAML 规范还是回答了许多设计问题，这些问题是任何系统架构设计师在构建可互操作的且支持 Web 的系统时必须回答的。

作为一个示例，请考虑用来将权限请求编码成 XML 请求的 SAML 断言机制。SAML 定义了六类语句：

认证（Authentication）：主体已登录。例如，用于认证的 SAML 断言看起来可能象下面这样：

[email protected] logged in at 2003-02-06T19:22:09Z

属性（Attribute）：标识主体的特性。例如，[email protected] 拥有 Admin 角色。

权限决定（Authorization decision）：声明允许某个主体对某个资源执行操作。例如，[email protected] 被授权 GET http://www.pushtotest.com/ptt/kits/index.html。

断言属性（Assertion attribute）：一个可选机制，使行业团体能够定义特定于其行业的属性。

此外，SAML 定义了由某个断言中的语句共享的断言的属性，包括：

版本属性（Version attribute）：标识了断言所遵循的 SAML 规范的主版本和次版本。

SAML 还定义了可选的条件元素以限制权限请求的有效性。例如，如果 SAML 标记 NotBefore 或 NotOnOrAfter 指定的以 UTC 编码的日期，那么它可能是有效的。

最后，SAML 定义了一个 XML 签名（XML Signature）元素以标识认证中心。该元素可以包含一个带有公钥、到期日和使用策略的 X509 证书。XML 签名还包含签名值本身，签名值是由认证中心为元素内容生成的。可以使用 X509 证书中权威机构的公钥信息来验证签名。通常，SAML 的复杂性在于部署基于 SAML 的软件，以及设置公钥基础结构（PKI）环境和数字证书。

误解：SAML 为大多数行业预定义了所有属性含义。

SAML 并未为任何行业定义属性含义。而是定义了一个名称空间机制，行业团体可以使用该名称空间机制来为其特定行业定义属性。例如，在航空行业中，SAML 属性 role:mechanic 定义了飞机的机械师。系统两端的各方需要分别就 SAML 使用的名称空间达成一致。

SAML 规范标识自己的名称空间来限定 SAML 属性和元素。例如，名称空间 "urn:oasis:names:tc:SAML:1.0:action:ghpp" 定义了 SAML 操作中使用的 get/head/put/post http 操作。如果该 SAML 名称空间的格式看起来有点古怪，那么这可能是因为 SAML 名称空间未遵循 SOAP 和 XML-RPC 中的传统 XML 名称空间格式：XML 名称空间是 URI；SAML 使用 URI 的 URN 变体，而其它名称空间则使用 URL 变体。

不实说法：SAML 是一个认证权威机构。

SAML 是一个在服务器之间使用的认证协议。您仍然需要能帮助您实际登录的某些东西。SAML 所能说的只是“您已经登录了（you have logged in）”。例如，当 LDAP 服务器对一个用户进行认证时，认证权威机构是 LDAP 服务器 — 即使 LDAP 服务器可能正在使用 SAML 来传送认证。

在完整的认证系统中，您仍需要编写策略决策点，以确定用户是否可以访问 Web 页面。此外，您还需要编写策略强制实施点（enforcement point）。这是一个接收权限、检查角色和权限，然后做出断言的 servlet 或应用程序。有几家公司提供了商业策略决策点和策略强制实施点解决方案，这些公司包括 Oblix、Netegrity、IBM 和许多其它公司。

误解：在认证需要传输大量数据的 Web 环境中，SAML 不能很好地工作。

当权限请求对于 HTTP 重定向而言太长时，SAML 定义了一种助诊文件（artifact）机制。SAML 助诊文件的长度为 42 字节，它包含一个类型-代码 — 长度为 20 个字节的源标识，以及长度为 20 个字节的随机数，服务器用它来查找断言。源服务临时存储断言。目标站点接收断言，然后从源站点上的助诊文件直接抽出所需的数据。这允许两台不同的安全性服务器使用助诊文件。

不实说法：使用重播技术可以轻易地攻破 SAML。

重播攻击是这样一类攻击：它可以拦截有效的消息，然后再将该消息重播回服务。重播攻击可用于造成数据完整性问题以及拒绝服务攻击。

SAML 提供了避免重播攻击的保护。SAML 要求在传输断言和消息时使用 SSL 加密，以专门防止断言被拦截。此外，SAML 提供了数字签名机制，该机制使断言具有有效时间范围，以防止断言以后被重播。

最后，助诊文件概要具有其它两个重播对策：

• SAML 源站点只将断言返回给接收助诊文件的请求者。
• SAML 源站点在第一次使用助诊文件后会擦除其助诊文件到断言的映射，从而使得重播的助诊文件无效。

误解：SAML 定义了发现过程以查找认证权威机构。

SAML 未定义任何机制来查找接受 SAML 断言的目标站点。

SAML 定义了一种用于认证的推（push）机制：用户登录到源站点，然后该站点向目标站点发送一个断言。该过程需要源站点和目标站点之间进行数字签名。在 Web 环境中，浏览器将表单公布（post）到目标站点，并且在一个隐藏的表单变量中包含一个用 Base64 编码的签名和断言。

将来的 SAML 规范有可能包含发现机制。

不实说法：SAML 不能处理匿名或访客（guest）访问。

SAML 没有用于提供匿名认证的功能。请考虑这样一种方案，其中某个网站允许您使用合作伙伴网站的功能，但是不允许合作伙伴站点知道您是谁。SAML 未提供这样的功能。让 SAML 处理匿名或访客访问是可能的，但是这要求参与的企业就其自己的匿名访问或访客授权访问的约定达成一致。

不实说法：SAML 要求在客户机端和服务器端都有 SSL 证书。

SAML 构建在需要公钥基础结构（PKI）的基础之上，以提供数字签名和 SAML 断言的加密。所以，PKI 具有的不便 SAML 全都有。

SAML 是最先需要那种程度的细粒度安全性的协议中的一个；例如，XML 密钥管理规范（XML Key Management Specification，XKMS）提供的安全性将用于认证 SAML 断言。同时，通过要求使用 HTTP Basic 的 HTTP 客户机端认证或 SSL 客户机端证书认证，SAML 为 SAML 助诊文件提供了安全性。然后只将助诊文件发送给期望的请求者，在检索到助诊文件后则删除它。

误解：SAML 是雾件（vaporware，指已宣布但还未实现）；还没有人要实现它。

许多商业和开放源码产品中已经提供了 SAML，包括：

• IBM Tivoli Access Manager
• Oblix NetPoint
• SunONE Identity Server
• Baltimore, SelectAccess
• Entegrity Solutions AssureAccess
• Internet2 OpenSAML
• Netegrity SiteMinder
• Sigaba Secure Messaging Solutions
• RSA Security ClearTrust
• VeriSign Trust Integration Toolkit
• Entrust GetAccess 7

误解：Microsoft 不支持 SAML。

目前还不清楚 Microsoft 将如何支持 SAML，但是 Microsoft 和 OASIS 小组正在进行大量工作，以使得 SAML 与 Microsoft 的倡议相协调。Microsoft 的平台和服务（包括 Microsoft .NET Passport）将如何与那些实现 Liberty Alliance 和 OASIS WS-Security 项目协议的服务相互操作，还需拭目以待。例如，与 Passport 的专有系统不同，Liberty Alliance 认证规范使用 SAML 标记来交换认证标记。但是，这两种认证系统在将标记从一个站点传递到下一个站点的方式上有所不同。

Microsoft 已公开承诺使 WS-Security 路线图工作和 SAML 项目合理化。他们似乎更侧重于以 WS-Security 作为更通用的 Web 服务安全性模型，该模型可以使用现有的 IT 投资以及新兴标准（如 SAML 和 XrML）。Microsoft 正在与 OASIS WS-Security 小组通力合作，以使用 SAML 断言作为 WS-Security 凭证。最近，OASIS WS-Security 小组接受了 SAML 的 WS-Security 绑定。

尽管 Microsoft 对 OASIS WS-Security 小组无控制力，但 Chris Kaler 是该工作组的主席之一，同时也是 Microsoft 员工。我认为，如果 Microsoft 对于将 SAML 用于 Passport 和 Liberty Alliance 只想得到形式上的认可，那么 Microsoft 还不如向 ECMA 标准团体提供建议。

误解：XML 签名中的规范化是不需要的。

这完全错了。

XML 签名是一种规范，旨在满足将 XML 文档（包括 SAML）与数字签名一起使用的特殊需求。W3C 的 XML 签名工作组正在开发一种 XML 语法，以便于可以对几乎任何内容进行签名 — XML 文档、SOAP 消息头和 XML 元素，并且提供用于创建和验证数字签名的协议和过程。

XML 签名中的规范化是允许在多个服务之间进行认证所必需的。例如，请考虑当您通过浏览器界面从制造商那里购买个人计算机时，服务器端所发生的情形。多个服务处理订单的不同部分：一个服务提供搜索功能以找到您希望订购的产品；下一个是开帐单服务，它获取您的支付信息；最后一个服务获取装运信息。这三个系统使用 SAML 断言共享您的记录。规范化确保了您记录中的字节顺序保持相同，即使三个不同系统正在操作该记录也是如此。如果没有规范化，那么该记录就可能会发生变化并使 XML 签名无效，因为 XML 签名的任务是确保其签名的内容是完好无损的，并且字节顺序是相同的。

结束语

由于许多致力于安全性的公司已经提供了上市的产品，因而 SAML 有一个良好的起点。SAML 规范为在一组联合服务中设计支持 Web 的、单点登录的服务提供了良好的框架。SAML 规范工作组的工作还在继续，以使得 SAML 和其它新兴标准（包括 WS-Security）之间的互操作性需求合理化。

作者感谢 Charles Knouse（Oblix 的首席软件工程师）和软件开发论坛（Software Development Forum，www.sdforum.org）的 Web 服务特别兴趣组（Web Services Special Interest Group），感谢他们为研究本文所提供的帮助。

参考资料

• 请在 OASIS 联盟站点上阅读 SAML 规范。
  
  
• 请查阅 Murdoch Mactaggart 的 developerWorks 文章 Enabling XML security，这篇文章非常出色地介绍了 XML 加密和 XML 签名（2001 年 9 月）。
  
  
• 请了解即将出现的 Web 服务安全性协议的工作原理 — 请在 developerWorks 上阅读 基于 XML 的令牌的 WS-Security 概要文件（2002 年 8 月）。
  
  
• 通过 Jon Udell 有关 SAML 和 PKI 的 InfoWorld 文章了解更多背景知识。
  
  
• 请下载 alphaWorks 的 XML Security Suite，以获得一个 XML 数字签名的实现。
  
  
• 请回顾由 Frank Cohen 所撰写的前一篇文章，以了解先于 Web 服务流行的 XML 单点登录方法（developerWorks，2002 年 1 月）。
  
  
• 在 developerWorks XML 专区上找到更多 XML 参考资料。
  
  
• 请获取 IBM WebSphere Studio，这是一个使 XML 开发自动化的工具，可以使用 Java 语言和其它语言进行开发。它同 WebSphere Application Server 紧密集成，也可以与其它 J2EE 服务器一起使用。
  
  
• 了解如何成为一名 IBM 认证的 XML 及相关技术的开发人员。
  
  

关于作者 Frank Cohen 是一位“上门服务”人士，当企业需要测试和解决复杂的互操作信息系统（特别是 Web 服务）中的问题时，他可以上门服务。Frank 是 PushToTest（一家测试自动化解决方案公司）的创始人和几本有关测试信息系统的书籍的作者。Frank 最近出版的新书 Automating Web Tests with TestMaker 现在可在 http://www.pushtotest.com/ptt 找到。可以通过 [email protected] 与他联系。

 

http://www-900.ibm.com/developerWorks/cn/xml/x-samlmyth/index.shtml