从基于传送的安全转移到基于信息的安全
当我给出关于Web服务的介绍的时候，不可避免的就会有来自于听众的关于安全的问题。最常见的问题是:“你是如何保障Web服务的安全的”。通常会跟随着怀疑的论断:“Web服务不可能是安全的”。
但是，记住，今天的Web服务的主体是基于同样的再Web之下的授权的技术，我们称之为HTTP。从而，所有的常见的确保Web安全的应用程序——基本的认证和SSL是最常见的——同Web服务一起工作的很好。这些安全技术多年来对各种的在线商务事务处理发挥了巨大的作用。
尽管如此，但是组织所具有的关于基于Web的安全策略的主要问题是通常的解决方法例如SSL有一点稍显笨拙，因为他们通常确保了整个线路传输的协议的安全，而不是只针对在协议之上传输的SOAP消息的。此外，对许多基于信号的集成项目，在信息到达他们的目标终点之前，一些中间步骤是必须的，同时传送级别的安全策略让这些信息在各个中间检查点并不安全。
为了获得更好的控制级别和防止中间的安全问题，各种组织所作的基于SOAP的信息集成通常想要的都是在信息层确保安全而不是在传输层。这所意味的是信号自身确保它的安全，而不依赖于传送。当安全只限于信息的时候一些事情变得很显然。首先，通常为大多数Web 服务所提供的SSL能力会被我称之为信号安全的东西替代，而信号安全也将成为为所有的客户和服务方交互安全的信号的必须。第二，安全信息将会被信号自己携带。第三，除非中间或者最终节点拥有正确的安全基础构造同时是可信任的，否则信号会仍然保持安全并不可读取，然后被往前转递到下一个节点。
Web 服务安全:WS-Security规范
你如何确保信号的安全，而不是传输的安全?答案在于OASIS标准.WS-Security，作为一个所有工业认可的推荐在2004年4月发布。WS-Security所定义的是一个把三层安全策略加到SOAP信号中去的机制。
认证标志:WS-Security认证标志使得客户可以以一种标准的方式发送包含在SOAP消息头中的用户名和密码或用于认证目的的X.509认证。尽管SAML和Kerberos标志普遍使用，但是关于这些标志的WS-Security规范也还没有发布。
XML加密:WS-Security被使用在W3C的 XML加密标准，从而使得SOAP信号体和它的组成部分被加密以确保机密性。通常的，不同的加密算法都被支持——在Oracle Application Server 10g Release 10.1.3中，被支持的算法是3DES, AES-128和AES-256。
XML数字签名:WS-Security被使用在W3C's XML数字签名标准中，从而使得SOAP消息可以被数字签名确保消息的整体性。通常的，签名时一个有消息本身的内容计算产生的。如果消息在发送途中被更改，数字签名就不可用了。Oracle Application Server支持DSA-SHA1, HMAC-SHA1, RSA-SHA1, 和 RSA-MD5算法。
配置Web服务的服务端
通常的当开发者看到WS-Security的三个组件，一些关于他们是如何在特定的应用程序中协调处理认证，加密，和数字签名的步骤的疑问也就产生了。
幸运的是，绝大多数供应商例如Oracle正在实现WS-Security为一个发布的机制，从而可以把这个机制应用于新的和现有的Web服务。 例如在Oracle JDeveloper 10g Release 10.1.3中，你只需要简单的再Web服务节点上点击，选择安全Web服务，然后跟随走完一个简单的向导。图一是Oracle JDeveloper.中的一个WS-Security的基本工具的运行时候的外观的一个屏幕截图。
图一 用Oracle JDeveloper 10g Release 10.1.3保护Web服务的安全
为了提供一个简单的在运转的WS-Security的用况，我用图一中所提供的认证的属性——用户名，密码认证标志——并使用getEmpSalary方法把他们应用到HRService Web服务。
注意到WS-Security运行时能力被元素使能。服务端对用户名和密码口令认证的需要被元素定义。
一旦这些配置被布置在一个一般的Web服务Ear文件。在Oracle应用程序服务器端运行时的管理配置文件wsmgmt .xml会被这个信息更新。我在上个月的Web服务管理专栏中用图表的方式解释了这个过程。在布置以后，这个Web服务也就可以用WS-Security的用户名密码标志来测试了。
配置Web服务客户端
下一步是决定如何从来自于Web服务客户端获得用户名和密码的WS-Security标志放入SOAP信息中。通常的Web服务工具包提供一个API或者发布的机制去完成这个功能。
图二 基于信号层安全的Web服务安全
为了配置这个信息，Oracle JDeveloper在Web服务的客户端提供了一个如图一所示的向导的镜像。这两个向导的主要区别是在于客户端的向导提供了获取用户姓名和密码口令的能力，而服务器端的向导则没有提供。列表二提供了所产生的客户端配置。这只是可选的，因为很多开发者并不愿意把这些信息嵌入到配置文件中去(虽然这对测试是非常有用的)。Oracle应用服务器提供了一种简单的客户API，用以设置客户的Web服务的用户名和密码口令标志。
当我运行生成的客户端，列表三种的信息就生成了，除去雇员的薪金请求，这些信号包含了信号头中包含的用户名和密码口令标志，还包含了支持了领先于标准的WS-Security wsse命名空间的标准模式的WS-Security参考。
结论
同很多其他的称之为WS—*的标准，通常都有关于WS-Security在异构环境下工作的协调性的担忧。在我的例子当中，我选择了最简单的可能性的情况，但是在具有更复杂的认证标志，加密和数字签名的实际文件中，协调性立刻变得极为重要。
业界是非常清楚这个问题的，同时中立公司论坛例如Web服务协调性组织(WS-I)已经开始工作，该组织由主要的厂商参与，其中包括Oracle，从而确保Oracle, IBM, Microsoft, Sun, 和BEA 所实现的WS-Security实现可以共同操作的。
这些努力能够带来一个名叫Basic Security Profile的如何使用WS-Security的轮廓或者说是一个推荐的最好实践。它将会补充其他的由WS-I发布的关键的协调性蓝本，Basic Profile 1.1。Basic Profile 1.1关注于SOAP, UDDI, 和 WSDL的最佳实践。
