通过

Web 服务世界中的安全性：建议的体系结构和路线图

 

2002 年 4 月 7 日
版本 1.0

© 2001-2002 国际商务机器公司。 保留所有权利。

这是一份初步文件，可能会随着时间的推移而发生重大更改。 本文档中包含的信息代表国际商务机和Microsoft公司关于截至发布日期讨论的问题的当前视图。 由于 IBM 和Microsoft必须应对不断变化的市场状况，因此不应解释为 IBM 和Microsoft的承诺，IBM 和Microsoft不能保证发布日期后提供的任何信息的准确性。

本文档中包含的信息的呈现、分发或其他传播不是 IBM 拥有或控制的任何知识产权的许可，或者由 IBM 或Microsoft和\或其他任何第三方拥有或隐含的许可。 IBM、Microsoft和\或任何其他第三方可能拥有涉及本文档主题的专利、专利申请、商标、版权或其他知识产权。 本文档的提供不会向你授予 IBM 或Microsoft或任何其他第三方专利、商标、版权或其他知识产权的任何许可。 此处描述的示例公司、组织、产品、域名、电子邮件地址、徽标、人员、地点和事件都是虚构的。 与任何真正的公司、组织、产品、域名、电子邮件地址、徽标、人员、地点或事件没有关联，也不应推断。

本文档和本文中包含的信息以“AS IS”提供，在适用法律允许的最大范围内，IBM 和Microsoft提供文档 AS IS AND WITH ALL FAULTS，因此不公开、默示或法定的所有其他保证和条件，包括但不限于任何（如果有）默示担保， 适销性、针对特定用途的适用性、响应的准确性或完整性、结果、工作工作、缺乏病毒和缺乏疏忽等工作职责或条件，都涉及文件。 此外，没有关于文件的任何知识产权的说明或 NON-INFRINGEMENT 的担保或条件，没有保证或条件，安静享受，安静拥有，安静拥有。

任何情况下，IBM 或MICROSOFT对于购买替代商品或服务、利润损失、使用损失、数据丢失或任何附带的、后果性的、间接的或特殊损害，无论根据合同、侵权、担保或其他任何原因，无论根据合同、侵权、担保或其他任何原因，都不应承担任何费用，否则，与本文档相关的任何其他协议都无效， 此类当事人是否事先通知了此类损害的可能性。

抽象

本文档介绍用于解决 Web 服务环境中安全性的建议策略。 它定义了一个全面的 Web 服务安全模型，该模型支持、集成和统一多个常用的安全模型、机制和技术（包括对称和公钥技术），使各种系统能够以平台和语言中立的方式安全地互操作。 它还介绍了一组规范和方案，这些规范说明了这些规范如何一起使用。

摘要

IT 行业一直在谈论 Web 服务近两年。 在试点计划和大规模生产中使用 Web 服务时，在组织内部、跨企业和 Internet 之间链接应用程序时，松散耦合、无语言、独立于平台的方式链接应用程序的好处越来越明显。 今后，我们的客户、行业分析师和新闻界确定了一个关键领域，随着 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 加密和 SSL/TLS 等基础技术构建。 这样，Web 服务提供商和请求者就可以开发满足其应用程序的个人安全要求的解决方案。

IBM 和Microsoft打算与客户、合作伙伴和标准机构合作，以分阶段方法改进此安全模型。 我们正在为这项工作设定 WS-Security 规范。 WS-Security 定义了保护消息完整性和机密性的核心设施，以及将安全相关声明与消息关联的机制。 虽然 WS-Security 是这一努力的基石，但它只是一个开始，我们将与行业合作，产生额外的规范，以处理政策、信任和隐私问题。

为了尽可能具体地讨论本文档中讨论的问题和解决方案，我们讨论了反映 Web 服务的当前和预期应用程序的多个方案。 其中包括防火墙处理、隐私、浏览器和移动客户端的使用、访问控制、委派和审核。

我们预计会担心可以做些什么来确保各种建议规范的互操作性和一致的实现。 为解决此问题，IBM 和Microsoft将与标准组织、开发人员社区和行业组织（如 WS-I.org）密切合作，开发互操作性配置文件和测试，为工具供应商提供指导。

本文档概述了一个全面的模块化解决方案，在实施时，客户能够构建可互操作且安全的 Web 服务，这些服务利用并扩展了对安全基础结构的现有投资，同时允许他们充分利用 Web 服务技术所提供的集成和互操作性优势。

1 简介和动机

为 Web 服务提供全面的安全功能和组件模型需要将当前可用的流程和技术与未来应用程序不断演变的安全要求集成。 它要求统一概念：它需要解决技术（安全消息传送）和业务流程（策略、风险、信任）问题：最后，它需要平台供应商、应用程序开发人员、网络和基础结构提供商以及客户协调工作。

统一可用的安全技术范围意味着应用程序安全性的功能要求必须从使用的特定机制中抽象化。 例如，无论客户使用的是手机还是笔记本电脑，都不应影响进行在线购买的客户，只要每台设备都能安全地表达正确的标识。

