为何需要Web服务安全

　　本文关于如何在企业环境中实现和应用基于Web服务安全技术(WS-Security)的安全防护方案这一系列文章之一。使用访问控制机制来保护公司的Web服务资源的安全，是企业应用的典型特征之一，此特征同其它特征一起组建企业应用环境。此系列中将要提出的针对开发安全防护方案的建议和设计多数来源于笔者在实现TransactionMinder，一个先进的Web服务安全保护系统中获得的第一线开发经验以及客户的需求。笔者在此处特意作了一般化处理，使得这些思想和设计可以应用在其他可比较的安全保护系统中。

　　文章没有讨论到的问题

　　首先，WS-Security理论基础的方方面面以及如何使用WS-Security来保护SOAP Web服务的资料随处可见。因此，关于WS-Security、XML安全、XML加密、XML签名、SAML(Security Assertion Markup Language: 安全声明标记语言)、PKI(Public Key Infrastructure: 公钥基础设施)等技术的理论基础及一般讨论请参考相关出版物以及在线资源–请参考下面的资源部分。

　　当然，对于涉及到的技术，以及在讨论组件实现的相关章节中提到的不同组件的目的会给出解释，不过笔者假设读者对这些主题有最低程度的基本理解。

　　其次，许多讨论如下主题的文章已经发表:

　　●Web服务在业务流程自动化以及异构系统互联等领域的良好前景
　　●在上述领域中应用Web服务的障碍。首先并且最主要的是Web服务安全保护机制的(或者是觉察到的)缺乏

　　此处，没有必要重复为安全通信提供标准和工具的重要性，也没有必要重复令人费解的安全标准制定过程以及标准发展的复杂性。

　　从Internet商业化的开始阶段起，就存在对于构建标准B2B自动处理链技术的不断尝试(某些做的确实不错)。在此处理链中，每个Web服务参与节点需要依次扮演服务器和客户(当它向处理链中的下一个节点请求服务时)的角色。从安全的观点看，一个节点需要向下一个节点提交自己的信用标记，或者抽取并向下一个节点传递信用标记以声明自己信任此信用标记。在SAML的术语中，这两种方法分别被称为“密钥拥有者”(Holder-of-Key, HK)以及“发送方担保”(Sender-Vouches, SV)，它们被用来声明加密信息所使用的加密运算的私钥的拥有者(请参考 "安全声明标记语言 绑定和概要" PDF文档的第5节)。图1中，Web服务节点A、B之间通信使用“密钥拥有者”(HK)方法，节点B、C之间通信使用“发送方担保”(Sender-Vouches, SV)方法。

