Web服务安全性解决方案（以IBM WebSphere Application Server为例）（AMT 袁磊）

3、2 使用个体凭证的企业应用程序集成

一个客户有多条需要访问遗留系统的业务线。业务需求是，在完全不同的系统之上提供内部的应用程序来访问遗留系统中的企业数据库。次要的目标是，为外部的业务合作伙伴提供同一遗留系统的访问权。每个需要访问数据的用户在在共同的 LDAP 注册中心中都有现存的个体凭证——他的/或她的用户 ID 和密码。用户由消费应用程序（Consuming Application）验证，他们的身份使用 WS-Security UsernameToken 安全令牌在 Web 服务请求中传送。安全性令牌和 SOAP 消息体的数字签名使用的是与消费应用程序（Consuming Application）相关联的 X.509 证书。一旦确认签名，消费应用程序（Consuming Application）就被验证了。 

在服务提供者（Service Provider）上，设置 WebSphere Application Server 验证使用在 UsernameToken 中传送的身份作为断言的身份，它已经由消费应用程序（Consuming Application）验证。当处理请求时，WebSphere Application Server 将安全性上下文中的身份用于执行的线程。这就使得 WebSphere Application Server 能够提供对 Web 服务资源的细粒度授权。 

这个解决方案使用了 WebSphere Application Server 的 WS-Security TimeStamp 元素，并且对这个元素进行了数字签名以防重播攻击。 

由于希望这个解决方案支持大量的消费应用程序（Consuming Applications），所以将服务提供者（Service Provider）的管理员的任务减到最少也是一个需求。为了满足这个需求，设置 Web 服务安全性（WS-Security）来提供消费应用程序（Consuming Application）的 X.509 证书作为 Web 服务请求中的二进制安全性令牌。 

业务需求就是保护解决方案，使其不依赖于网络传输。解决方案的体系结构包括使用 XML 数字签名（XML Digital Signature）和 XML 加密（XML Encryption）来满足验证、数据完整性和数据机密性的需求。然而，取决于 XML 加密（XML Encryption）的开销，HTTPS 可以提供数据机密性。这种选择需要加以权衡的是，仅仅在两个网络节点之间提供安全性（一般通过 Internet），而不适用于其他的网络传输。

图 2 —— 使用个体凭证的 EAI

3、3 联合身份

一组业务合作伙伴有这样的需求，就是使他们的雇员能够从自己不同的企业访问应用程序。他们的目标是改善他们的流程，允许每个合作伙伴向他们的雇员提供一组统一的服务，这组服务利用了其他合作伙伴的业务功能。例如，业务合作伙伴通常在他们销售周期中为代理集成供应商所使用的信息。尽管业务合作伙伴可能有自定义的 Web 页，但是代理必须离开这个集成的 Web 环境，“跳”到特定的供应商 Web 页去检索所需的信息。业务伙伴的 Web 站点和供应商的 Web 站点之间的跳跃带来了很多的难题，包括安全性问题、内容集成的困难、以及记住众多的用户名、密码和各个供应商的 Web 站点地址所造成的混乱。

主要的业务伙伴在与它的伙伴的关系中具有优势，它使用安全性断言标记语言（Security Assertion Markup Language，SAML）控制对它的 Web 资源（HTML、Servlet、JSP）的访问。结果，他们的需求之一就是利用 SAML 断言控制对他们的 Web 服务的访问。 

这些合作伙伴的解决方案包括联合的身分（Federated Identity）模型，在这个模型中，消费应用程序（Consuming Application）验证它的本地用户并使 Web 服务请求断言雇员的身份。正如在前面的客户场景中展示的，服务提供者（Service Provider）依赖于消费应用程序（Consuming Application）去验证用户，但是在这种情况下，每个合作伙伴都有一个不同的安全域。因而，当处理 Web 服务请求时，提供者需要将断言的身份映射到对于它的安全域有效的凭证。这个模型需要任何双方之间具有信任关系。通过使用 SSL 和 X.509 证书，相互验证实现了信任。 

合作伙伴的主要目的之一就是不公开用户所在的安全域的用户证书。为了达到这个目的，合作就映射到他们的用户身份的公共假名（common pseudonym）达成一致意见。一个人的社会保障号码（Social Security Number）就是假名的好例子；然而，考虑到法律因素，它不是最好的选择。 