目标是使客户能够使用异类系统轻松构建可互操作的解决方案。 例如，本文档稍后提出的安全消息传送模型支持公钥基础结构（PKI）和 Kerberos 标识机制作为更通用设施的特定体现，并且能够扩展以支持其他安全机制。 通过单个安全模型的抽象集成，组织可以使用其在安全技术方面的现有投资，同时使用不同技术与组织通信。

此外，随着使用不同标识机制的组织使用 Web 服务进行协作，安全信任模型提供了一个灵活的框架，组织可以在其中使用适当的授权进行互连。

同时，每个客户和每个 Web 服务都有自己的独特的安全要求，具体取决于其特定的业务需求和运营环境。 例如，在工作组设置中，简单易操作是首要问题，而对于公共 Internet 应用程序来说，能够抵御协同拒绝服务攻击是一个更高的优先级。 由于这些要求可以通过多种方式组合在一起，并且以不同的特定级别表示，因此 Web 服务安全性的成功方法需要一组灵活的可互操作安全基元，通过策略和配置启用各种安全解决方案。

为了应对这些挑战，本文档提出了一种进化方法，基于一组统一以前不同技术的安全抽象来创建安全互操作的 Web 服务。 这样就可以在整体框架中对特定的客户要求进行专用化，同时允许技术随时间推移而发展并逐步部署。

作为这种进化方法的一个示例，可以将安全消息传送模型添加到现有的传输级安全解决方案中。 客户可以将消息级完整性或持久性机密性（消息元素加密）添加到其消息通过的现有 Web 服务，例如安全套接字层（SSL/TLS）。 这些消息现在具有在传输层之外保持的完整性（或机密性）。

我们预计出现的建议的模型和规范将广泛从多个供应商获得，并将由适当的标准组织考虑。 模型、规范和标准流程使企业能够快速且经济高效地提高现有应用程序的安全性，并自信地开发新的可互操作、安全的 Web 服务。

这种模式的业务优势是明确的。 通过为 Web 服务构建全面的安全体系结构，可以更好地确保其投资和资产在业务流程随着 Web 服务日益重新播发时受到保护。

Web 服务安全模型术语

由于术语因技术而异，本文档定义了多个术语，这些术语可以一致地应用于不同的安全格式和机制。 因此，此处使用的术语可能与其他规范不同，并且已定义，以便读者可以将术语映射到其首选词汇。

  • Web 服务— 术语“Web 服务”适用于各种基于网络的应用程序拓扑。 本文档使用术语“Web 服务”来描述其功能和接口通过应用现有和新兴 Web 技术标准（包括 XML、SOAP、WSDL 和 HTTP）向潜在用户公开的应用程序组件。 与网站相比，基于浏览器的交互或依赖于平台的技术，Web 服务是通过定义的格式和协议以独立于平台和语言中立的方式提供计算机到计算机的服务。

  • 安全令牌— 我们将安全令牌定义为安全相关信息（例如 X.509 证书、Kerberos 票证和验证器、SIM 卡、用户名等的移动设备安全令牌）的表示形式。

    下图显示了一些不同类型的安全令牌。

  • 签名的安全令牌— 我们将 签名的安全令牌 定义为一个安全令牌，其中包含颁发者以加密方式认可的一组相关声明（断言）。 签名的安全令牌示例包括 X.509 证书和 Kerberos 票证。

  • 声明— 声明是由主题或与声明关联的另一方关于主题的声明。 一个重要点是，此规范不会尝试限制可发出的声明类型，也不会尝试限制这些声明的表达方式。 声明可以是可用于对消息进行签名或加密的密钥。 声明可以是安全令牌传达的语句。 例如，声明可用于断言发件人标识或授权角色。

  • 使用者— 安全令牌的主题是主体（例如人员、应用程序或业务实体），安全令牌中表示的声明适用。 具体而言，使用者，因为安全令牌的所有者拥有证明安全令牌所有权所需的信息。

  • 所有权证明— 我们定义了 所有权证明，用于证明安全令牌或声明集的所有权。 例如，所有权证明可能是与包含公钥的安全令牌关联的私钥。

  • Web 服务终结点策略— Web 服务在指定它们所需的声明以处理消息方面具有完全的灵活性。 我们将这些必需的声明和相关信息统称为“Web 服务终结点策略”。 终结点策略可以用 XML 表示，可用于指示与身份验证相关的要求（例如用户或组标识证明）、授权（例如某些执行功能证明）或其他自定义要求。

  • 声明要求— 声明要求可以绑定到整个邮件或邮件元素、给定类型的所有操作或仅在某些情况下的操作。 例如，服务可能要求请求者证明购买金额大于规定限制的授权。

  • 中介— 由于 SOAP 消息从初始请求者发送到服务，因此它们可由执行操作（例如路由消息，甚至修改消息）的中介操作。 例如，中介可以添加标头、加密或解密消息片段，或添加其他安全令牌。 在这种情况下，应小心谨慎，使对消息的更改不会使消息完整性失效、违反信任模型或销毁责任。

  • 执行组件— 执行组件 是中间或终结点（如 SOAP 规范中定义），由 URI 标识，处理 SOAP 消息。 请注意，用户和客户端软件（例如浏览器）都不是执行组件。

