Web 服务世界的安全性：提议的体系架构和指南

文档选项

将此页作为电子邮件发送
级别： 初级
IBM,
2002 年 4 月 01 日
本文描述了为解决 Web 服务环境中的安全性问题 而提议的策略。它定义了一个全面的 Web 服务安全性模型，这个模型通过使各种系统能够安全地以一种与平台和语言无关的方式进行互操作来支持、集成和统一几个流行的安全性模型、机制和技术（包括对称和公用密钥技术）。它还描述了一组规范和案例，这些案例显示了如何一起使用这些规范。
2001-2002International Business Machines Corporation,Microsoft Corporation. All rights reserved.
这是一个预备文档，以后随着时间的推移可能会发生实质性的改变。本文档中包含的信息代表 International Business Machine 和 Microsoft Corporation 在发布之日对所讨论问题的当时的观点。因为 IBM 和 Microsoft 必须对不断变化的市场形势作出反应，所以不应该将本文档解释为 IBM 和 Microsoft 方面做出的承诺，并且 IBM 和 Microsoft 无法在发布之日后保证本文档提供的任何信息的准确性。
允许提供、分发或以其它形式传播这篇文档中所包含的信息并不意味着（无论明示的还是默示的）给予您 IBM 或 Microsoft 和／或其他第三方所拥有或控制的知识产权的许可证。IBM、Microsoft 和／或其他第三方可能拥有涵盖本文档中主题的专利权、专利申请、商标、版权或其他知识产权。提供这篇文档并没给予您 IBM 或 Microsoft 或任何其他第三方的专利权、商标、版权或其它知识产权的许可证。这里描述的示例公司、组织、产品、域名、电子邮件地址、徽标、人物、地点和事件纯属虚构。如关系到任何真实的公司、组织、产品、域名、电子邮件地址、徽标、人物、地点或事件纯属无意，请勿妄加推测。
这里包含的这篇文档和信息以“仅此状态”提供，并被适当的法律最大程度地许可，IBM 和 Microsoft 以“仅此状态和未消除任何错误”的状态提供本文档，因此对所有关于本文档的其它保证和条件（无论是明示的、默示的、还是法定的）不负任何责任，这些保证和条件包括（但不限于）任何（如果有的话）对适销性、适用于某特定用途、准确性、完全负责、结果、技艺精湛的成果、确认无病毒、无疏忽等保证和条件。另外，对于本文档相关的知识产权的标题、安静享用、安静拥有、与描述相符或不侵犯也不提供任何保证或条件。
在任何情况下，IBM 或 MICROSOFT 都不对任何第三方受到的生产替代品或服务损失、利润亏损、使用上的损失、数据损失、或者任何意外的、相应产生的、直接的、间接的、或特殊的损害负责，不管是有合同、民事侵权行为、保证还是其它条件、由此引起还是由与本文档相关的任何其它协议引起、也不管第三方是否已经提醒可能会有这种损害。




回页首
IT 业已经谈论了将近两年 Web 服务。当 Web 服务用于试验计划和大规模生产时，拥有一种松散耦合的、与语言和平台无关的、在组织内跨企业、跨因特网链接应用程序的方法的好处正变得愈发明显。再往前，我们的客户、业界分析家和新闻界确定了当 Web 服务日益成为主流时要解决的关键问题：安全性。这篇文档提议了一个技术上的策略和指南，业界可以籍此建立并实现一个基于标准的体系架构，这个体系架构非常全面，同时又足够灵活，可以满足真实企业的 Web 服务安全性需要。
这个新出现的 Web 服务体系架构的关键好处是能够交付集成的、可互操作的解决方案。通过应用这个全面的安全性模型，确保 Web 服务的完整性、机密性和安全性对组织和它们的客户来说都至关重要。
为回应客户和业界所示的关心，IBM 和 Microsoft 已经联手制定了这个提议的 Web 服务安全性计划和指南，用来开发一组说明如何为在 Web 服务环境中交换的信息提供保护的 Web 服务安全性规范。
第一次，我们把以前不兼容的安全性技术，如公用密钥基础架构、Kerberos 和其它安全性技术都放在了一起，创建了一个安全性模型。简言之，它不是一个理想化的框架而是一个实用框架，它使我们能够在我们的客户目前所在的异类 IT 世界中构建安全的 Web 服务。
在这篇文档中，我们提供了一组范围很广的规范，它们包含许多安全性技术，其中包括跨范围广泛的应用程序和企业拓扑的认证、授权、隐私权、信任、完整性、机密性、安全通信通道、联合、委托和审核。这些规范提供了一个框架，这个框架可扩展、灵活并且最大程度地利用安全性基础架构中的现有投资。这些规范包含并扩充了 IBM 和 Microsoft 以前提议的相似规范（即 SOAP-Security、WS-Security 和 WS-License 规范）中表达的思想。
通过利用 Web 服务模型核心处的自然可扩展性，这些规范建立在一些基础技术如 SOAP、WSDL、XML 数字签名（XML Digital Signature）、XML 加密法（XML Encryption）和 SSL/TLS 的基础之上。这允许 Web 服务提供者和请求者开发满足他们应用程序的个别安全性需求的解决方案。
IBM 和 Microsoft 目的在于与客户、伙伴和一些标准组织合作用一种阶段性方法发展并改善这个安全性模型。我们正在为 WS-Security 规范促成这种工作。WS-Security 定义了用于保护消息完整性和机密性的核心工具以及用于把有关安全性的声明与消息关联起来的机制。虽然 WS-Security 是这种工作的基础，但它只是个开始，我们将与业界合作制定出处理策略、信任和隐私权问题的附加规范。
为使本文档中讨论的问题和解决方案尽可能具体，我们讨论了反映 web 服务当前和预期的应用程序的几个案例。这些案例包括防火墙处理、隐私权、浏览器和移动客户机的使用、访问控制、委托以及审核。
我们期望大家关心可以做些什么工作来确保各种提议的规范的互操作性和一致实现。为解决这个问题，IBM 和 Microsoft 将与标准组织、开发者社区以及业界组织（如 WS-I.org）亲密合作来开发将为工具厂商提供指导的互操作性概要文件和测试。
这篇文档概述了一个全面的、模块化的解决方案，在实现这个解决方案时，将允许客户构建可互操作而且安全的 Web 服务，这些 Web 服务在允许客户充分利用 Web 服务技术必须提供的集成和互操作性好处的同时利用并扩展安全性基础架构中的现有投资。




