SOAP安全性扩展：数字签名（SOAP-DSIG）定义了用数字方式签名SOAP消息及确认签名的句法和处理规则。本文讨论了SOAP-DSIG和SSL有着怎样的关系，并描述了这两项技术是如何互补的。

数字签名使初始用户和软件能够可靠地发送信息。可惜的是，简单对象访问协议（Simple Object Access Protocol，SOAP）1.1并不包括签名消息的规定，因此也无此安全性。我和我的同伴们曾建议在SOAP中加入数字签名技术（它随即被万维网联盟收录为SOAP-DSIG附注），来定义用数字方式签名SOAP消息以及确认签名的句法和处理规则。该技术从此被应用到了IBM、Microsoft以及其它公司外发产品中。

然而SOAP-DSIG必须使用安全套接字层（Secure Sockets Layer，SSL），这是一种在Web站点中得到了最广泛运用的安全性技术。因此我们应该提出这样一个问题：SOAP-DSIG和SSL有着怎样的关系？这两项技术的区别又是什么呢？

本文回答了这些问题，并描述了这两项技术是如何在各自的不足之处与对方实现互补的。同样，由于HTTP（也就是HTTP上的SOAP）应用相当广泛，因此本文将主要把HTTP作为传输层进行重点讨论。然而，您应当注意，SOAP和SOAP-DSIG都是独立于传输而存在的，因而能在其它传输协议上使用，如SMTP、FTP以及MQ。在使用其它传输协议时，您需要了解SOAP-DSIG与那个传输层（例如，SMTP中的S/MIME）中相应的安全性有着怎样的关系，这也是我稍后将在本文中说明的内容。

介绍
尽管HTTP最初只是作为一个传输HTML文档的协议开发的，而现在您通过Web站点上的CGI脚本或Java Servlet就能用它来订购产品和服务。在因特网上订购产品时，您可能需要发送信用卡号码等的个人信息。然而，您应该只把该信息以安全的方式发送给值得信任的HTTP服务器，这样就没有敌对的第三方能截获并窃取该信息了。开发SSL就是为了解决这些保密性和服务器身份验证问题的，它现已得到了广泛使用。

与这些企业对客户（B2C）的应用不同，在企业对企业（B2B）的应用中，不是由人用浏览器来显示HTML文档，而是由计算机来处理订单。且比如商品订单等数据可能会用XML而不是HTML格式进行描述，并通过HTTP和SOAP进行交换。

SOAP是一个用来交换任意XML文档的标准消息传递层，也是Web服务的主要构件之一。除了SOAP以外还有其它相关技术，如通用描述、发现和集成（Universal Description，Discovery and Integration，UDDI）以及Web服务描述语言（Web Service Description Language，WSDL），但本文并不想讨论这些技术。（需要关于在本文中提及的技术的链接，请参阅参考资料部分。）

在开发基于SOAP的Web服务和B2B应用时，安全性问题仍然很重要。特别是在企业间的商业交易中，不可抵赖性的安全性要求需要得到满足。SOAP-DSIG就是针对这个目的提出的。本文回答了下列问题：什么是不可抵赖性？SOAP-DSIG和SSL是如何结合起来以实现不可抵赖性的？

消息传送的安全性要求
每一个SOAP消息都有一个SOAP信封和SOAP编码。SOAP信封是一个能用来装载任何XML文档的数据结构。SOAP编码被用于将非XML数据编码为XML文档，这样它就能被装在SOAP信封中进行传输了。通常，这一编码旨在用于类似远程过程调用（RPC）的应用中。由于本文中主要讨论的是SOAP信封，而并不直接涉及SOAP编码，因此它适用于任何一种基于SOAP的应用，包括RPC和B2B应用。

在开始部分，我将概述一下从一台计算机（发送方）到另一台计算机（接收方）的消息传输的一般安全性要求。确切地说，我将谈到消息身份验证、发送方/接收方身份验证以及不可抵赖性。请注意，这里所描述的安全性要求并不是SOAP所专有的，它们能适用于任何种类的消息传输。

第一个要求就是机密性加密。由于机密性要求是通过使用SSL来满足，而不是由SOAP-DSIG解决的，因此本文中将不作讨论。我所关注的安全性要求是身份验证。请考虑一下下面两个问题：