Web 服务安全模型原则

可以通过将 SOAP 消息发送到 URI 标识的服务终结点、请求特定操作以及接收 SOAP 消息响应（包括错误指示）来访问 Web 服务。 在此上下文中，保护 Web 服务的广泛目标闯入了为确保消息的完整性和机密性提供设施的附属目标，并确保该服务仅针对表达策略所需声明的消息中的请求。

如今，安全套接字层（SSL） 以及事实上的传输层安全性（TLS）用于为 Web 服务应用程序提供传输级别安全性。 SSL/TLS 提供了多种安全功能，包括身份验证、数据完整性和数据机密性。 SSL/TLS 支持点到点安全会话。

IPSec 是传输安全性的另一个网络层标准，对于 Web 服务来说可能变得很重要。 与 SSL/TLS 一样，IPSec 还提供具有主机身份验证、数据完整性和数据机密性的安全会话。

当今的 Web 服务应用程序拓扑包括移动设备、网关、代理、负载均衡器、非军事区域（DMZ）、外包数据中心以及全球分布式动态配置的系统的广泛组合。 所有这些系统都依赖于消息处理中介转发消息的能力。 具体而言，SOAP 消息模型在抽象物理网络和应用程序基础结构的逻辑终结点上运行，因此经常将多跃点拓扑与中间执行组件合并。

当数据被传输层以外的中介接收和转发时，数据的完整性和随传输层一起流动的任何安全信息都可能丢失。 这强制任何上游消息处理器依赖于先前中介所做的安全评估，并完全信任其处理消息内容。 综合 Web 服务安全体系结构中需要提供端到端安全性的机制。 成功的 Web 服务安全解决方案将能够利用传输和应用程序层安全机制来提供全面的安全功能套件。

点到点配置

端到端配置

此处所述的 Web 服务安全模型使我们能够通过以下过程实现这些目标：

  • Web 服务可以要求传入消息证明一组 声明（例如名称、密钥、权限、功能等）。 如果消息到达时没有所需的声明，服务可能会忽略或拒绝该消息。 我们将所需声明和相关信息集称为 策略。
  • 请求者可以通过将 安全令牌 与消息相关联来发送具有所需声明证明的消息。 因此，消息都要求执行特定操作，并证明其发件人有权要求该操作。
  • 当请求者没有所需的声明时，请求者或其代表某人可以通过联系其他 Web 服务来尝试获取必要的声明。 这些其他 Web 服务（我们称为 安全令牌服务）可能反过来需要自己的声明集。 通过颁发安全令牌来代理不同信任域之间的安全令牌服务代理信任。

下图演示了此模型，其中显示了任何请求者也可能是服务，安全令牌服务也可能完全是 Web 服务，包括表示策略和要求安全令牌。

此常规消息传送模型（声明、策略和安全令牌）对多个更具体的模型（例如基于标识的安全性、访问控制列表和基于功能的安全性）进行了子分类和支持。 它允许使用现有技术，例如 X.509 公钥证书、Kerberos 共享机密票证甚至密码摘要。 如稍后我们将讨论的那样，它还提供集成抽象，使系统能够在不同的安全技术之间建立桥梁。 常规模型足以构建更高级别的密钥交换、身份验证、授权、审核和信任机制。

2 个 Web 服务安全规范

此处表达的安全策略和下面介绍的 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 服务和请求者如何声明隐私首选项和组织隐私实践声明的模型。

Follow-On 规范

  • WS-SecureConversation：介绍如何管理和验证双方之间的消息交换，包括安全上下文交换和建立和派生会话密钥。
  • WS 联合身份验证：介绍如何在异类联合环境中管理和代理信任关系，包括对联合标识的支持。
  • WS-Authorization：介绍如何管理授权数据和授权策略。

为 WS-Security 提供安全性需要对许多功能区域中的说明、规范和配置文件的生产进行尽职尽责。 这些文档将通过一个过程来改变和演变，在完成规范过程时，将平衡客户需求与 Web 服务开发社区的需求和我们自己的教育过程。

WS-Security

WS-Security 介绍了 SOAP 消息传送的增强功能，通过消息完整性和消息保密性提供 保护质量。 此规范还定义了如何在 SOAP 消息中附加和包含安全令牌。 最后，提供了一种机制来指定二进制编码的安全令牌（例如 X.509 证书）。 这些机制可以独立使用或组合使用，以适应各种安全模型和加密技术。

WS-Security 提供了一种通用机制，用于将安全令牌与消息相关联。 WS-Security不需要特定类型的安全令牌。 它设计为可扩展（例如支持多种安全令牌格式）。 例如，请求者可能提供身份证明，并证明他们具有特定的业务认证。

通过利用 XML 签名 与安全令牌（可能包含或暗示密钥数据）结合使用来提供消息完整性，以确保在未经修改的情况下传输消息。 完整性机制旨在支持多个签名（可能由多个执行组件提供）并可扩展以支持其他签名格式。 签名可以引用安全令牌（即指向）。

