介绍：为何需要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。相反，在此环境下为保护自动化处理链的安全，需要一个相对轻量简单的A[1] [2] 下一页
|
|