●从发送方的角度来看：在发送消息的时候，目标接收方的身份是如何得到验证的呢？
●从接收方的角度来看：在接收消息时，发送方的身份和消息的内容是如何得到验证的呢？
在这里，我将身份验证看作是两种安全性要求的结合。一种是消息创建者的身份验证，它被称为消息身份验证。另一种是发送方和接收方身份的验证，它被称为发送方/接收方身份验证。在可能存在不可靠或恶意的计算机的网络环境中，消息的创建者和消息的发送方不总是相同的。例如，一旦有恶意的一方以某种方式窃取了由发送方创建的合法消息，该消息就有可能被转发给任何人。因此，这一差异就很重要。

这两种类型的身份验证牵涉到以下几个方面：

●消息身份验证：
消息身份验证保证了被传输的消息不会在途中被修改，且消息创建者的身份不会被冒用。通常，消息身份验证能通过在被传输的消息中附加一个数字签名或者消息身份验证代码（Message Authentication Code，MAC）来实现。在这里您需要注意的是消息身份验证无法保证是谁发送了该消息。
●发送方/接收方身份验证：
发送方及接收方身份验证保证了发送方和接收方分别就是他们所声称的人。也就是说，发送方能够确认其意愿中的消息接收方的身份，而接收方能确认消息发送方的身份。请注意，发送方/接收方身份验证无法保证是谁创建了该消息。
在下一部分中，我将概述一下实现以上两项安全性要求的安全性技术。

消息身份验证技术
正如上文所提到的，为满足消息身份验证的要求，用到了两项通用技术：消息身份验证代码（Message Authentication Code）和数字签名。这里列出了它们的一些优缺点。

●消息身份验证代码（Message Authentication Code，MAC）：
SSL将MAC附加到被传输的消息中，SOAP-DSIG也能用来附加MAC。由于MAC的计算要比数字签名快，因此它对于诸如SSL等数据传输量很大的传输层安全性来说是实用的。然而，由于MAC是通过一个在发送方和接收方之间共享的密钥来进行计算的，因此它只能保证被传输的消息不是由发送方就是由接收方创建的。换句话来说，从某个第三方的角度来说，您无法确定该消息究竟是由发送方创建的还是由接收方创建的。
●数字签名：
SOAP-DSIG的最初动机是在SOAP消息中附加数字签名。特别地，SOAP-DSIG定义了向SOAP消息中附加XML签名的数据格式。由于数字签名是建立在公用密钥密码术基础上的，因此计算一个数字签名所花的时间往往要比计算一个MAC长得多。而由于发送方和接收方不再需要共享一个密钥，因此您就能识别消息创建者的身份了，也就是说，它保证了签名者就是创建者。
发送方/接收方身份验证技术
发送方/接收方身份验证有两种广泛使用的技术。请注意，HTTP客户机（服务器）可以是发送方也可以是接收方。

●密码身份验证：
这是个应用广泛的机制，事实上Amazon.com就使用了这种机制。典型的示例包括HTTP基本身份验证以及基于表单的身份验证。它可以用于发送方身份验证，在这种情况下HTTP客户机应该用来发送消息。HTTP客户既能通过发送其身份及密码向HTTP服务器证实自己的身份。由于密码需要保密，因此通常用SSL来发送。
●SSL服务器/客户机身份验证：
这是一种基于HTTP服务器和客户机的公用密钥证书对它们的身份进行双向验证的技术。SSL服务器身份验证特别在因特网上得到了广泛的应用，例如在Amazon.com。另一方面，SSL客户机身份验证是可选的，目前也尚未应用在很多Web站点上。然而，在某些公用密钥证书被分发给了每个帐户持有者的情况下，比如在在线交易中，SSL客户机身份验证就会被用来验证帐户持有者的身份。
就安全性来说，密码身份验证无法与SSL身份验证进行直接的比较。但是由于SSL需要公用密钥证书以及相应的专用密钥（它们必须被签发并得到管理），因此管理一个基于密码身份验证的系统要比管理一个基于SSL身份验证的系统要容易一些。因为密钥的撤销及更新必须有一个证书撤销列表（Certificate Revocation List，CRL），所以对于发布与管理公用密钥证书以及相应的专用密钥的要求也会变得越来越高。

什么是不可抵赖性？
除了以上两项安全性要求以外，不可抵赖性也是B2B应用中相当重要的一个要求。对不可抵赖性的需求因恶意发送方而引起。不可抵赖性保证了恶意发送方无法在事后抵赖其创建并发送特定消息的事实。这就意味着不可抵赖性保证了消息的发送方与消息的创建者为同一人。

例如，假设甲企业创建并发送了一个购买订单给乙企业。当乙企业处理了订单并