同样，通过利用 XML 加密 与安全令牌结合使用来保护部分 SOAP 消息的机密性，从而提供消息保密性。 加密机制旨在支持多个参与者的其他加密技术、流程和操作。 加密还可以引用安全令牌。

最后，WS-Security 描述了编码二进制安全令牌的机制。 具体而言，该规范介绍了如何对 X.509 证书和 Kerberos 票证进行编码，以及如何包括不透明的加密密钥。 它还包括可用于进一步描述消息中包含的安全令牌的特征的扩展机制。

WS-Policy

WS-Policy 将描述发送方和接收方如何指定其要求和功能。

WS-Policy 将完全可扩展，并且不会对可能描述的要求和功能类型施加限制;但是，规范可能会识别多个基本服务属性，包括隐私属性、编码格式、安全令牌要求和支持的算法。

此规范将定义通用 SOAP 策略格式，该格式不仅支持安全策略。 此规范还将定义用于附加或关联服务策略与 SOAP 消息的机制。

WS-Trust

WS-Trust 将描述建立直接信任关系和中转信任关系的模型（包括第三方和中介）。

此规范将描述如何通过创建安全令牌颁发服务将现有直接信任关系用作代理信任的基础。 这些安全令牌颁发服务基于 WS-Security 来传输必要的安全令牌，以确保这些令牌的完整性和机密性。

然后，此规范将描述如何将多个现有信任机制与此信任模型结合使用。

最后，信任模型将显式允许，但不会授权、委派和模拟主体。 请注意，委派与模拟一致，但提供附加级别的可跟踪性。

WS-Privacy

创建、管理和使用 Web 服务的组织通常需要声明其隐私策略，并要求传入的请求发出有关发件人遵守这些策略的声明。

通过使用 WS 策略、WS-Security和 WS-Trust 的组合，组织可以声明并指示符合规定的隐私策略。 此规范将描述隐私语言如何嵌入到 WS-Policy 说明中的模型，以及如何使用 WS-Security 将隐私声明与消息相关联。 最后，此规范将介绍如何使用 WS-Trust 机制来评估这些隐私声明，以便用户首选项和组织实践声明。

WS-SecureConversation

WS-SecureConversation 将描述 Web 服务如何对请求者消息进行身份验证、请求者如何对服务进行身份验证以及如何建立相互身份验证的安全上下文。

此规范将介绍如何建立会话密钥、派生密钥和每条消息密钥。

最后，此规范将描述服务如何安全地交换上下文（有关安全属性和相关数据的声明集合）。 为了实现这一点，该规范将介绍并基于 WS-Security 和 WS-Trust 中定义的安全令牌颁发和交换机制的概念。 例如，使用这些机制，服务可能支持使用弱对称密钥技术的安全令牌，以及使用非共享（非对称）密钥颁发更强大的安全令牌。

WS-SecureConversation 旨在对 SOAP 消息层进行操作，以便消息可以遍历各种传输和中介。 这不会排除在其他消息传送框架中使用。 为了进一步提高系统的安全性，传输级别安全性可以与 WS-Security 和跨所选链接 WS-SecureConversation 结合使用。

WS-Federation

此规范将定义如何使用 WS-Security、WS-Policy、WS-Trust 和 WS-SecureConversation 规范构造联合信任方案。 例如，它将描述如何联合 Kerberos 和 PKI 基础结构（如以下方案所述）。

同时，还引入了信任策略来指示和约束和标识正在中转的信任类型。

此规范还将定义用于管理信任关系的机制。

WS-Authorization

此规范将描述如何指定和管理 Web 服务的访问策略。 具体而言，它将描述如何在安全令牌中指定声明以及如何在终结点解释这些声明。

此规范旨在灵活且可扩展的授权格式和授权语言。 这可实现范围最广泛的方案，并确保安全框架的长期可行性。

3 将 Web 服务安全性与当今的安全模型关联

此 Web 服务安全模型与现有的安全模型兼容，用于身份验证、数据完整性和数据机密性，目前常用。 因此，可以将基于 Web 服务的解决方案与其他现有安全模型集成：

  • 传输安全— 安全套接字（SSL/TLS）等现有技术可以为消息提供简单的点到点完整性和机密性。 Web 服务安全模型支持将这些现有的安全传输机制与 WS-Security（和其他规范）结合使用，以在多个传输、中介和传输协议之间提供端到端完整性和机密性。
  • PKI— 在高级别上，PKI 模型涉及证书颁发机构颁发具有公共非对称密钥的证书，以及声明密钥所有权以外的属性（例如属性颁发机构）的证书颁发机构。 此类证书的所有者可以使用关联的密钥来表达各种声明，包括标识。 Web 服务安全模型支持使用公共非对称密钥颁发安全令牌的安全令牌服务。 PKI 从最宽泛意义上使用，不假定任何特定的层次结构或模型。
  • Kerberos— Kerberos 模型依靠与密钥分发中心（KDC）的通信来代理双方之间的信任，方法是为双方颁发加密的对称密钥，并相互“引入” 它们。 Web 服务模型再次构建在具有安全令牌服务中转信任的核心模型的基础上，通过颁发具有加密对称密钥和加密证明的安全令牌。