Web 服务安全性（WS-Security）可以对 SOAP 头中传送的作为基于 XML 安全性令牌的 SAML 断言进行数字签名，并且签署 SOAP 消息的主体。这提供了验证消费应用程序（Consumer Application）和确保消息完整性的功能。对于这个解决方案，加密使用 HTTPS 的网络连接提供了消息的机密性。 

通过使用在 SAML 断言中提供的用户身份作为假名，服务提供者（Service Provider）将假名映射到在它的安全域内有效的本地用户身份。因为业务功能包括授权逻辑，所以在调用 Web 服务实现时，用户身份作为一个 HTTP 头参数在服务提供者（Service Provider）的环境中传送。结果，基于数字签名的成功，WebSphere Application Server 只提供粗粒度的授权。

图 3 —— 使用 SAML 的联合身份

 这个解决方案在 WebSphere Application Server 提供对 WS-Security 的支持以前就已经实现了，它使用的是自定义 WS-Security 组件。这个解决方案签署整个 SOAP 消息，并在给消费应用程序（Consuming Application）的响应中提供了一个安全性上下文令牌，以用于后续的请求。这个安全性上下文令牌使性能最优化，类似于传统的 Web 解决方案使用 HTTP cookies 来传送安全性上下文的方式。

WebSphere Application Server V5.02 和 V 5.1 支持传送基于 XML 的令牌（例如，SAML）。然而，必须提供自定义的 JAAS 登录模块（JAAS Login Module）来将令牌中的用户身份合并到 WebSphere Application Server 的安全性上下文中，以便利用 WebSphere Application Server 进行授权。当需要应用程序到应用程（application-to-application）的安全性而不只是企业边界上网络节点之间的 Internet 安全性时，用户应该考虑 Web 服务安全性（WS-Security）。

4、 总结

因为 Web 服务安全性（WS-Security）将影响总的响应时间以及的解决方案可以支持的同时发生的请求的数目，所以决定使用 Web 服务安全性（WS-Security）是非常有道理的，这一点很重要。与使用 XML 数字签名（XML Digital Signature）和 XML 加密（XML Encryption）提供的解决方案相比，在很多情况下，启用传输持活（KeepAlive）的 HTTPS 提供的解决方案的性能要好得多。然而，HTTPS 究竟为提供了多好的解决方案实际上取决于 Web 服务实现所执行的业务逻辑的总处理时间。如果服务是对一个具有良好索引的数据库的简单查询，花费少于 100 毫秒的时间，那么将看到这两个选择之间巨大的差异。如果业务逻辑比较复杂或分布在远程系统之上，并且处理需要花几秒，那么这种选择可能就不会造成那么大的差异。

 在比较 Web 服务安全性（WS-Security）和基于传输协议（比如 HTTPS）的可选方案的影响时，应该保持谨慎。如果只使用包含简单字符串的 Web 服务请求消息，并且服务本身也仅仅是回显（echo）作为响应的消息，那么这样的测试结果可能会导致得出无意义的结论：使用 Web 服务安全性（WS-Security）的解决方案总是比使用 HTTPS 安全性机制的解决方案的性能低得多。例如，使用中等复杂程度的 XML 结构发送 4K 字节的实际请求消息与使用简单的字符串发送 4K 字节的测试消息相比，SOAP 引擎的处理时间增加了 30%，从而减少了两个安全性机制之间的整体差异。如果业务逻辑开始执行，并且必须处理实际的业务信息（这不同于 25 毫秒回显（echo）），那么在执行实际工作时，就能够切实地理解 Web 服务安全性（WS-Security）给解决方案带来的真正影响。 

当业务需求证明应用程序端点之间对以任务为中心的数据、具有市场价值的数据或机密的数据的消息完整性的要求是正当的时，由 Web 服务安全性（WS-Security）提供的数字签名功能就是很好的选择，并且可以很容易地在厂商的应用程序服务器（比如 Websphere Application Server）中实现。 

XML 数字签名（XML Digital Signature）和 XML 加密（XML Encryption）都将对解决方案产生了影响。如果性能是超过所有其他需求第一位考虑的因素，那么 HTTPS 就是最佳的选择。现今，一个常用的实践方法是，使用 XML 数字签名（XML Digital Signatures）验证应用程序和数据完整性，而依赖于 HTTPS 提供机密性。使用 XML 数字签名（XML Digital Signature）和 XML 加密（XML Encryption）的影响究竟是小还是大，只能通过在应用程序环境中使用实际的数据和业务逻辑来启用这个功能，然后测量它们之间的差异，这样才能确定。