回页首
为 Web 服务提供安全性功能和组件的全面模型要求把当前可用的流程和技术与未来应用程序不断改进的安全性需求集成起来。它要求概念统一；它同时需要技术（安全的消息传递）和业务流程（策略、风险和信任）问题的解决方案；最后，它要求平台厂商、应用程序开发者、网络和基础架构提供者及客户共同努力。
统一这一系列可用安全性技术意味着应用程序安全性的功能需求必须从所应用的特定机制中抽象出来。例如，只要每个设备都能够安全地表示正确的身份，进行在线购买的用户就不应该受使用的是蜂窝式电话还是膝上型电脑的影响。
目标是使客户能够很容易地使用异类系统建立可互操作的解决方案。例如，这篇文档稍后提议的安全消息传递模型同时支持公用密钥基础架构（public key infrastructure，PKI）和 Kerberos 身份机制作为更通用工具的特殊体现，并且能够扩展到支持额外的安全性机制。集成通过单个安全性模型的抽象使一个组织可以使用它们在安全性技术中的现有投资，同时可以与使用不同技术的组织通信。
另外，当使用不同身份机制的组织合作使用 Web 服务时，安全性信任模型会提供一个灵活的框架，在这个框架中，如果配置了合适的授权，组织就可以互相连接。
同时，每个客户和每个 Web 服务根据它们特定的业务需要和运营环境都有自己独特的安全性需求。例如，在工作组设置中，简单性和易于操作是大家最关心的，而对于公共的因特网应用程序，更优先考虑的是抵挡协同的拒绝服务攻击（denial-of-service）的能力。因为这些要求可以用多种方式组合在一起，并且可以以不同的特殊级别表示，所以成功的 Web 服务安全性方法就要求一组灵活的、可互操作的安全性基本元素，通过策略和配置，这些安全性基本元素可以使许多种安全解决方案成为可行的方案。
为解决这些问题，这篇文档根据一组把以前不同的技术集成在一起的安全性抽象提议了一种创新的方法来创建安全的、可互操作的 Web 服务。这样就能够对整体框架内的特定客户需求进行特殊化，同时允许技术随时间的推移而发展，并逐步递增地部署这些技术。
作为这个创新方法的示例，安全消息传递模型可以添加到现有的传输级别安全性解决方案。一个客户可以把消息级完整性或持久的机密性（消息元素的加密）添加到通过诸如安全套接字层（Secure Sockets Layer，SSL/TLS）传送消息的现有 Web 服务。现在，消息有了在传输层外持久存在的完整性（或机密性）。
我们期望能够从多个厂商广泛获取所提议的新兴模型和规范，并期望合适的标准组织会考虑它们。模型、规范和标准流程一起使企业能够快速而又有效利用成本地增加它们现有应用程序的安全性并放心地开发可互操作的、安全的新 Web 服务。
这种模型对企业的好处很明显。通过为 Web 服务构建一个全面的安全性体系架构，使组织和客户能够在业务流程正日益改建为 Web 服务时更好地确保它们的投资和资产会得到保护。
由于术语在各种技术间是不同的，本文档定义了一些术语，它们可以在不同的安全性格式和机制间被一致地应用。因此，这里使用的术语可能和其它规范中不同，定义这些术语是为了使读者可以把它们映射为自己更喜欢的词汇。
Web 服务（Web service）― 术语“Web 服务”广泛适用于许多种基于网络的应用程序拓扑。在这篇文档中，我们使用术语“Web 服务”来描述一些应用程序组件，这些组件的功能和接口被通过包括 XML、SOAP、WSDL 和 HTTP 在内的现有和新兴 Web 技术标准的应用程序公开给潜在的用户。与 Web 站点、基于浏览器的交互或者平台相关的技术相比，Web 服务是一种以与平台和语言无关的方式，通过定义的格式和协议，从计算机到计算机提供的服务。
安全性令牌（Security Token）― 我们定义了安全性令牌来表示与安全性相关的信息（例如，X.509 证书、Kerberos 票据和认证者、来自 SIM 卡的移动设备安全性令牌、用户名等等）。
下图显示了一些不同种类的安全性令牌。