请注意，虽然模型兼容，但为了确保签名和加密的互操作性、适配器和/或常见算法需要得到同意或开发。

联合身份验证、授权（包括委派）的现有模型、隐私和信任不太常见，而且更临时。 用于解决这些安全属性的规范在策略的后续阶段进行标识。

现有信任模型通常基于业务协议。 下面是 UDDI Web 服务的示例。 在 UDDI 中，有几个参与者通过协议提供通用业务注册表来支持一组 API。 UDDI 中的“信任模型”不是通过特定身份验证机制的要求为“信任”定义单个模型，而是向节点（即信息的保管人）负责身份验证。 也就是说，UDDI Web 服务的每个实现都有自己的身份验证机制，并强制实施自己的访问控制策略。 “信任”位于操作员之间，以及请求者与其信息保管人之间的“信任”。

4 种方案

下面提供了一些方案，这些方案演示了我们如何设想正在使用的 Web 服务安全规范。 这些方案有意专注于技术细节，以说明整体安全策略的功能。 将提供详细的业务使用场景的配套文档。

此处描述的示例公司、组织、产品、域名、电子邮件地址、徽标、人员、地点和事件都是虚构的。与任何真正的公司、组织、产品、域名、电子邮件地址、徽标、人员、地点或事件没有关联，也不应推断。

以下列表简要介绍了建议的初始规范和关联的可交付结果支持的一些方案：

  • 使用用户名/密码和 Transport-Level 安全性的直接信任 — 此方案演示了使用具有传输安全性的用户名和密码进行身份验证。
  • 使用安全令牌的直接信任 — 此方案演示了使用 X.509 认证和 Kerberos 服务票证（ST）的直接信任。
  • 安全令牌获取 - 此方案演示了使用独立于消息存储的安全令牌进行身份验证。
  • 防火墙处理 - 此方案说明了防火墙如何利用此安全模型进行更大的控制。
  • 颁发的安全令牌 - 此方案演示了基本身份验证。
  • 强制实施业务策略 - 此方案演示如何使用安全令牌颁发来编码业务流程。
  • 隐私 - 此方案说明了客户端和服务如何传达其隐私策略。
  • Web 客户端 - 此方案演示了将 Web 浏览器用作客户端。
  • 移动客户端 - 此方案说明了移动客户端如何安全地与 Web 服务交互。

第二组方案更为复杂。 这些方案可以基于当前的可交付结果构建，但需要后续规范（如 WS-SecureConversation），使互操作性无缝。

  • 启用联合身份验证 - 本部分介绍涉及联合信任的几种不同方案。
  • 验证服务：介绍如何使用验证消息安全性的服务（例如签名）。
  • 支持委派 - 这说明了如何使用安全令牌进行委派。
  • 访问控制 - 这说明了 Web 服务安全性如何支持传统的基于访问控制列表的安全性。
  • 审核 - 这说明了如何使用审核来跟踪与安全相关的活动和事件。

请注意，在下面的说明中，使用术语请求者来描述 Web 服务的各种潜在用户，并不打算限制请求者的特征。 请求者可以包括与 B2B 环境中的服务交互的业务实体，或者从浏览器或移动设备访问服务的个人。

使用用户名/密码和 Transport-Level 安全性的直接信任

下面是一个非常基本的示例，演示如何将 Web 服务安全性与现有传输安全机制一起使用：

请求者使用安全传输（例如 SSL/TLS）打开与 Web 服务的连接。 它发送其请求，并包含包含其用户名和密码的安全令牌。 该服务对信息进行身份验证、处理请求并返回结果。

在此方案中，使用现有的传输安全机制处理消息保密性和完整性。

此方案假定双方已使用某种机制来建立共享机密-请求者密码。 没有对这些各方之间的组织关系做出任何假设。

使用安全令牌的直接信任

此方案演示了使用由 Web 服务直接信任的安全令牌。 此处的直接信任意味着请求者的安全令牌（或其签名机构）已知且受 Web 服务信任。 此方案假定双方已使用某种机制建立信任关系以使用安全令牌。 可以通过配置应用程序或使用安全传输来交换密钥来手动建立此信任。 通过安全传输密钥，我们意味着 SSL（或其他机制或进程）等传输可用作受信任方向接收方断言密钥或安全令牌有效性的一种方式。 各方之间的组织关系没有做出任何假设。

请求者向服务发送消息，并包含已签名的安全令牌，并提供安全令牌的所有权证明，例如签名。 该服务验证证明并评估安全令牌。 安全令牌上的签名有效，并且由服务直接信任。 服务处理请求并返回结果。

直接信任假定相关方充分理解隐私策略。

安全令牌获取

在某些情况下，使用的安全令牌不会作为消息的一部分传递。 而是提供可用于查找和获取令牌的安全令牌引用。

