企业应用Web服务安全：问题介绍(图)

介绍为何需要Web服务安全

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

本系列文章没有讨论到的问题

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

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

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

●Web服务在业务流程自动化以及异构系统互联等领域的良好前景

●在上述领域中应用Web服务的障碍首先并且最主要的是Web服务安全保护机制的(或者是觉察到的)缺乏

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

从Internet商业化的开始阶段起就存在对于构建标准BB自动处理链技术的不断尝试(某些做的确实不错)在此处理链中每个Web服务参与节点需要依次扮演服务器和客户(当它向处理链中的下一个节点请求服务时)的角色从安全的观点看一个节点需要向下一个节点提交自己的信用标记或者抽取并向下一个节点传递信用标记以声明自己信任此信用标记在SAML的术语中这两种方法分别被称为密钥拥有者(HolderofKey HK)以及发送方担保(SenderVouches SV)它们被用来声明加密信息所使用的加密运算的私钥的拥有者(请参考 安全声明标记语言 绑定和概要 PDF文档的第节)图中Web服务节点AB之间通信使用密钥拥有者(HK)方法节点BC之间通信使用发送方担保(SenderVouches 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消息中潜伏的攻击因此比传统的防火墙复杂得多它们除提供标准防火墙功能外还提供对于WSSecurity以及相关技术的支持

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

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

链条的缺失部分问题

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

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

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

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

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

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

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

目的解决方案的需求

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

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

开发的WSSecurity工具包应该满足的更确切需求如下

●现有的访问控制系统已经使用了种类广泛的后台策略及用户信息服务器为任何工业级别应用而开发的安全工具包的一个必须特性是能够与已有的基础设施集成虽然要求工具包支持所有不同来源不同形式的基础设施是不现实的但是它必须提供简单通用的适配接口这些接口允许(通过配置)在现有工具包中添加为特定存储提供者开发的插件来添加相应功能

●通过第方SDK提供对于XML签名XML加密功能的支持前面已经提到现在有一些相应的实现很可惜它们的相互兼容性很差同时为避免严重依赖于特定的SDK提供者和(或)其特定版本 工具包必须开放适当的挂钩以便插入其它不同实现的包装器 这些开放挂钩的接口应位于SDK结构层次的底层如此保有对其他SDK的供应者的最广泛的兼容性很幸运上面提到在本案例所需的密码运算功能有限不需要进行签名验证解密以及其他一些标准密码运算等功能

●通过挂接点使用第方SAML SDK提供的SAML标记生成功能将实现的工具包仅关心如何正确地在消息头部添加已生成的SAML标记(参考安全声明标记语言标记概要 PDF文档 )

●Web服务技术本身的异构特性决定工具包不能依赖于特定的平台如果需要平台相关的特性可以通过调用工具包公开API中的平台封装层来添加

●为降低开发工作量选择工具包支持的安全标记的类型时 有必要做出的一定的限制同时工具包的设计要合理当需要添加并支持新的安全标记类型时工作不会太复杂以致无法完成也就是说工具包的设计过程应当尽可能的抽象同时注意扩展性

●最后前面曾提到工具包应该保持相对轻量具有简单的供外部调用的API同时应该以解决当前的特定问题为导向而开发这样可以避免开发者学习使用另一个复杂API的负担

对于企业Web服务当前的访问控