已签名安全性令牌（Signed Security Token）― 我们定义了 已签名安全性令牌作为安全性令牌，它包含一组由签发者用密码的方式签署的相关声明（断言）。已签名安全性令牌的示例包括 X.509 证书和 Kerberos 票据。
声明（Claim）― 一个声明要么是一条关于主题的陈述，要么是由主题或者把主题与声明关联起来的依赖方做出的陈述。重要的一点是这个规范并不试图限制可以做出的声明的类型，也不试图限制如何表达这些声明。声明可以是关于可能用于对消息进行签名或加密的密钥的。声明可以是安全性令牌传达的陈述。声明可以用于，例如，表明发送者的身份或者一个被授权角色。
主题（Subject）― 安全性令牌的主题是一个主体（例如，一个人、一个应用程序或者一个业务实体），安全性令牌中表达的声明应用于这个主体。明确地说，主题作为安全性令牌的所有者拥有证明安全性令牌所有权所需的信息。
所有权证明（Proof-of-Possession）― 我们定义了 所有权证明来作为在证明一个安全性令牌或一组声明的所有权的过程中使用的信息。例如，所有权证明可以是与包含公用密钥的安全性令牌相关联的私有密钥。
Web 服务端点策略（Web Service Endpoint Policy）― Web 服务在指定处理消息所需的声明时非常灵活。我们把这些所需的声明和相关的信息合称为“Web 服务端点策略”。端点策略可以用 XML 表示，并且可用于指出与认证（例如，用户或组身份的证明）、授权（例如，某些执行能力的证明）相关的需求或其它定制的需求。
声明需求（Claim Requirement）― 声明需求可以依靠整条消息或消息的一些元素、给定类型的所有操作或者只在某种环境下发生的一些操作。例如，当请求者要购买的数量超过规定的限制时，服务可以要求请求者证明自己的权限。
中介体（Intermediary）― 当从最初的请求者向服务发送 SOAP 消息时，一些执行路由消息或者甚至修改消息等操作的中介体可能会对这些消息进行操作。例如，一个中介体可能会添加报头、加密或解密消息片段，或者添加额外的安全性令牌。在这种情况下，就需要小心行事使消息的更改不会使消息的完整性无效、不会违反信任模型或者破坏责任性。
参与者（Actor）― 一个 参与者就是一个中介体或端点（SOAP规范中这样定义到），它由 URI 标识，并处理 SOAP 消息。用户或客户机软件（例如，浏览器）都不是参与者。
可以通过向 URI 标识的服务端点发送 SOAP 消息、请求特定的操作并接收 SOAP 消息响应（包括错误的暗示）访问 Web 服务。在这个上下文中，保护 Web 服务这个大目标被分解为几个子目标 ― 提供用来保护消息完整性和机密性的工具以及用来确保服务只对表达策略所需声明的消息中的请求起作用的工具。
目前，安全套接字层（SSL）和实际的传输层安全性（Transport Layer Security，TLS）一起被用于为 web 服务应用程序提供传输级别的安全性。SSL/TLS 提供了几个安全性功能，包括认证、数据完整性和数据机密性。SSL/TLS 启用了点对点安全会话。
IPSec是另一个用于传输安全性的网络层标准，对于 Web 服务来说，它可能会变得很重要。与 SSL/TLS 一样，IPSec 也用主机认证、数据完整性和数据机密性提供安全的会话。
目前的 Web 服务应用程序拓扑把移动设备、网关、代理、负载平衡器、“非军事区”（demilitarized zone，DMZ）、外包数据中心（outsourced data center）和全球分发的、动态配置的系统这许多东西都组合在一起。所有这些系统都依赖于消息处理中介体转发消息的能力。特别是，SOAP 消息模型对抽象物理网络和应用程序基础架构的逻辑端点进行操作，因此它经常要把一个多跳（multi-hop）拓扑与中间参与者集成在一起。
当传输层之外的中介体接收并转发数据时，数据的完整性和任何随数据流动的安全性信息都可能会丢失。这就迫使任何上行消息处理器都要依赖先前中介体所进行的安全性评价并完全信任它们对消息内容的处理。全面的 Web 服务安全性体系架构中所需的东西是一个提供端到端安全性的机制。成功的 Web 服务安全性解决方案将能够同时利用传输层和应用层的安全性机制来提供一套全面的安全性功能。


这里描述的 Web 服务安全性模型使我们能够通过一个过程达到这些目的，在这个过程中：
Web 服务可以要求进来的消息证明一组 声明（例如，名称、密钥、许可、性能等等）。如果消息到达但没有必需的声明，那么服务可以忽略或者拒绝该消息。我们把这一组必需的声明和相关的信息称为 策略。
请求者可以通过把 安全性令牌与消息关联起来发送带必需声明的证明的消息。这样，消息既要求特定的操作又要证明它们的发送者具有要求该操作的声明。
如果请求者没有必需的声明，那么请求者或它们的代表可以通过与其它 Web 服务联系设法获得必需的声明。这些其它的 Web 服务，我们称其为 安全性令牌服务（security token service），可以接下来要求它们自己的一组声明。安全性令牌服务通过签发安全性令牌代理不同信任域之间的信任。
下图说明了这个模型，它显示任何请求者也都可以是服务，安全性令牌服务也完全可以是一个 Web 服务，并包括表达策略和要求安全性令牌。

这个常规的消息传递模型 ― 声明、策略和安全性令牌 ― 包含并支持几个更特殊的模型，比如基于身份的安全性、访问控制列表和基于性能的安全性。它允许使用现有的技术如 X.509 公用密钥证书、Kerberos 共享秘密的票据甚至密码摘要。我们后面将讨论到它还提供一个集成抽象，这个集成抽象允许系统在不同的安全性技术之间建立一座桥梁。这个常规模型对于建立更高级的密钥交换、认证、授权、审核和信任机制就已经足够了。




回页首
这里所描述的安全性策略和下面介绍的 WS-Security 规范为这个提议的 Web 服务安全性模型提供了战略目标和基础。
以后，我们将继续与客户、伙伴以及标准组织合作开发一套初始的 Web 服务安全性规范。

