选择一个Web服务安全解决方案可能是一件具有挑战性的工作。本文将向您展示一些较为流行的解决方案，并且对这些方案的性能、限制条件等进行评价，供您在选择时参考。

Web服务设计的目的是为了将企业的功能以一种可被共同使用的、松散的联结形式表现出来。虽然有着获得一个SOA基础结构利益的潜力，Web服务也为企业的资产带来了未授权访问的风险。因此，通过将访问权限限制为只给合法的用户使用，从而防止一些对系统完整性造成破坏来保障Web服务的安全是至关重要的。

其实，让我们选择一个Web服务安全解决方案可能是一件使人畏缩的事情。目前，有很多可用的解决方案，而且有很多因素可以决定某一个特定的方案适合你的情况。虽然每一个解决方案都提供了相关的说明文档等，但我们却很难找到一个全面的可以帮助我们做出正确选择的方法指南。

本文虽然并不是一个完整的指导方针，却审视了一些流行的方案，并对其功能进行了评判。本文讨论了一些影响你的方案选择的因素，并为你提供了一些指南，帮助你做出一个科学而理智的决定。为了清楚起见，我们将相关的代码和相关消息也作为本文的一部分列示出来。

传输级vs.消息级安全

保障Web服务最常见的一种方法就是使用SSL来保障传输通道的安全。这是Web应用安全的一个自然扩展，在这种情况下，通过使用SSL，HTTPS协议来保障HTTP请求/响应的安全。SOAP/HTTPS属于与HTTPS等同的Web服务。它可以保证程序调用在保密性和安全性方面是安全的。实施SOAP/HTTP协议相对简单，因为多数应用程序服务器只是为HTTPS协议扩展了SSL的授权证书配置。

虽然这种方法可以帮助你快速地建立一个安全方案，它却有着一些你必须要考虑的局限性：

SOAP/HTTPS并没有解决认证的需要。它必须与其它的机制（如Username Token）相结合，才能处理认证问题。

因为SSL是为整个通道加密，它就为性能带来极大的影响。如果只是消息的局部需要保障安全，可以考虑使用消息级别的安全（Message Level Security），因为它支持局部的加密和完整性，这显然会改善性能。

SSL是一个点到点（point-to-point）的安全方案，它不适合端到端（end-to-end）的拓扑结构，因为在端到端的结构中，消息需要通过网关等仲裁设备进行传送。

通过MLS(即Message Level Security，消息级安全),安全限制就可以被运用于消息自身而不是传输通道。Web服务安全标准在近年来被进行了具体的规定和发展，已经涉及到了MLS的应用问题。其中包括大批的标准，如XML-Encryption, XML-Signature, UsernameToken, Kerberos, SAML等。这些标准覆盖了不同的技术，在有些情况下这些标准可以进行组合，进一步产生一个综合性的解决方案。在一个使用UsernameToken以求鉴定和认证并且使用SSL以求机密性和完整性的例子中，将MLS 与TLS结合起来是可能的。

为了演示MLS，下面的例子对一个样本性的SOAP/HTTP消息进行了加密。这个作为示例用的是一个简单的计算器服务，其界面包括一个可以接受两个数字的乘法方法，还有一个使用Xfire and WSS4JJ框架的Java客户端。（笔者在一台使用WebSphere 6.1的主机上测试了Web服务），不过多数应用程序服务器支持基本的SOAP消息安全，因此你可以在另外一台可选的服务器上运行这项服务）。你可以从这儿下载这个示例代码。其中的ReadMe.html文件描述了下载的zip文件的内容。

这个计算器服务通过执行EJB来备份。当然，你可以有另外的选择，如选择JavaBeans等。下面展示的是EJB的界面：

package com.dev.ws.security.ejb;
public interface Calculator extends javax.ejb.EJBObject {
public float multiply(float a, float b) throws java.rmi.RemoteException;
}
The EJB bean simply implements the multiply method as follows: 
package com.dev.ws.security.ejb;
public class CalculatorBean implements javax.ejb.SessionBean {
...
public float multiply(float a, float b){
return a*b;
}
}