增强 Web 服务安全性的新技术-软件开发-技术专栏-GIS空间站

摘要：如果没有良好的安全性，Web 服务将永远不能发挥它的潜能。本文重点讨论了 WS-Security 及其相关的技术，它们代表了 Web 服务安全性的未来。本文对这些新兴的安全标准进行了概述，并对这些安全标准的作用、工作方式和协作形式进行了说明。讨论的主题包括完整性、保密性以及如何通过公钥加密、WS-Security 和其他技术来实现完整性和保密性。本文还讨论了一些关键的 WS-Security 组件，例如 wsu 命名空间。

完整性

使用 SOAP 消息进行传输和身份验证是一个多方面的问题，可能存在多种解决方案。因此，WS-Security 采用了一种非常广泛的方法。但是，更明确的一点是要为 SOAP 消息提供完整性。解决方案是使用某种类型的数字签名。幸运的是，已经有了针对该领域的 W3C 标准。该标准称为 XML 签名，它为数字签名 XML 文档提供了详细的机制。WS-Security 没有彻底改造已有标准，而是简单地利用现有规范，并就如何在 SOAP 消息中使用这些规范提出了一些具体细节。

XML 签名规范定义的主要内容是 <Signature> 元素，该元素的内容包括数字签名本身以及有关如何生成该签名的信息。虽然已经有了一些方案，但一个典型的 <Signature> 实例与 SOAP 中使用的相同，也包含 <SignedInfo> 和 <KeyInfo> 元素。

<SignedInfo> 元素描述正在进行签名的信息。该元素本身包含多个子元素，每个子元素都指定了一些有关已签名信息的内容。其中最重要的子元素包括以下元素：

倘若了解 XML 签名的 <Signature> 元素的这种基本特性，就可以理解 WS-Security 是如何使用该元素的。图 2 是包含数字签名的 SOAP 消息形式的一个示例。

在本例中，标头的 <Security> 元素以 <BinarySecurityToken> 开头。该元素与前面部分中所示的 X.509 证书示例几乎完全相同。唯一的区别在于，该元素使用由 Web Services Security Addendum 定义的 Id 属性来为该 <BinarySecurityToken> 提供名称。（请查看补充文章“wsu 命名空间”，以获得详细信息。）此处的 Id 属性值为“X509Cert”，从标头的其他位置可以引用该属性值。您不久将会看到，当消息中也包含数字签名时，这个特性非常有用。

接下来是由 XML 签名标准定义的 <Signature> 元素，包括前面描述的几个子元素：<SignedInfo>、<SignatureValue> 和 <KeyInfo>。<SignedInfo> 元素内包含用于对该 XML 文档进行标准化以及创建其数字签名的算法的标识符。<Reference> 元素具有一个 URI 属性，可以准确指定正在进行签名的内容。在本示例中，仅对正文进行了签名，因此，这个 URI 与消息的 <Body> 元素所关联的 Id 属性值相匹配。Reference 元素也包含两个子元素：<DigestMethod> 和 <DigestValue>。其中第一个子元素标识用于创建这个数字签名的消息摘要的算法，而第二个子元素包含消息摘要值本身。由于在本例中仅对正文进行了签名，因此，这个摘要是从 SOAP 消息的 <Body> 元素的标准化版本中计算得出的。

接下来的 <Signature> 子元素 <SignatureValue> 包含数字签名本身的字节，该数字签名通过使用签名者的私钥对消息摘要进行加密创建的。最后是 <Signature> 中的最后一个子元素 <KeyInfo>，它标识验证这个签名应使用的公钥的位置。在本示例中，消息中先出现那个密钥（在安全令牌中），然后通过 <SecurityTokenReference> 进行引用。使用该密钥的 Id 属性 "X509Cert" 对其进行标识。

对于许多 Web 服务应用程序，确保数据完整性至关重要。具有一种经过良好定义并被广泛接受、可为 SOAP 提供这种服务的方法也非常有用。由于提供有效的签名和受信任的证书证明了专用私钥的知识，对于身份验证，使用公钥技术创建的数字签名也非常有用，验证某人的身份亦是如此。然而，在实际应用中创建 XML 文档的数字签名并不是最简单的事情。准确地说，必须首先标识要进行签名的内容，然后进行标准化，再进行实际签名。由于 WS-Security 允许为相同的消息创建多个签名，每个签名可能由消息途径中不同的接收方所创建，并且每个签名可能传输消息的不同部分或存在重叠的部分，因此，它可能比此处所示的示例要复杂得多。根据 W3C XML 签名标准来构建所有这些内容非常有意义，但是使用这种 WS-Security 的 SOAP 标头一定会比那些不需要特定安全服务的要大得多、复杂得多。

保密性

对于许多重要的应用程序来说，防止数据在传输中被人窥探，并确保其安全性非常重要。因此，WS-Security 定义的第三个服务是保密性，它提供了一种在 SOAP 消息传输之前对其进行部分加密或全部加密的方法。WS-Security 的设计者以同样的方式解决了完整性问题，他们选择了在现有保密标准的基础上构建保密性，而不是创建全新的标准。他们再一次从 W3C 的现有标准中选择了一个称为 XML 加密的规范。通过该标准，WS-Security 允许对 SOAP 消息的标头信息、正文以及任何附件进行部分加密或全部加密。XML 加密规范并不是一种十分复杂的文档。例如，WS-Security 仅使用了由该标准定义的三个 XML 元素：<EncryptedData>、<EncryptedKey> 和 <ReferenceList>。