这组规范将包括一个消息安全性模型（WS-Security），还有 Web 服务端点策略（WS-Policy）、一个信任模型（WS-Trust）和一个隐私权模型（WS-Privacy）。这些初始规范一起提供了一个基础，在这个基础上我们可以跨多个信任域建立安全的、可互操作的 Web 服务。
根据这些初始规范，我们将继续与客户、伙伴及标准组织合作为安全会话（WS-SecureConversation）、联合信任（WS-Federation）和授权（WS-Authorization）提供后继规范。
这些安全性规范结合在一起使得许多用目前更基本的安全性机制难以实现的案例（本文档在后面描述了其中一些案例）可以成功。
同时，我们将提议并继续做些相关的工作，用与审核、管理和隐私权相关的规范加强 Web 服务安全性框架。
另外，IBM 和 Microsoft 还致力于与象 WS-I 这样的组织合作建立互操作性概要文件。
安全性规范、相关活动和互操作性概要文件组合在一起将使用户能够很容易地建立可互操作的、安全的 Web 服务。
下面概述了每个被提议的规范：
初始规范
WS-Security：描述如何向 SOAP 消息附加签名和加密报头。另外，它还描述如何向消息附加安全性令牌（包括二进制安全性令牌，如 X.509 证书和 Kerberos 票据）。
WS-Policy：将描述中介体和端点上的安全性（和其它业务）策略的能力和限制（例如，所需的安全性令牌、所支持的加密算法和隐私权规则）。
WS-Trust：将描述使 Web 服务能够安全地进行互操作的信任模型的框架。
WS-Privacy：将描述 Web 服务和请求者如何声明主题隐私权首选项和组织隐私权实践声明的模型。
后继规范
WS-SecureConversation：将描述如何管理和认证各方之间的消息交换，包括安全性上下文交换以及建立和派生会话密钥。
WS-Federation：将描述如何管理和代理异类联合的环境中的信任关系，包括支持联合身份。
WS-Authorization：将描述如何管理授权数据和授权策略。
为 Web 服务提供安全性要求在许多功能性领域制定描述、规范和轮廓的过程中付出理所当然的辛勤工作。在完成规范的过程中，这些文档将在平衡客户的需要与 Web 服务开发社区的需要的过程中以及我们自己的教育过程中发生改变并发展。
WS-Security 描述加强 SOAP 消息传递，通过消息完整性和消息机密性提供 保护质量。这个规范还定义了如何在 SOAP 消息内附加并包含安全性令牌。最后，提供一种用于指定二进制编码的安全性令牌（例如 X.509 证书）的机制。这些机制可以独立使用也可以组合在一起使用来提供许多种安全性模型和加密技术。
WS-Security 提供了一个通用机制用于把安全性令牌与消息关联起来。WS-Security 并不要求特定类型的安全性令牌。它被设计为可扩展的（例如，支持多种安全性令牌格式）。例如，一个请求者可能会提供身份证明和他们具有某个特定业务认证的证明。
提供消息完整性的方法是一起使用XML 签名和安全性令牌（它可能包含或暗示关键数据）以确保消息在传输过程中未被修改。完整性机制被设计为支持多个签名（可能是由多个参与者签署的），并可以扩展为支持额外的签名格式。签名可以引用（也就是指向）一个安全性令牌。
同样，提供消息机密性的方法是一起使用XML 加密和安全性令牌为 SOAP 消息的一部分保密。加密机制被设计为支持额外的加密技术、流程和多个参与者的操作。加密也可以引用一个安全性令牌。
最后，WS-Security 描述了编写二进制安全性令牌的机制。这个规范还特别描述了如何编写 X.509 证书和 Kerberos 票据以及如何包括进不透明加密的密钥。它还包含可用于进一步描述与消息包含在一起的安全性令牌的特征的可扩展性机制。
WS-Policy 将描述发送者和接收者如何指定他们的要求和能力。
WS-Policy 将是完全可扩展的，并将不会对可以描述的要求和能力的类型做什么限制；但是，该规范很可能识别几个基本的服务属性，包括隐私权属性、编码格式、安全性令牌要求和支持的算法。
这个规范将定义一个常规的 SOAP 策略格式，这种格式能支持的不仅仅是安全性策略。这个规范还将定义一个向 SOAP 消息附加服务策略的机制。
WS-Trust 将描述用于建立直接和代理信任关系（包括第三方和中介体）的模型。
这个规范将描述如何通过创建安全性令牌保证服务把现有的直接信任关系用作代理信任的基础。这些安全性令牌保证服务建立在 WS-Security 的基础上，用一种保证令牌的完整性和机密性的方式传送那些必需的安全性令牌。
然后这个规范将描述如何把几个现有的信任机制与这个信任模型一起使用。
最后，这个信任模型将明确允许，但不强求主体进行授权委托和模仿。注意，委托与模仿是一致的，但它提供额外级别的可跟踪性。
创建、管理和使用 Web 服务的组织将经常需要声明它们的隐私权策略，并要求进来的请求声明发送者是否遵守这些策略。
通过使用 WS-Policy、WS-Security 和 WS-Trust 的组合，组织可以声明并指出遵守声明的隐私权策略。这个规范将描述一个关于如何把隐私权语言嵌入到 WS-Policy 描述以及如何使用 WS-Security 把隐私权声明与消息关联起来的模型。最后，这个规范将描述如何使用 WS-Trust 机制同时为用户首选项和组织实践声明评价这些隐私权声明。
WS-SecureConversation 将描述 Web 服务如何认证请求者消息、请求者如何认证服务以及如何互相建立认证的安全性上下文。
这个规范将描述如何建立会话密钥、派生密钥和消息令牌（per-message）密钥。
最后，这个规范将描述服务如何安全地交换上下文（关于安全性属性和相关数据的声明的集合）。为完成这个工作，该规范将描述 WS-Security 和 WS-Trust 中定义的安全性令牌签发和交换机制概念，并以它们为基础。例如，使用这些机制，服务可以支持使用弱对称密钥技术的安全性令牌，还可以签发使用非共享（不对称）密钥的更强壮些的安全性令牌。
WS-SecureConversation 被设计为在 SOAP 消息层运作，这样消息就可以通过多种传送器和中介体传送。这并不排除在其它消息传递框架中使用它。为进一步增加系统的安全性，可以跨选中的多个链接把传输级安全性与 WS-Security 和 WS-SecureConversation 一起使用。
这个规范将定义如何使用 WS-Security、WS-Policy、WS-Trust 和 WS-SecureConversation 规范构建联合信任案例。例如，它将描述如何把 Kerberos 和 PKI 基础架构联合起来（如下面的案例所述）。
同时还引入一个信任策略来指出并限制和确定被代理的信任类型。
这个规范还将定义用于管理信任关系的机制。
这个规范将描述如何指定和管理 Web 服务的访问策略。它将特别描述如何在安全性令牌内指定声明，以及这些声明在端点处将如何被解释。
这个规范将被设计为在授权格式和授权语言上都是灵活且可扩展的。它使最大范围的案例成功并确保安全性框架能长期存在。




