对于SOA为一个机构所带来的许多的好处，例如具有在许多不同的提供者和供应商的情况下混合和匹配服务，或者以一种独立于平台的形式来授权访问数据，有许多的实现细节在处理服务类型架构的时候就将被很早的注意到。安全就是这样的一个领域，如果没有在它上面付出应有的努力，那么它就会成为使得任何SOA的举动失败。

　　安全对于许多的IT部门来说都是一个重要的问题之一，但是SOA安全问题完全是在另一个新的纬度上了。当服务的混合和匹配可以开启一系列的商务处理的可能性的时候，如果底层的服务没有采取足够严格的策略来处理它们可能会涉及到的许多的交互，那么它也可以开启一个潘多拉盒，成为灾难之源。

　　从另外一个方面来看，具有独立于平台的数据访问也就带来了开放，但是只有开放也就会带来攻击的问题。如果没有进行必须的防备，那么你和你的商业合作伙伴的专用通道将会轻易的被欺诈用户窃取到。

　　通过XML标准或在网络层次上提供的，安全可以放在SOA概念栈，也就是WS-*/SOAP规范的许多不同层次上。

　　如果你有一个运行在SOA环境下的应用程序，固定在网络层的安全也许是最为直接和非入侵的方式来提高安全的，尽管它不需要修改底层的应用程序。

　　许多的SOA网络安全策略和许多的基于Web的应用程序是采用相同的策略的，他们采用的方式都可以归结为创建一个虚拟局域网(virtual private network)来排除服务器和客户端的交互，使用数字证书来建立SSL(secure socket layer)保护或者HTTPS，或者通过在软件或者硬件上部署防火墙基础架构来检测通过SOA进来的可疑请求。

　　网络安全，或者通常被称之为的传输安全，可能会阻碍很多的攻击，但是这并没有排除有人监听或者截取一个应用程序的一部分数据。为了解决这个问题，许多的建立在XML基础上的规范可以用来用来保护应用程序的有效载荷。

　　XML加密和XML签名是两个有W3C开发的标准，两个都可以用来把安全加入到基于XML的数据中去。

　　前面一个规范是用来把原始的XML数据通过密码依次加密，从而让数据能够在请求者和响应者之间以一种模糊的方式传输。尽管密码的目的是为了对第三方的保密，这就能保证即使是在传输的过程中有截取的情况发生，消息也将会很难读董的，因为密码已经改变了原有的内容。

　　XML签名，从另一个侧面，是用来进行XML文档的篡改检测的。通过使用XML签名，一个服务供应商可以提供给任何的服务消费者——或者反之亦然——以一种确定的方式来检测XML的有效负载是不是相对于它原来的方式或者它原来的状态有了改变。

　　你应该知道的是XML加密和XML签名都适用于任何的XML类型的文档。意识到这一点是很重要的，因为他们不仅仅可以用来锁定和服务请求之间的有效负载的交换，同样的他们也可以用于对类似WSDL这种契约，这些文档也是基于XML的，并且也是SOA中的一个重要组成部分。

　　为了完成能够使SOA安全目的，我们找到了和安全相关的WS-*标准。他们是严格的设计来用于SOA有效载荷载在服务之间的传送的。

　　基于这个事实，使用WS-*安全标准来保护服务需求的安全需要一个冗长的分析和设计阶段，因为他们本身在服务逻辑上就是确定的，尽管他们他们将能够基于这个原因为服务提供更加健壮的安全解决方案。

　　在OASIS标准中心关于安全我们找到了WS-Security .。WS-Security规定了安全令牌在服务请求者和服务提供者之间交换的方式，从而能够把这个令牌用于以后的验证目的。

　　WS-Security提供了对不同类型的令牌的支持，例如Kerberos和 X.509令牌，同时也支持用于其他安全问题的机制，而不仅仅限于SOA范围内的。关于WS-Security很重要的是要意识到它的使用一定要在SOAP消息头里面的。

　　列表1.1:在SOAP消息头中的WS-Security数据

　　    <?xml version=’1.0’ encoding=’iso-8859-1’>
　　<s12:Envelope
　　 xmlns_s12=’http://www.w3c.org/2003/05/soap-envelope’
　　 xmlns_wsse=’http://www.docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd’>
　　 <s12:Header>
　　   <wsse:Security>
　　      <!-- WS-Security Token Data/Description -->
　　   </wsse:Security>
　　 </s12:Header>
　　 <s12:Body>

　　 </s12:Body>
　　</s12:Envelope>  
  
 
　　正如你在前面的代码注意到的，对应于WS-Security 的wsse命名空间是被附在SOAP封装体内的，并且在这个命名空间中，令牌数据依据规范被嵌入到消息中去，以提供给服务消费者和提供者使用。

　　当WS-Security是第一批直接在SOAP消息中处理和安全相关的规范，很多其他的规范也是以这种方式来处理的——把消息嵌入到SOAP封装体中——并逐渐的跟随上来。 其中之一就是WS-SecurityPolicy，WS-Trust和WS-SecureConversation,所有这些规范都是提供不同程度的安全功能，以加固你的SOA基础架构为目标。

　　通过这些我们总结了确保你的SOA安全的方式。你也许看到了，一些技术需要更加冗长的实现过程，而其他的一些也许更加直接，但是不管你决定采用什么方式，你的SOA都不能忽略这个问题。