请求者向服务发出请求，并包括对安全令牌的引用，并提供所有权证明。 Web 服务使用提供的信息从令牌存储服务获取安全令牌并验证证明。 Web 服务信任（请注意，信任是在消息语义之外建立的）安全令牌，因此处理请求并返回响应。

防火墙处理

防火墙仍然是 Web 服务安全体系结构的关键组成部分，它们必须能够继续强制执行边界处理规则。

如下所示，防火墙会检查传入的 SOAP 消息，并且仅允许来自“已授权”请求者的这些消息渗透到防火墙中。

在此方案中，我们有两个请求者向防火墙内的 Web 服务发送消息。 防火墙检查消息，以确定请求者是否“授权”将消息发送到防火墙内的指定 Web 服务。

在此方案中，防火墙通过检查用于对消息进行签名的安全令牌来做出此决定。 如果签名有效，并且安全令牌的签名机构受信任来授权消息进入防火墙，并且令牌表示它确实授权消息进入防火墙，则允许该消息;否则会被拒绝。 在某些情况下，签名可能专门将防火墙引用为 SOAP 执行组件。

在其他情况下，防火墙还可以充当安全令牌颁发机构，并且仅允许包含防火墙颁发的安全令牌的所有权证明的消息。

颁发的安全令牌

下面是一个示例，展示了 Web 服务安全性如何支持受信任的方进行简单身份验证：

在前两个步骤中，请求者与认证机构通信以获取安全令牌，特别是证明请求者标识的断言签名声明。

请求者获取了安全令牌，因为 Web 服务具有要求需要适当类型的安全令牌的策略（在本例中为标识证明）。

请求者接下来向 Web 服务发送一条消息，其中包含安全令牌和附加到消息（认为验证器或已签名质询）的所有权证明，并接收响应。

请注意，在上述说明中，未详细说明标识认证服务的操作。 若要获取标识安全令牌，请求者可以使用现有的安全协议，也可以利用 Web 服务安全规范。

如果我们假设请求者使用的是 Web 服务安全规范，则系统会按如下方式运行：标识服务在策略中描述了其要求，然后请求者可以请求安全令牌及其标识证明。

请注意，标识服务只是安全令牌服务。 此外，Web 服务的对称性允许任何 Web 服务也封装安全令牌服务。

最后，请注意，Web 服务可以代表请求者（从安全令牌服务）获取安全令牌，并将其返回到请求者以供后续消息使用。

强制实施业务策略

在许多业务流程中，必须强制实施特定的策略。 例如，服务可能要求使用者具有特定评级或与特定审核公司站在一起。 借助 Web 服务，其中许多策略都可以自动进行编码和验证，从而简化整个过程。

请考虑以下示例：

尼古拉斯的经销商拥有一项 Web 服务，用于与其部件供应商进行交互。 但是，他们只想与制造商认证的零部件的供应商打交道。

一家零部件公司 Joshua 的部件公司将转到制造商并出示（并证明）其身份安全令牌（例如，从图示的安全令牌服务）并请求制造商的安全令牌，指出他们是经过认证的零部件经销商（假设他们经过认证且状态良好）。 约书亚的部分随后可以联系尼古拉斯的经销商，并提供（并证明）这两个安全令牌。

如果尼古拉斯的经销商将他们的业务政策编入服务政策，那么政策一致性的负担可能会提前加载到零部件公司（例如约书亚的部件）。

服务策略还可以指定允许制造商存储哪些信息的约束，以确保遵守隐私策略。

隐私

隐私包括一系列广泛的关注点，需要在从此策略中出现的每种规范中考虑。

通过提供服务策略中的隐私声明来解决基本隐私问题。 涉及委派和授权的更复杂的方案将在特定于这些方案的规范中介绍。

例如，个人声明一组“隐私首选项”，描述个人的行为或不想允许代表个人处理个人信息的应用程序。 一个代表个人工作的日历应用程序现在可以访问使用一组“隐私实践规则”的日历服务，以便就使用和披露个人信息做出声明和决定。 日历服务通过将隐私做法规则与隐私首选项相结合来做出决定，以确定建议的使用还是允许披露。

Web 客户端

假设我们提供了一个 Web 客户端与中间层 Web 应用程序通信的示例，而中间层 Web 应用程序又与另一个域中的 Web 服务通信（安全）。 中间层 Web 应用程序（可感知 Web 服务）想要获取 Web 客户端的安全令牌。

此外，此方案假定安全令牌允许中间层应用程序在与服务对话时代表客户端执行操作。

若要启用此方案，Web 客户端的浏览器将访问中间层应用程序，并重定向到关联的标识服务。 身份验证后（例如使用 HTML 窗体和 https），请求将重定向回中间层应用程序。 标识服务向原始中间层应用程序 Web 服务器（例如使用通过 HTTPS 发送的查询字符串）提供安全令牌（断言标识和委派）。 Web 服务器现在可以使用这些安全令牌，并向 Web 服务发出来自其自己的标识的请求。 Web 服务处理请求，并将结果返回到 Web 服务器，其中结果已格式化并返回到浏览器。

移动客户端