回页首
这个 Web 服务安全性模型与今天普遍使用的用于认证、数据完整性和数据机密性的现有安全性模型兼容。所以，它有可能将基于 Web 服务的解决方案与现有的其它安全性模型集成在一起：
传输安全性（Transport Security）― 现有技术，如安全套接字（SSL/TLS），可以为消息提供简单的点对点完整性和机密性。Web 服务安全性模型支持把这些现有的安全传输机制与 WS-Security（以及其它规范）一起使用来提供（特别是跨多个传送器、中介体和传输协议的）端到端完整性和机密性。
PKI― 高级 PKI 模型涉及到签发带公用对称密钥的证书的证书机构和声明除密钥所有权之外属性的机构（例如，属性机构）。这种证书的拥有者可以使用相关的密钥来表示多种声明（包括身份）。Web 服务安全性模型支持安全性令牌服务使用公用不对称密钥签发安全性令牌。这里使用的 PKI 意义最广，并不采用任何特殊的层次或模型。
Kerberos― Kerberos 模型依靠与密钥分发中心（Key Distribution Center，KDC）通信，通过签发加密的对称密钥 ― 这个密钥为双方都加了密，并将他们“介绍”给对方 ― 来代理各方之间的信任。又一次，Web 服务模型建立在核心模型之上，而安全性令牌服务通过签发带加密的对称密钥和加密的嘱托的安全性令牌来代理信任。
注意，尽管模型是兼容的，为确保互操作性，还需要在用于签名和加密的适配程序和／或通用算法上达成一致或者开发它们。
联合、授权（包括委托）、隐私权和信任的现有模型独特性有余，而通用性不足。这个策略的后面阶段将确定说明这些安全性属性的规范。
现有的信任模型通常都是基于企业间的协定。现有信任模型的一个示例是 UDDI Web 服务。在 UDDI 中，有好几个参与者，他们通过一致同意支持一组 API 来提供一个通用业务注册中心（Universal Business Registry）。UDDI 中的“信任模型”不是根据特定认证机制的要求为“信任”定义一个单独的模型，而是把认证的责任交给了节点，该节点是信息的管理员。也就是说，UDDI Web 服务的每个实现都有自己的认证机制并强制遵守自己的访问控制策略。“信任”是操作员之间的，也是请求者和管理它的信息的操作员之间的。




回页首
下面我们提供了许多案例，它们举例说明了在我们的想象中，提议的要使用的 Web 服务安全性规范是什么样的。这些案例的重点故意放在技术细节上来阐明整个安全性策略的能力。将有随附的文档提供详细的企业使用案例。
这里描述的示例公司、组织、产品、域名、电子邮件地址、徽标、人物、地点和事件纯属虚构。如关系到任何真实的公司、组织、产品、域名、电子邮件地址、徽标、任务、地点或事件纯属无意，请勿妄加推测。
下面的列表简要介绍了提议的初始规范和相关的可交付方案（deliverable）可以支持的一些案例：
使用用户名／密码和传输级安全性的直接信任― 这个案例演示使用用户名和密码以及传输安全性的认证。
使用安全性令牌的直接信任― 这个案例演示使用 X.509 证书和 Kerberos 服务票据（ST）的直接信任。
安全性令牌的获得― 这个案例演示使用独立于消息存储的安全性令牌进行的认证。
防火墙处理― 这个案例演示描述了防火墙如何利用这个安全性模型进行更高级的控制。
签发的安全性令牌― 这个案例演示基本的认证。
强制遵守业务策略― 这个案例演示如何使用安全性令牌签发把业务流程编成法令。
隐私权― 这个案例演示客户机和服务如何与它们的隐私权策略进行通信。
Web 客户机― 这个案例演示如何把 Web 浏览器用作客户机。
移动客户机― 这个案例演示移动客户机如何安全地与 Web 服务进行交互。
第二组案例更复杂。这些案例“可以”建立在当前可交付方案的基础上，但需要后继规范（象 WS-SecureConversation）来进行无缝的互操作。
启用联合― 这部分描述了几个涉及到联合信任的不同案例。
验证服务― 描述如何使用验证消息安全性的服务（例如，签名）。
支持委托― 这个案例演示如何使用安全性令牌进行委托。
访问控制― 这个案例演示 Web 服务安全性如何支持基于传统访问控制列表的安全性。
审核― 这个案例演示使用审核来跟踪与安全性有关的活动和事件。
注意，在下面的描述中，对术语请求者的使用被用于描述 Web 服务的许多种不同的潜在用户，并不意味着要限制请求者的特征。请求者可以包括在 B2B 环境中与服务进行交互的业务实体，或者通过浏览器或移动设备访问服务的个人。
在下图中，“蓝色”框代表服务，“浅蓝色”框代表安全性令牌和它们的身份及委托声明。
1 下面是一个非常基本的示例，展示 Web 服务安全性如何与现有的传输安全性机制一起使用：

请求者用安全传输（例如 SSL/TLS）打开了与 Web 服务的连接。它发送自己的请求并在请求中包含进一个包含其用户名和密码的安全性令牌。服务对这些信息进行认证，处理请求并返回结果。
在这个案例中，消息机密性和完整性是用现有的传输安全性机制处理的。
这个案例假设双方都已经使用了一些机制来建立共享的秘密 ― 请求者密码。但没有对双方之间的组织关系做什么假设。
2 这个案例演示如何使用 Web 服务直接信任的安全性令牌。这里的直接信任意思是 Web 服务知道并信任请求者的安全性令牌（或者它的签名机构）。这个案例假设双方都已经使用了一些机制来建立一种信任关系以便使用安全性令牌。这种信任可以手工建立，方法是配置应用程序或者使用安全的传输交换密钥。利用密钥的安全传输，我们暗示可以把一个传输（或者其它机制或流程），比如 SSL，作为一种方法来使用，被信任方用这种方法向接收方声明密钥或安全性令牌的有效性。但没有对双方之间的组织关系做什么假设。

