SOAP技术和安全性研究.docVIP

一：SOAP简介以及SOAP安全介绍 　　SOAP（Simple Object Access Protocol ）简单对象访问协议是在分散或分布式的环境中交换信息的简单的协议，是一个基于XML的协议。它包括四个部分：SOAP封装（envelop)，封装定义了一个描述消息中的内容是什么，是谁发送的，谁应当接受并处理它以及如何处理它们的框架；SOAP编码规则（encoding rules），用于表示应用程序需要使用的数据类型的实例; SOAP RPC表示(RPC representation)，表示远程过程调用和应答的协定;SOAP绑定（binding），使用底层协议交换信息。 　　虽然这四个部分都作为SOAP的一部分，作为一个整体定义的，但他们在功能上是相交的、彼此独立的。特别的，信封和编码规则是被定义在不同的XML命名空间(namespace)中，这样使得定义更加简单。 　　SOAP的两个主要设计目标是简单性和可扩展性。这就意味着有一些传统消息系统或分布式对象系统中的某些性质将不是SOAP规范的一部分。比如：分布式垃圾收集 (Distributed garbage collection)、成批传送消息(Boxcarring or batching of messages)、对象引用 (Objects-by-reference（which requires distributed garbage collection）)、对象激活 (Activation（which requires objects-by-reference）)。 　　自从SOAP规范从去年发布以来， SOAP规范的加密性，认证和授权等安全机制一直受到人们的广泛关注。这三个方面对于任何的B2B来说都是很重要的 ，但SOAP标准在制定规范时并没有过多考虑SOAP 的安全性要求。因为SOAP一个很重要的设计目标就在于它的简单性，尽可能的利用已有的标准和协议来实现相应的功能，而不是另起炉灶，重新定义一个崭新的协议，如果这样的话，会大大的降低它的实用性和兼容性。 　　安全性是个复杂的问题，在最低层SOAP 消息可通过 HTTPS 传递， 通用 SSL 传输信息，这就确保被编码消息内容可以避免被窃听，也确保客户端和服务器可互相验证身份。尽管 HTTPS 解决了对窃听者屏蔽消息的问题，但不能满足安全性更高的特殊用户认证的特定 Web 服务的要求。比如下面需要SOAP安全的几个场景，仅仅依靠SSL的安全机制是不满足信息的安全要求的： 　　端对端的信息传送（End-to-end messaging）。SOAP消息可以与不同的运输层协议（如HTTP，SMTP等）捆绑在一起进行传输，传输的过程中可能经过一系列中间设备或应用程序，假如应用程序对SOAP消息进行恶意破坏，可以在SOAP消息插入一系列相似的头元素，再传给下一个中间设备或程序，从而破坏了信息的完整性。在这种情况之下，中间设备或应用程序是不值得完全信任的，它们随时可以修改传输的信息。因此，SSL/TLS并不能保证端到端传输的安全性。 　　中间件的独立性（Middleware independence）。在应用层中保证端对端的安全要求，如果在传输中的传输的消息是平文，而不是是经过加密 的密文，极易受到黑客的攻击。但假如在应用程序中进行安全加密的处理，需要用户对加密算法有详细的了解，有许多不同的加密算法适合不同的安全要求，这对于用户来说是额外的负担。因此，标准的，安全的，独立的，透明的运输层是必要的，在SOAP中进行适当的安全扩展，保证了中间件应用程序的独立性，不用考虑过多的加密算法细节。 　　传输的独立性 （Transport independence）。 SOAP消息在传输的时候可以与不同的运输层协议进行捆绑，如HTTP，SMTP协议，有可能存在这么一个场景，所有的通信连接是安全的，中间层应用程序也是值得信赖的，但是，安全信息需要经过两个运输层协议，比如前一段是经过HTTP协议传输，在下一个阶段，则需要通过SMTP协议进行传输，两者之间的转换是烦琐的，易出错的。因此，在SOAP中加入扩展信息，保证了运输层的独立性，从而使与运输层无关。 　　驻留信息的安全性。运输层可以进行安全传输，但不能保证信息驻留时也是安全的。假如消息保存后继续向前传输，驻留信息的安全十分重要。在电子商务中，常常要求用户填写帐号和密码，这些信息通常保留在本地的COOKIE中，对于这些持久保存的信息进行加密，可通过SOAP的安全扩展来实现。 　　在目前应用最广泛的INTERNET，运行着许多基于TCP/IP协议的应用。由于TCP/IP协议本身的不安全性，造成了这些应用的不安全性。如：几乎所有的数据在网络上都是明文传输和用户在网络上的身份仅通过IP地址表现。由