上述文档中所述的规范为解决移动安全性所特有的设计挑战提供了极大的灵活性。  Web 服务方法的灵活性支持多种加密技术，在具有有限计算和存储功能的设备上提供强加密保护和高性能加密保护。  同样，它使网络运营商能够提供安全代理（如网络网关）代表移动客户端进行操作。 

下面是合并这两个想法的示例。  当网络运营商支持移动客户端（使用这些 Web 服务安全规范）时，可以将这些客户端配置为通过网络运营商的网关发送请求。  在此方案中，网关是一个 SOAP 中介，它积极参与整个消息流;具体而言，网络运营商正在提供专为移动设备设计的增值加密算法。  网关可以增强或更改消息的安全令牌和保护质量。  请注意，即使设备在外部网络上漫游，此 Web 服务安全模型中固有的灵活性也允许此解决方案。 

以下示例对此进行了说明：

启用联合身份验证

Web 服务安全模型旨在支持联合身份验证。 下面是标识联合的简单示例：

Alice at Adventure456 希望使用 Business456 的货币 Web 服务。 货币服务将仅处理具有 Business456 颁发的安全令牌的请求。 Alice 仅具有由 Adventure456 颁发的标识声明（即标识安全令牌）的安全令牌。

在这种情况下，仅当 Business456 愿意接受与 Adventure456 的安全联合时，Alice 才能访问货币服务。

以下小节介绍了安全联合的几种方法。

使用安全令牌交换的联合身份验证

在此方法中，货币服务的策略指出它只接受 Business456 颁发的安全令牌。 由于该策略指示在何处获取所需的安全令牌，Alice 向 Business456 安全令牌服务提供 Adventure456 安全令牌，并接收 Business456 安全令牌。 然后，她向货币服务提出（并证明）此安全令牌。 下图对此进行了说明：

在此方法中，Business456 安全令牌服务配置为接受具有 Adventure456 颁发的标识声明的安全令牌

应指出，此示例与强制实施业务策略方案中的示例非常相似。 这演示了 Web 服务安全模型的灵活性。

使用信任链的联合身份验证

在此方法中，Currency 服务将接受具有任何安全令牌的请求，但它不会处理请求，除非它可以基于提供的安全令牌（和证明）获取 Business456 安全令牌。

为此，Currency 服务会将原始请求转发到 Business456 安全令牌服务，该服务评估初始安全令牌。 如果有效，它将认可请求，并可能包括 Business456 安全令牌，供 Alice 在后续请求上使用。 下图对此进行了说明。

在此方法中，Business456 安全令牌服务配置为接受具有 Adventure456 颁发的标识声明的安全令牌

使用安全令牌交换联合身份验证 （PKIKerberos）

在此方法中，Adventure456 已颁发 Alice 公钥安全令牌，货币服务的策略指示它仅接受其 KDC 中的 Kerberos 安全令牌。

在货币服务策略的方向上，Alice 向 Business456 的安全令牌服务提供公钥安全令牌（并证明）。 安全令牌服务封装 Business456 的 KDC。 因此，它可以验证 Alice 的公钥安全令牌，并为 Currency 服务颁发 Kerberos 安全令牌。 下图对此进行了说明：

在此方法中，Business456 安全令牌服务配置为接受具有 Adventure456 颁发的标识声明的公钥安全令牌。

使用安全令牌交换联合身份验证 （KerberosSecurity 令牌服务）

在此方法中，Adventure456 已颁发 Alice 一个 Kerberos 安全令牌，货币服务的策略指示它只接受其自己的安全令牌服务颁发的安全令牌。

在这里，我们假设 Adventure456 和 Business456 的管理员已交换公钥证书，以便联合安全性。 我们进一步假设 Alice 仅支持对称密钥技术。

根据 Currency Web 服务策略，Alice 需要获取可用于在 Business456 访问安全令牌服务的安全令牌。 由于 Alice 使用的是对称密钥安全令牌，Alice 首先联系其安全令牌服务，以获取适用于 Business456 安全令牌服务的安全令牌。 请注意，此安全令牌将包含使用 Business456 安全令牌服务的公钥编码的对称密钥 Sab。

Alice 使用适用于 Business456 安全令牌服务的安全令牌，请求货币服务的安全令牌。 Business456 安全令牌服务为 Alice 提供对称密钥、Sac 和货币服务的安全令牌。

Alice 使用适用于 Currency 服务和关联的对称密钥的安全令牌向 Currency 服务发出请求。

使用凭据交换的联合身份验证 （KerberosKerberos）

在此方法中，Adventure456 已颁发 Alice 一个 Kerberos 安全令牌，货币服务的策略指示它只接受由封装其 KDC 的自己的安全令牌服务颁发的 Kerberos 安全令牌。

在这里，我们假设 Adventure456 和 Business456 的管理员不希望建立跨领域可传递信任，但愿意交换公钥证书，以便联合安全性。 此外，我们假设 Alice 和 Currency 服务仅支持对称密钥技术。

与前面的示例一样，安全令牌服务能够向其信任域中的服务提供对称密钥安全令牌。 因此，上述方法在此方案中有效。

验证服务