请求者向服务发送消息，在消息中包含一个已签名安全性令牌并使用，例如签名，提供安全性令牌的所有权证明。服务检验该证明并评价安全性令牌。安全性令牌上的签名有效并被服务直接信任。服务处理该请求并返回一个结果。
直接信任假设涉及到的各方都透彻理解了隐私权策略。
3 有些情况下，使用的安全性令牌并不作为消息的一部分传送。而是提供一个安全性令牌引用，用它来定位并获得令牌。

请求者向服务发出一个请求，包含对安全性令牌的引用并提供所有权证明。Web 服务使用所提供的信息从令牌存储服务获取安全性令牌并验证证明。Web 服务信任（注意，这种信任是建立在消息语义之外的）这个安全性令牌，所以处理该请求并返回响应。
4 防火墙仍然是 Web 服务安全性体系架构的一个至关重要的组件 ― 它们必须能够继续强制执行边界处理规则。
如下所示，防火墙检验进来的 SOAP 消息并只允许来自“被授权”请求者的那些消息穿过防火墙。

在这个案例中，有两个向防火墙内的 Web 服务发送消息的请求者。防火墙检查消息以确定请求者是否已“被授权”可以向防火墙内的指定 Web 服务发送消息。
在这个案例中，防火墙通过检查用于对消息签名的安全性令牌做出了这样的决定。如果签名有效，并且信任安全性令牌的签名授权机构授权该消息进入防火墙，并且令牌说它的确授权该消息进入防火墙，那么就允许该消息进入防火墙；否则，就拒绝它。有些情况下，签名可以特指防火墙为 SOAP 参与者。
在其它案例中，防火墙还可以充当安全性令牌的签发机构，并且只允许包含防火墙签发的安全性令牌的所有权证明的消息。
5 下面是一个示例，显示 Web 服务安全性如何支持被信任一方进行的简单认证。

在头两步中，请求者与认证机构通信获得安全性令牌，特别是证明请求者身份的断言的已签名声明。
请求者得到了一个安全性令牌，因为 Web 服务有一个策略要求需要一个适当类型的安全性令牌（在这个例子中，是身份证明）。
请求者下一步是向 Web 服务发送一条消息并接收响应，安全性令牌和所有权证明都被附加到消息上（请考虑认证者或签名的挑战）。
注意，在上面的描述中，并没有详细描述身份认证服务的操作。为获得一个身份安全性令牌，请求者可以使用现有的安全性协议或者也可以利用 Web 服务安全性规范。
如果我们假设请求者使用的是 Web 服务安全性规范，那么系统的操作步骤如下：身份服务在策略中描述它的要求，然后请求者可以请求一个安全性令牌，还有它的身份证明。
注意，身份服务只是一个安全性令牌服务。而且，Web 服务的对称性考虑到了所有的 Web 服务，还封装了安全性令牌服务。
最后，注意 Web 服务可以代表请求者（从安全性令牌服务）获得安全性令牌并把它们返回给请求者以供后面的消息使用。
6 在许多业务流程中，都有一些必须强制遵守的特定策略。例如，一个服务可以要求消费者在特定的审计公司有一定的级别和名望。使用 Web 服务，可以将这许多策略自动编成法令并验证，从而简化整个过程。
请考虑下列示例：

Nicholas' Dealership 有一个用于与部件供应商交互的 Web 服务。但是，他们只希望与部件经过制造商认证的供应商做生意。
一个部件公司，Joshua's Parts 将去制造商那儿并出示（且证明）它们的身份安全性令牌（例如，来自所演示的安全性令牌服务的令牌）并请求一个来自制造商的安全性令牌，该令牌声明他们是经过认证的部件经销商（假设他们被认证过并且名声很好）。然后 Joshua's Parts 可以联系 Nicholas' Dealership 并提供（且证明）这两个安全性令牌。
如果 Nicholas' Dealership 已经把他们的业务策略编进了服务策略中，负责策略一致的担子就落到了部件公司（例如 Joshua's Parts）的头上。
服务策略还可以就制造商将允许存储什么信息来确保遵守隐私权策略指定一些限制。
7 隐私权包括一组范围广泛的关心的问题，需要在出现这个策略的每个规范中说明。
基本的隐私权问题可以通过在服务策略中提供隐私权声明解决。涉及到委托和授权的更复杂的案例将包含在特定于那些案例的规范中。
举例来说，一个人声明了一组“策略首选项”，它描述了这个人是不是允许日程服务根据个人信息进行处理。这个日程服务使用一组“隐私权实践规则”来决定对个人信息的使用和公开。日程服务通过把隐私权实践规则和隐私权首选项结合起来，确定是否允许所提议的使用或公开来做出决定。

8 请考虑一个示例，在这个示例中，我们让 Web 客户机与一个中间层 Web 应用程序通信，而这个应用程序反过来与另一个域内的 Web 服务安全地对话。这个中间层 Web 应用程序（它有 Web 服务意识）希望为 Web 客户机获得一个安全性令牌。

而且，这个案例假设安全性令牌使中间层应用程序能够在与服务谈话时充当客户机。
为使这个案例成功，Web 客户机的浏览器访问中间层应用程序并被重定向到一个相关的身份服务。一旦经过认证（例如使用 HTML 表单和 https），请求就被重定向回中间层应用程序。身份服务向初始的中间层应用程序 Web 服务器提供一个安全性令牌（表明身份和委托）―　例如使用经 HTTPS 发送的查询字符串。现在这个 Web 服务器就可以使用这些安全性令牌并可以以它自己的身份向 Web 服务签发请求。Web 服务处理该请求并将结果返回到 Web 服务器，在这个服务器中结果被格式化并被返回到浏览器。
这个文档中前面描述的规范在解决移动安全性的独特设计问题时提供了足够的灵活性。Web 服务方法的灵活性使得它可以支持多种加密技术，这些技术为计算和存储功能有限的设备提供强大的和有一定性能的加密保护。同样，它还使网络操作员能够提供安全性代理（比如网络网关）来充当移动客户机。
下面是一个把这两种思想结合在一起的示例。当网络操作员支持移动客户机（使用这些 Web 服务安全性规范）时，它们可以配置那些客户机来通过网络操作员的网关发送请求。在这个案例中，网关是一个积极参与整个消息流的 SOAP 中介体；网络操作员还特别提供专为移动设备设计的一个增值（value-add）加密算法。网关可以增加或更改安全性令牌以及消息的保护质量。注意，这个 Web 服务安全性模型固有的灵活性允许这个解决方案，甚至当设备在外部网上漫游时也允许。
下面的示例演示了这一点：