　　图1. “密钥拥有者” 请求(Holder-of-Key, HK)以及“发送方担保”(Sender-Vouches,(SV)请求

　　标记解释：  A auto token, A的验证标记; A public key, A 的公钥; A signature, A的签名; B public key, B 的公钥; B signature, B的签名。

　　从理论转回来，考虑当前企业软件环境，首先需要注意的是作为Web服务保护机制的访问控制系统(如Digital Evolution的TransactionMinder 或 Management Point  )的存在。这些保护机制普遍用于保护系统防御输入的SOAP消息中潜伏的攻击，因此比传统的防火墙复杂得多。它们除提供标准防火墙功能外，还提供对于WS-Security以及相关技术的支持。

　　因此，为支持实现上述的自动服务链，作为请求方的Web服务节点应该对输出的信息进行适当处理，使其可以被保护目的Web服务节点的访问控制系统所接受。

　　在本系列文章的主要关注点是对于位于不同的访问控制系统后的Web服务节点互联问题提供(胶水)方案。这需要实现传统的WS-Security的功能的子集，但是又略微不同。实现细节会在下面的需求部分讨论，一个示例(工具包)实现会在后续的文章中展开。

　　链条的缺失部分：问题

　　显然，企业级的访问控制系统不会孤立存在，它们同后台的用户目录服务器和访问策略服务器连接。这些服务器可以提供用户信用标记以及基于访问策略做出访问控制决定。

　　典型的访问控制系统需要处理验证和授权任务。基于不同的配置方案，系统可以接受许多种类的信用标记。对于Web服务访问控制系统，除其他需求外，特别地需要支持不同的基于Web服务安全的方案。系统需要从输入的Web服务信息头部的WS-Security信息部分提取并使用用户信用标记来验证请求者。另外，如图2所示，访问控制系统还需要能够修改输入的请求信息，如添加额外的安全头部信息，添加特定的验证标记和签名，以及进行消息解密等。

　　图2. 访问控制系统的角色

　　标记注释： Validation, 确认； Authentication, 验证；Authorization, 授权； policy store, 策略库；User Directory，用户目录对Web服务输出信息自动地进行安全处理以及对输入请求的状态信息和信用标记自动的进行提取，现有的访问控制系统还无法做到。实现这样功能可能需要一个特殊的复杂代理或者网关，在输出信息输出前对其进行修改处理。当前，这方面的工作多数集中在硬件方面(比如DataPower的 XS40 XML Security Gateway)。软件实现，虽然提供了丰富的类似硬件代理的功能，但是实际上很有限。

　　因此，企业Web服务的开发者不得不手工编写代码来提取信用标记并对输出信息进行适当的安全处理。这需要对XML进行手工解析, 或者利用常见的XML签名加密(Apache XML Security 项目，IBM XML Security Suite)、SAML(SourceID SAML 1.1 工具包 )、或者WS-Security(Apache的 WSS4J 项目, Phaos’ WSSE Toolkit)等工具包。

　　由于WS-Security涉及相当广泛的技术，因此其实现必然依赖于许多外部的软件开发包。现在可用的软件开发包不少，不过彼此之间存在的兼容性很差，利用所有的工具包使其兼容本身就是一个大挑战。不兼容的问题举例如下：支持的算法集合不同、不兼容的证书格式、使用的JDK版本的冲突、依赖的XML解析器的不兼容性。

　　WS-Security标准本身具有通用性，功能丰富，实现完整支持标准的通用WS-Security SDK, 将导致异常复杂的API。进而，组织内开发者基于特定需求需要对此API简化包装时，通常需要付出额外的开发工作。

　　最后不得不提到的是，现有的安全SDK通常是自依赖的——其功能等依赖于自己提供的信用标记存储结构及其访问接口，对于企业现有的策略以及用户目录服务器等并未提供良好的挂钩(hook)。企业开发者需要利用已有的存储设备等基础设施，实现新的系统需要与已有设备连接。因此，通常需要在系统中整合多种类型的信用标记存储方案和标记格式，这意味着需要为兼容性进行多层次的封装工作。

　　目的：解决方案的需求       

　　这里考虑特别的案例——作为在已有访问控制系统下开发企业Web服务的开发者，我们并不需要一个完全支持标准的膨胀的SDK。相反，在此环境下为保护自动化处理链的安全，需要一个相对轻量简单的API来帮助解决现存的方案的不足。

　　在请求信息到达目的Web服务节点前，目的节点前端的访问控制系统需要对请求信息进行特定的安全处理。特别的处理包括首先进行的消息验证(消息结构和完整性)，以及签名验证和对任何加密内容的解密等。在我们的实现中Web服务的请求输入点上应该是(可能)附带已经验证的WS-Security头部信息的有效SOAP信息，以及头部附加的特定验证标记。在图3中Web服务节点B处，工具包应该协助开发者从(请求A的)输入中提取验证标记，构造新的(位于请求B中的)Web-Security标记，或为了满足目标系统(Web服务节点C)的策略需求而改变已有(请求A中包含的)信用标记。

　　图3. Web服务链

　　开发的WS-Security工具包应该满足的更确切需求如下：

　　●现有的访问控制系统已经使用了种类广泛的后台策略及用户信息服务器。为任何工业级别应用而开发的安全工具包的一个必须特性是能够与已有的基础设施集成。虽然要求工具包支持所有不同来源、不同形式的基础设施是不现实的，但是它必须提供简单通用的适配接口，这些接口允许(通过配置)在现有工具包中添加为特定存储提供者开发的插件来添加相应功能。
　　●通过第3方SDK提供对于XML签名、XML加密功能的支持。前面已经提到，现在有一些相应的实现。很可惜，它们的相互兼容性很差。同时为避免严重依赖于特定的SDK提供者和(或)其特定版本, 工具包必须开放适当的挂钩，以便插入其它不同实现的包装器。 这些开放挂钩的接口应位于SDK结构层次的底层，如此保有对其他SDK的供应者的最广泛的兼容性。很幸运，上面提到，在本案例所需的密码运算功能有限，不需要进行签名验证、解密、以及其他一些标准密码运算等功能。
　　●通过挂接点使用第3方SAML SDK提供的SAML标记生成功能。将实现的工具包仅关心如何正确地在消息头部添加已生成的SAML标记(参考安全声明标记语言  标记概要 PDF文档 )。.
　　●Web服务技术本身的异构特性决定工具包不能依赖于特定的平台。如果需要平台相关的特性，可以通过调用工具包公开API中的平台封装层来添加。
　　●为降低开发工作量，选择工具包支持的安全标记的类型时, 有必要做出的一定的限制。同时工具包的设计要合理，当需要添加并支持新的安全标记类型时，工作不会太复杂以致无法完成。也就是说，工具包的设计过程应当尽可能的抽象，同时注意扩展性。
　　●最后，前面曾提到，工具包应该保持相对轻量、具有简单的供外部调用的API，同时应该以解决当前的特定问题为导向而开发。这样可以避免开发者学习使用另一个复杂API的负担。

　　对于企业Web服务，当前的访问控制系统已经提供了如下的保护功能，因此下面这些特性不在工具包需求范围之内：

　　●验证和授权：这两项特性本身就不属于WS-Security的标准范畴。因此，我们假定访问控制代理已经在输入的请求信息中添加了所有必要的验证和(或)状态标记信息。
　　●信息验证：假定在工具包处理输入信息前，已经完成其结构以及完整性验证，无效的输入信息应该已经被拒绝，不会到达被保护的Web服务节点。此假定对于附加于信息安全头部的安全声明标记语言(SAML)断言(assertion)同样适用。
　　●实现安全声明标记语言的特有的功能：此处讨论的是WS-Security的特性，而SAML只是WS-Security支持的众多标记中的一种，因此，工具包的以依赖外部提供者生成必要的SAML断言这种方式，提供对于SAML的支持。
　　●XML签名验证： 请求信息被允许输入前，所有签名应该已经在前端网关处验证完毕
　　●XML解密： 任何信息内容如果设定为当前Web服务节点可读，应该在签名验证之前解密或验证之后立即解密

　　结论：关于实现阶段

　　基于的上述一般需求 ，工具包的实现过程会包含如下的阶段，每个阶段都添加或扩展了特定的功能：

　　●设计框架添加生成WS-Security头部信息以及添加支持的标记信息的功能
　　●增加对于X.509标记、SAML标记、以及用户名称标记的初步支持
　　●增加从请求消息的安全头部提取已支持格式的标记的功能
　　●增加在输出的SAOP请求信息头部中添加XML签名的功能
　　●增加在输出信息中加密内容的功能
　　后续文章中将构建工具包的框架并依次添加上面的功能，同时会讨论相关标准的某些性质。

　　缩略语：

　　●WS， Web服务; 
　　●WSS， Web服务安全; 
　　●TC，技术委员会；
　　●WG，工作组；
　　●SAML，Security Assertion markup language 安全声明标记语言;
　　●WS-I, Web Service interoperability organization, Web服务互操作组织
　　●PKI， Public Key infrastructure , 公钥基础设施