此 Web 服务安全模型还支持请求方 外包 处理消息和安全令牌验证的方案。 应指出，滥用此类服务可能会导致可伸缩性问题。 也就是说，根据实现，服务执行验证服务可能更便宜（或更昂贵）。 Web 服务安全模型支持任一方法，从而启用此方案。

在此方案中，我们已将验证服务与安全令牌服务分开。 在其他情况下，它们可以合并或具有直接信任关系（因此不需要 WS-Federation）。

在此方案中，请求者从安全令牌服务获取安全令牌。 然后，它将消息发送到 Web 服务，并包括所有权证明（例如签名）。 Web 服务发送签名块、安全令牌及其已签名到验证服务的摘要的计算。 由 Web 服务信任的验证服务随后会发出有效的/无效决策。

应指出，验证服务可以通过代表声明相应声明的请求方颁发安全令牌来指示其决策。

支持委派

Web 服务安全性支持委派。 下面是一个复杂的委派方案，旨在显示方法的灵活性：Alice 使用 calendar456 来管理她的计划。 她想允许鲍勃在周二与她举行会晤。 但是，Bob 不会直接执行计划。 相反，Bob 使用服务计划 456 来设置需要放在 Alice 日历上的会议。

Alice 不知道 Bob 将如何安排会议，但她想要限制一组可以查看她的日历的服务

Alice 提供了一个安全令牌，使 Bob 能够在日历上安排会议。 此安全令牌包含限制 Bob 将会议安排到星期二的声明。 此外，此安全令牌使 Bob 能够颁发后续安全令牌，只要使用者能够证明他们具有来自 TrustUs456 的第三方服务的隐私认证。

由于 TrustUs456 已审核服务 Schedule456，因此他们具有一个安全令牌，用于断言其隐私认证。

当计划服务在 Calendar456 访问 Alice 的日历时，它可以证明其隐私认证的所有权证明以及基于 Alice 通过 Bob 到自身的安全令牌（s）访问和安排会议声明。

存取控制

在协同工作时，Alice 和 Bob 发现他们经常互相安排会议，并开发信任级别。 因此，Alice 希望允许 Bob 安排会议，而无需每次都委托给他。 她可能会增加委派安全令牌的到期时间，但她需要重新颁发这些令牌，如果她想撤销 Bob 安排会议的能力，这是有问题的。

Alice 与她的日历服务（身份验证自己）通信，并获取授权列表。 她更新授权列表，以允许 Bob 查看忙/闲数据和安排会议并将其提交到服务。 现在，当 Bob 访问她的日历服务进行这些操作时，他不需要 Alice 的委派安全令牌。

审计

在上述委派方案中，对抗者可能尝试在没有委派安全令牌或过期的安全令牌的情况下安排会议。 在这种情况下，请求将失败，因为对立方无法证明所需的声明。

为了跟踪这种类型的活动，该服务可以提供审核功能。 也就是说，当发生与安全相关的事件（例如身份验证或未经证实的声明或错误的签名）时，将记录该事件。 管理员可以安全地访问日志，以查看与安全相关的事件和管理日志。

例如，对抗者可能会尝试模仿 Bob。 使用监视器/管理工具，安全管理员 Carol 查看审核日志，并看到 Alice 的日历发生了许多安全故障。 在查看她看到有时 Bob 的请求失败的数据时，他的签名与消息或消息不匹配（重播）。 因此，Carol 收集用于试图跟踪对抗者的审核记录。

5 摘要

随着 Web 服务更广泛地应用，随着应用程序拓扑的不断发展，以支持防火墙、负载均衡器和消息中心等中介，随着对组织面临的威胁的认识变得更加清楚，对 Web 服务的其他安全规范的需求也越来越明显。  本文档提出了一个集成的 Web 服务安全模型和一组实现该模型的规范。 这些新规范通过扩展和利用（而不是替换）现有的安全技术和资产，使客户和组织能够更快开发安全、可互操作的 Web 服务。

IBM 和Microsoft认为，这是定义全面的 Web 服务安全策略的第一步。  它反映了我们迄今确定的挑战和解决方案。 随着我们继续与客户、合作伙伴和标准组织合作，确保 Web 服务的安全，我们预计，完成该策略需要更多想法和规范。 

贡献

本文档由 IBM 和 Microsoft 共同创作。

关键贡献包括（按字母顺序）：乔瓦尼·德拉-利贝拉，Microsoft;布兰登·迪克森，Microsoft;IBM乔尔·法雷尔：普拉里特·加格，Microsoft;IBM 玛丽安·洪多;克里斯·卡勒，Microsoft;巴特勒·兰孔，Microsoft;凯尔文·劳伦斯，IBM;安德鲁·莱曼，Microsoft;保罗·利奇，Microsoft;约翰·曼费尔德利，Microsoft;IBM马鲁山一郎;安东尼·纳达林，IBM;纳塔拉杰·纳加拉特南，IBM;里克·拉希德，Microsoft;约翰·谢丘克，Microsoft;丹·西蒙，Microsoft;阿贾穆·韦斯利，IBM

引用