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

问题提供(胶水)方案。这需要实现传统的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服务节点前，目的节点前端的访问控制系统需要对请求信息进行特定的安全处理。特别的处理包括首先进行的消息验证(消息结构和完整性)，以及