其中最重要的自然是 <EncryptedData>。正如其名称所示，该元素包含在子元素中称为 <CipherData> 的实际加密数据。该元素也可包含指示所使用的加密算法的子元素、加密所使用的密钥以及其他内容。图 3 显示了一个示例，说明发送方选择对按 WS-Security 定义的消息正文进行加密时，一个简单的 SOAP 消息的形式。

首先注意消息中没有出现 SOAP 标头。尽管这在实际应用程序中是不可能的，但可能使用由 WS-Security 定义的 XML 加密，而不含有 Security 元素或任何其他 Header 元素。在这个简单的示例中，消息正文仅包含一个带有三个子元素的 <EncryptedData> 元素。其中第一个子元素 <EncryptionMethod> 指示加密数据时所使用的算法。在本示例中，选择了对称算法 TripleDES，并且使用相同的密钥来加密和解密数据。接下来的子元素是从 XML 签名中借用的 <KeyInfo>。此时，假设双方均已知道可以在加密和解密中使用的所有密钥，因此，唯一要做的就是通知选定的接收方。虽然密钥可以使用任意名称，但是也可以使用 LDAP 风格的识别名称来命名密钥。因此，该示例指定密钥名为“CN=Key13, C=US”。无论使用何种名称，重要的是双方均可以准确地了解该名称所引用的密钥。最后是 <CipherData> 子元素，它在其 <CipherValue> 子元素中带有实际加密数据的 base64 编码。

也可能在相同的消息中传输加密的密钥，这个消息带有使用该密钥进行加密的数据。当使用对称密钥加密数据时，就经常会出现这种情况，如图 3中的 TripleDES 示例所示，然后使用消息接收方的公钥对对称密钥进行加密并随数据一道发送。消息到达时，接收方可以使用其私钥解密嵌入的对称密钥，然后使用该对称密钥对实际数据进行解密。为了发送加密的密钥，XML 加密定义了一个带有识别名 <EncryptedKey> 的元素。为了与 SOAP 消息一起使用，WS-Security 指定了该元素应当出现在 <Security> 标头中。因此，带有加密数据和读取该数据所需的加密对称密钥的 SOAP 消息可能如图 4 所示。

与图 3中虚拟的简单示例不同，图 4 中的 SOAP 消息包含了带有 Security 元素的标头。这个元素只包含在 XML 加密标准中定义的 <EncryptedKey> 子元素。<EncryptedKey> 的格式与 <EncryptedData> 的格式非常相似，在此示例中，它具有三个熟悉的子元素：<EncryptionMethod>、<KeyInfo> 和 <CipherData>。此处要进行加密的是对称密钥，因此，<EncryptionMethod> 描述的是如何对该密钥进行加密，而不是如何对实际数据进行加密。由于我们一直假设这是使用接收方的公钥进行加密的对称密钥，因此，该元素指示对这个密钥进行加密时使用的 RSA 算法。<KeyInfo> 元素指定作为此 <EncryptedKey> 的一部分进行传输的对称密钥的名称，并且由于我们假设该密钥与前面示例中的相同，因此，它具有相同的名称。与先前的 <EncryptedData> 元素不同，此 <EncryptedKey> 中的 <CipherData> 元素包含加密的对称密钥，而不是任何用户数据。

<EncryptedKey> 元素还具有 <EncryptedData> 中所没有的一个新的子元素。该元素 <ReferenceList> 在将这个密钥与使用其进行加密的数据相关联的过程中发挥了重要作用。它包含一个标识该 SOAP 消息部分的 URI，该消息是使用 <EncryptedKey> 元素中包含的密钥进行加密的。在图 4 中，整个 SOAP Ìå都使用这个密钥进行加密，因此，使用了一个相当刻板的名称“EncryptedBody”。

SOAP 体本身的形式与图 3中所示的非常类似。一个区别是，<EncryptedData> 元素的开始标记现在具有一个名为“EncryptedBody”的 Id 属性。如上所述，这就是将这个元素包含的数据与用于对该数据进行加密的密钥相关联的方法。其他区别是，由于已经明确地标识出用于对这个元素的内容进行加密的密钥，因此不需要 <EncryptedData> 中的 <KeyInfo> 元素。

按照 WS-Security 定义，对 SOAP 消息使用 XML 加密的方式有多种。您可以对整个正文、正文和某些标头元素、仅正文的某些部分或者随消息一道发送的附件进行加密。SOAP 消息的不同接收方可以添加自己的加密标头，或解密并处理他们预期的部分。由于 Web 服务中对保密性的要求是多样化的，因此定义如何实现保密性的标准必须是完全通用的。

虽然 WS-Security 在规定使用 SOAP 提供安全性的基础方面做了许多有用的工作，但它并不是面面俱到的。因此，制定了许多其他规范来填补其中的一些空白。下面来看看他们定义的这些文档和技术。

http://www.gissky.net- GIS空间站

增强 Web 服务安全性的新技术

完整性

保密性

Tags：Web 服务,安全