段智华 (
[email protected])
2001 年 11 月
一：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地址表现。由于这两个原因，使得一些软件产品的安全工作形同虚设。比如一些网络应用通过网络将用户口令传输的服务方，由服务方验证用户的合法性。由于用户口令在网络上传输是明文的，它很容易被网络监听者获取。又如一些防火墙进行的IP过滤工作是通过IP数据包中的IP地址来实现的。实际上在NTERNET上伪造一个IP地址是相当容易的。SOAP协议基于运输层之上，有必要通过SOAP的扩展来增强SOAP的安全功能。因此，我们必须了解当前Internet网络面临哪些威胁，以及网络网络安全的要求是什么，这不仅仅是SOAP必须考虑的问题，也是其他基于Internet网络分布式应用程序必须考虑的，只有更好的了解各种无所不在的攻击手段和侵犯方式，才能更好的建立安全的防范机制。
二：互联网络的安全要求以及存在的安全威胁
总的来说，网络安全的五个基本的安全要求：
机密性(Confidentiality). 保证没有经过授权的用户，实体或进程无法窃取信息。在 一个开放的网络环境里,维护信息机密是全面推广应用的重要保障。因此,要预防非法的信息存取和信息在传输过程中被非法窃取。
授权：(Authorization.) 授权是确定允许用户做什么的过程。可将不同的特权给予不同类型的用户。例如，每个人都能阅读公共图书馆的联机卡片目录，甚至不必是该系统的认证用户。换句话说，所有用户都被授权可阅读目录。但系统可能会将借书的权限仅限于已认证用户，这里已认证是指持有此图书馆的有效借书卡。取决于认证机制的复杂程度，系统可能根据所持的卡来限制用户的特权。例如，可能授权某些用户可以借的书不限数量，而限制其他用户只能借一定数量的书籍。
数据完整性(Data integrity)：保证没有经过授权的用户不能改变或者删除信息，从而信息在传送的过程中不会被偶然或故意破坏，保持信息的完整、统一。因此,要预防对信息的随意生成、修改和删除,同时要防止数据传送过程中信息的丢失和重复
原始性证明（Proof of Origin.） 对信息或数据的发送者的进行标示。保证信息被经过标示的发送者所传送，从而避免以前的数据包被重复发送。
防止抵赖(Nonrepudiation): 保证信息的发送者不能抵赖或否认对信息的发送，当然信息发送前需要对发送者进行安全认证。要在信息的传输过程中为参与交易的个人、企业或国家提供可靠的标识。
最后的三个安全要求是彼此相关的，数据完整性与原始性证明的区别在于数据是完整的，并不能保证信息不被重复发送。换句话说，数据完整性不能防止反复攻击。哈希散列算法如 HMAC，认证时使用一个经过加密的密钥对于原始性证明来说是合适的，但并不适用于"防止抵赖"。
相应的，目前网络存在的威胁主要表现在以下几个方面：
非授权访问：没有预先经过同意，就使用网络或计算机资源被看作非授权访问。它主要有以下几种形式：假冒、身份攻击、非法用户进入网络系统进行违法操作、合法用户以未授权方式进行操作等。
信息遗漏丢失：指敏感数据在有意或无意中被泄漏出去或丢失。
破坏数据完整性：以非法手段窃得对数据的使用权，删除、修改、插入或重发某些重要信息，以取得有益于攻击者的响应；恶意添加，修改数据，以干扰用户的正常使用。
拒绝服务攻击：是一种比较简单，但又日益流行的攻击和禁用企业信息资源的方法。在拒绝服务攻击中，作恶者发送大量的信息流量，使 Web 服务器、主机、路由器和其它网络设备负担过重。通过这种方式发送的信息流量非常之大，致使企业的用户、客户和合作伙伴都在好长一段时间内无法访问网络。
基于以上的安全威胁以及网络安全的迫切要求，仅仅依靠SSL的安全机制不能解决所有的问题。SOAP安全的解决方案基于三个W3C的XML规范来实现：XML Digital Signature, XML encryption, and XML Key Management Services.。SOAP层安全处于传输层和应用层之上，对SOAP层的安全性进行扩展，把关于安全的五个基本要求应用到整个的SOAP信息中，包括SOAP头以及SOAP体。同时，更多的安全措施也可结合SOAP层安全与传输层以及应用程序 来共同解决。由于网络安全十分复杂，目前W3C正在尝试制定相应的规范，不断的完善和更新，下面介绍SOAP数字签名的一个草案.
三：SOAP 安全扩展: 数字签名
3．1 "SOAP Security Extensions: Digital Signature"这个文本目前只是W3C的讨论方案，正处于不断修改的过程中。提出此文本的最初设想是利用XML的数字签名（XML Digital Signature syntax [XML-Signature]）对SOAP进行扩展，在SOAP的头元素中定义签名属性（
）来实现。以下部分是我翻译了W3C的SOAP数字签名草案中的一部分，以供大家参考，如有不当之处，敬请大家指正。
工作组在SOAP头元素的扩展命名空间中加入安全特征，通过扩展，在方案中加入一个新的元素，这个元素在schema中可以不用改变。如果要在SOAP1.1协议的进行加密性扩展，可以在命名空间中引入适当的标准实现，
