SOAP技术及安全性研究.docxVIP

-：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 消息插入一系列相似的头元素，再传给下一个中间设备或程序，从而破坏了信息的 完整性。在这种情况之下，中间设备或应用程序是不值得完全信任的，它们随时可 以修改传输的信息。因此，SSUTLS并不能保证端到端传输的安全性。 屮间件的独立性(Middleware independence)。在应用层屮保证端对端的安 全耍求，如杲在传输中的传输的消息是平文，而不是是经过加密的密文，极易受到 黑客的攻击。但假如在应用程序中进行安全加密的处理，需要用户对加密算法有详 细的了解，有许多不同的加密算法适合不同的安全要求，这对于用户来说是额外的 负担。因此，标准的，安全的，独立的，透明的运输层是必要的，在SOAP屮进行 适当的安全扩展，保证了屮间件应用程序的独立性，不用考虑过多的加密算法细节。 传输的独立性(Transport independence) o SOAP消息在传输的时候可以 与不同的运输层协议进行捆绑，如HTTP, SMTP协议，有可能存在这么一个场景, 所有的通信连接是安全的，屮间层应用程序也是值得信赖的，但是，女全信息需要 经过两个运输层协议，比如前一段是经过HTTP协议传输，在下一个阶段，则需要 通过SMTP协议进行传输，两者Z间的转换是烦琐的，易出错的。因此，在SOAP 屮加入扩展信息，保证了运输层的独立性，从而使与运输层无关。 驻留信息的安全性。运输层可以进行安全传输，但不能保证信息驻留时也是安 全的。假如消息保存后继续向前传输，驻留信息的安全十分重要。在电子商务屮， 常常要求用户填写帐号和密码，这些信息通常保附在本地的COOKIE屮，对于这些 持久保存的信息进行加密，可通过SOAP的安全扩展来实现。 在目前应用最广泛的INTERNET,运行着许多基于TCP/IP协议的应用。由于 TCP/IP协议本身的不安全性，造成了这些应用的不安全性。如：几乎所有的数据在 强上都是明文传输和用户在网络上的身份仅通过IP