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

签名验证和对任何加密内容的解密等。在我们的实现中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服务节点可读，应该在签名验证之前解密或验证之后立即解密
　　
　　结论：关