9 Web 服务安全性模型被设计为支持联合。下面是身份联合的一个简单示例：
Adventure456 处的 Alice 想使用 Business456 处的 Currency Web 服务。该 Currency 服务将只处理带有 Business456 签发的安全性令牌的请求。Alice 只有一个 Adventure456 签发的带身份声明的安全性令牌（也即，一个身份安全性令牌）。
在这个案例中，如果 Business456 愿意接受与 Adventure456 的安全性联合，Alice 将只能够访问 Currency 服务。
下面的几个分段描述了进行安全性联合的几种方法。
使用安全性令牌交换的联合
在这种方法中，Currency 服务的策略声明它只接受 Business456 签发的安全性令牌。因为这个策略指出了可以从哪里获得必需的安全性令牌，所以 Alice 向 Business456 安全性令牌服务出示（且证明）她的 Adventure456 安全性令牌并接收到一个 Business456 安全性令牌。然后她在向 Currency 服务发出的请求中出示（且证明）这个安全性令牌。下图演示了这个过程：

在这种方法中，Business456 安全性令牌服务被配置为接受 Adventure456 签发的带身份声明的安全性令牌。
应该注意，这个示例与强制遵守业务策略案例中的示例非常相似。这个示例演示了 web 服务安全性模型的灵活性。
使用信任链的联合
在这种方法中，Currency 服务将接受带任何安全性令牌的请求，但它不处理请求，除非它可以获得基于提供的安全性令牌（和证明）的 Business456 安全性令牌。
为做到这一点，Currency 服务将初始请求转发给评价初始安全性令牌的 Business456 安全性令牌服务。如果该令牌有效，它认可该请求，并且可以为 Alice 包括进一个 Business456 安全性令牌以供后面的请求使用。下图演示了这个过程。

在这种方法中，Business456 安全性令牌服务被配置为接受 Adventure456 签发的带身份声明的安全性令牌。
使用安全性令牌交换的联合（PKI -> Kerberos）
在这种方法中，Adventure456 已向 Alice 签发了一个公用密钥安全性令牌，并且 Currency 服务的策略指出它只接受来自它的 KDC 的 Kerberos 安全性令牌。
按照 Currency 服务的策略的指示，Alice 向 Business456 的安全性令牌服务出示（且证明）她的公用密钥安全性令牌。这个安全性令牌服务封装了 Business456 的 KDC。结果，它能够验证 Alice 的公用密钥安全性令牌并签发了一个用于 Currency 服务的 Kerberos 安全性令牌。下图中演示了这个过程。

在这种方法中，Business456 安全性令牌服务被配置为接受 Adventure456 签发的带身份声明的公用密钥安全性令牌。
使用安全性令牌交换（Kerberos -> 安全性令牌服务）的联合
在这种方法中，Adventure456 已向 Alice 签发了一个 Kerberos 安全性令牌，并且 Currency 服务的策略指出它只接受它自己的安全性令牌服务签发的安全性令牌。
这里我们假设 Adventure456 和 Business456 的管理员们为联合安全性已经交换了公用密钥证书。我们进一步假设 Alice 只支持对称密钥技术。
根据 Currency Web 服务的策略，Alice 需要获得一个可用于访问 Business456 处的安全性令牌服务的安全性令牌。因为 Alice 使用的是对称密钥安全性令牌，Alice 首先联系她的安全性令牌服务以获取为 Business456 安全性令牌服务准备的安全性令牌。注意，这个安全性令牌将包含一个与 Business456 安全性令牌服务的公用密钥编码在一起的对称密钥，Sab。
使用为 Business456 安全性令牌服务准备的安全性令牌，Alice 请求一个用于 Currency 服务的安全性令牌。Business456 安全性令牌服务向 Alice 提供了一个对称密钥 Sac 和一个用于 Currency 服务的安全性令牌。
使用为 Currency 服务准备的安全性令牌和相关的对称密钥，Alice 向 Currency 服务发送了一个请求。

使用凭证交换（Kerberos -> Kerberos）的联合
在这种方法中，Adventure456 已经向 Alice 签发了一个 Kerberos 安全性令牌，并且 Currency 服务的策略声明它只接受封装它的 KDC 的它自己的安全性令牌服务签发的 Kerberos 安全性令牌。
这里，我们假设 Adventure456 和 Business456 处的管理员不想建立跨域的传输信任，但为了联合安全性，想交换公用密钥证书。我们进一步假设 Alice 和 Currency 服务都只支持对称密钥技术。
就象前面的示例中那样，安全性令牌服务有能力向它们信任域内的服务提供对称密钥安全性令牌。所以，上面描述的这种方法在这个案例中是可行的。

10 这个 Web 服务安全性模型还支持这样的案例，在这个案例中，请求者 外包（outsource）处理消息和安全性令牌验证。应该注意误用这种服务会导致可伸缩性问题。也就是说，根据实现，服务执行验证服务的代价可能更便宜，也可能更昂贵。Web 服务安全性模型支持其中一种方法，因此可以使该案例成功。
在这个案例中，我们已经将验证服务与安全性令牌服务分开了。在其它案例中，它们可以组合在一起或者具有直接信任关系（因此不需要 WS-Federation）。

在这个案例中，请求者从安全性令牌服务获得了一个安全性令牌。然后它将消息发送给 Web 服务并在消息中包括了所有权证明（例如，一个签名）。Web 服务发送签名块、安全性令牌和计算出的已签名的摘要给验证服务。然后，Web 服务信任的这个验证服务发出一个有效／无效决定。
应该注意，验证服务可以通过签发一个代表声称正确声明的请求者的安全性令牌来表明它的决定。
11 Web 服务安全性支持委托。下面是用来显示这种方法的灵活性的一个复杂的委托案例：Alice 使用 calendar456 管理她的日程。她希望允许 Bob 在周二为她安排一次会议。但是，Bob 并不直接安排时间。Bob 而是使用服务 schedule456 来安排需要放在 Alice 日程上的会议。
Alice 并不知道 Bob 将如何安排会议的日程，但她希望限制可以看到她的日程的一组服务。

Alice 向 Bob 提供了一个安全性令牌，这个令牌使 Bob 能够根据她的日程安排会议。这个安全性令牌包含限制 Bob 将会议安排到周二的声明。而且，只要主题（一个或多个）能够证明它们有一个来自 TrustUs456（一个第三方服务）的隐私权证明，这个安全性令牌就会使 Bob 能够签发后继的安全性令牌。
既然服务 schedule456 已经被 TrustUs456 审核过了，那么它们就有了一个声明它们的隐私权证明的安全性令牌。
当日程服务在 calendar456 处访问 Alice 的日程时，它可以验证它的隐私权证明的所有权证明及其访问声明，并根据来自 Alice，通过 Bob，到达它自身的安全性令牌安排会议日程。
在一起工作时，Alice 和 Bob 发现他们经常要互相协商会议的时间并建立一种信任级别。因此，Alice 希望允许 Bob 安排会议时间而不必每次都委托他。她可以增加委托安全性令牌的期限，但需要重新签发那些令牌，如果她想废除 Bob 安排会议日程的能力，这就会比较麻烦。

Alice 与她的日程服务通信（认证她自己）获得授权列表。她更新授权列表来允许 Bob 查看她的闲／忙数据、安排会议并将数据提交给服务。现在，当 Bob 为这些操作访问她的日程服务时，他不需要来自 Alice 的委托安全性令牌。
12 在上面的委托案例中，有可能一个敌人尝试不用委托安全性令牌安排会议或者使用一个过期的安全性令牌安排会议。在这种情况下请求将失败，因为敌人无法证明所需的声明。
为跟踪这种类型的活动，服务可以提供审核功能。也即，当发生与安全性有关的事件，比如认证或者未证明的声明或者错误的签名时，就记录下来。管理员可以安全地访问日志来检查与安全性相关的事件并管理日志。
例如，敌人可能会努力假扮 Bob。使用监视器／管理工具，安全性管理员 Carol 查看审核日志时看到 Alice 的日程已经有了许多安全性失败记录。在查看数据时，她看到有时 Bob 的请求失败是因为他的签名与消息（一条或多条）不匹配，消息是旧的（被重用的）。于是 Carol 便收集审核记录以用于追查这些敌人。





回页首
随着 Web 服务的应用日益广泛，随着应用程序拓扑继续发展到支持防火墙、负载平衡器和消息传递中心之类的中介体并且人们对组织所面临的威胁理解得更加深刻，对 Web 服务的增加的安全性规范的需要就变得更加明了。在这个文档中，我们提议了一个集成的 Web 服务安全性模型和一组用于实现该模型的规范。通过扩展和利用（而不是代替）现有的安全性技术和资产，这些新规范将使客户和组织能够更快速地开发安全的、互操作的 Web 服务。
IBM 和 Microsoft 相信这是定义一个全面的 Web 服务安全性策略的第一步。它将反映我们迄今为止已经确定的问题和解决方案。由于我们将继续与客户、伙伴以及标准组织合作来保护 Web 服务，我们希望会有使这个策略更加全面所需的其它思想和规范。




回页首
这篇文档是由 IBM 和 Microsoft 合写的。
主要的供稿者包括（按字母顺序排列）：Giovanni Della-Libera，Microsoft；Brendan Dixon，Microsoft；Joel Farrell，IBM；Praerit Garg，Microsoft；Maryann Hondo，IBM；Chris Kaler，Microsoft；Butler Lampson，Microsoft；Kelvin Lawrence，IBM；Andrew Layman，Microsoft；Paul Leach，Microsoft；John Manferdelli，Microsoft；Hiroshi Maruyama，IBM；Anthony Nadalin，IBM；Nataraj Nagaratnam，IBM；Rick Rashid，Microsoft；John Shewchuk，Microsoft；Dan Simon，Microsoft；Ajamu Wesley，IBM
脚注
参考资料
您可以参阅本文在 developerWorks 全球站点上的英文原文.
请单击文章顶部或底部的 讨论参与本文的讨论论坛。
[Kerberos] ― J. Kohl 和 C. Neuman，“The Kerberos Network Authentication Service (V5)”，RFC 1510，1993 年 9 月。
[SOAP] ― W3C 注解，“SOAP: Simple Object Access Protocol 1.1”，2000 年 5 月 8 日。
[URI] ― T. Berners-Lee、R. Fielding 和 L. Masinter，“Uniform Resource Identifiers (URI): Generic Syntax”，RFC 2396，MIT/LCS，U.C. Irvine，Xerox Corporation，1998 年 8 月。
[XML-C14N] ― W3C 推荐，“Canonical XML Version 1.0”，2001 年 3 月 15 日。
[XML-Encrypt] ― W3C 工作草案，“XML Encryption Syntax and Processing”，2002 年 3 月 4 日。
[XML-ns] ― W3C 推荐，“Namespaces in XML”，1999 年 1 月 14 日。
[XML-Schema1] ― W3C 推荐，“XML Schema Part 1: Structures”，2001 年 5 月 2 日。
[XML-Schema2] ― W3C 推荐，“XML Schema Part 2: Datatypes”，2001 5 月 2 日。
[XML Signature] ― W3C 提议的推荐，“XML Signature Syntax and Processing”，2001 年 8 月 20 日。
[WS-Routing] ― H. Nielsen、S. Thatte，“Web Services Routing Protocol”，Microsoft，2001 年 10 月
[X509] ― S. Santesson 等人，“Internet X.509 Public Key Infrastructure Qualified Certificates Profile”，2000 年 3 月