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

建立上下文：WS-SecureConversation

有时，解决一个问题所要求的全部过程只是一个或两个 SOAP 消息的简单交换。例如，调用一个远程操作可能只要求这种简单的交换。但是，假设一个应用程序可能需要通过调用一系列操作来与其他某个应用程序交换大量的 SOAP 消息。在这种情况下，在两个应用程序之间创建某个类型的共享安全上下文会非常有用。这种共享上下文的一个常见用法是，为将用于上下文周期的加密密钥定义一个生存期。例如，通讯双方可能希望创建一个对称密钥，然后使用它来加密通过特定安全上下文的生存期进行交换的信息。（这种非 Web 服务的一个示例就是 SSL，它能够创建一个对每个会话中所传输的字节进行加密的新密钥。）

WS-SecureConversation 定义了 XML 类型和交互，以允许建立安全上下文和创建特定于此上下文的密钥 — 即，只用于特定会话的密钥。这些机制的基础是 <SecurityContextToken> 元素。正如该规范所定义的那样，每个安全上下文都具有一个名称和共享的机密，因此 <SecurityContextToken> 可包含 <Identifier> 子元素，以唯一地指定这个上下文以及用于该上下文的一个或多个加密密钥的名称。

WS-SecureConversation 定义了创建 <SecurityContextToken> 的三种可能的方法。第一，可以从某些安全令牌服务请求 <SecurityContextToken>。要实现这个目的，请求方在正文中向安全令牌服务发送包含 <RequestSecurityToken> 元素的 SOAP 消息，如同请求普通的安全令牌一样。服务通过 SOAP 消息进行响应，消息正文包含 <RequestSecurityTokenResponse> 元素，该元素又包含所请求的 <SecurityContextToken> 和 <RequestedProofToken>，而这二者又包含这个新上下文的共享机密，例如已加密的对称密钥。

第二，可由通讯的其中一方创建 <SecurityContextToken> 并将其发送到另一方。在这种情况下，<SecurityContextToken> 的创建者在包含 <RequestSecurityTokenResponse> 的 SOAP 消息中发送新的令牌。（开始不发送 <RequestSecurityToken>）。这个消息与前面示例中从安全令牌服务获得的消息相同，因此它包含有新的 <SecurityContextToken> 和 <RequestedProofToken>。

第三，可以通过将使用该上下文的双方之间的协商来创建 <SecurityContextToken>。其中一方向另一方发送包含 <RequestSecurityToken> 的 SOAP 消息，然后接收包含 <RequestSecurityTokenResponse> 的响应。虽然这不是必需的，但是这种交换可能会依赖先前描述的 WS-Trust 定义的质询/响应协商过程。如果协商成功，其结果是双方都以新的 <SecurityTokenReference> 和 <RequestedProofToken> 结束。

无论是通过什么的方法创建，安全上下文始终包含共享的机密，例如对称密钥。虽然这个密钥可直接用于消息加密或签名，但是 WS-SecureConversation 不建议这样做。相反，从安全上下文的共享机密中派生一个或多个密钥，然后使用派生的密钥进行通讯，是一种更为安全的方法。本规范基于传输层安全性 (TLS) 规范中使用的方法，来定义一个用于创建派生密钥的算法。也可以使用其他方法来生成派生密钥，因为规范并没有要求使用它所定义的算法。

一旦创建了安全上下文，所需的全部操作就是标识每个 SOAP 消息中的上下文。由于上下文存在某种提示，因此通讯的每一方都已经知道要使用哪个（或哪些）密钥来处理这个消息。有了上下文以后，使用它的 SOAP 消息的 Security 元素将包含具有该上下文唯一标识符的 <SecurityContextToken> 元素。通过对这个标识符进行检查，消息的接收方就可以确定所使用的安全上下文。

如今，在 SSL 和 Kerberos 中的使用表明，与其他安全技术相比，安全上下文是较好的；WS-SecureConversation 使得它们能够在 Web 服务应用程序中使用。

使用 SAML 和其他基于 XML 的令牌

正如本文前面所述的那样，WS-Security 定义了两个用于表示安全令牌的 XML 元素。但是其他类型的令牌是怎么样的呢？尤其是已经使用 XML 定义的安全令牌？WS-Security 本身并没有说明这种类型的令牌应当如何表示，因此一个称为 Web Services Security Profile for XML-based Tokens 的规范对这个问题进行了修正。它定义了将根据 XML 的安全令牌与 WS-Security 结合使用的一般方法，然后指定了如何使用这两种现有类型的 XML 令牌。

这个规范声明的第一类 XML 安全令牌是使用安全声明标记语言 (SAML) 定义的。虽然 SAML 可能是相当普及的技术，但理解它具有重要的意义。（如果您是一位失眠症患者，则 SAML 规范的副本所起的作用就像不能进入睡眠时所施的入睡魔法。）正如其名称所示，该语言允许您表达有关诸如人或应用程序等主题的广泛声明。这些声明可以有关身份验证（如何才能完成）、授权（是否赋予对特定资源的访问权）或其他内容。尽管这不是必需的，但可以使用 XML 签名对声明本身进行身份验证。

SAML 声明可以直接插入 SOAP 标头的 <Security> 元素中，而不是定义另一种类型的安全令牌元素。与 Kerberos 票据或 X.509 证书不同，SAML 声明已经以 XML 进行了表述，因此易于使用。稍微简化的结果如图 7 所示。如本示例所示，SAML Assertion 元素可以原始形式插入到 Security 元素中。尽管本示例中没有显示，但 AssertionID 属性可用于将这个 SAML 安全令牌与该 SOAP 消息中的数字签名或其他内容相关联。

由 Web Services Security Profile for XML-based Tokens 规范声明的其他类型的 XML 安全令牌是 XrML。XrML 允许您表达有关数字内容或服务的权限，例如访问特定 Web 服务或播放特定音频文件的权限。它定义了一个 <license> 元素，该元素可以通过与 SAML <Assertion> 相同的方式插入到 SOAP 标头的 Security 元素中。

SAML 和 XrML 是相对较新的技术，因此您可能暂时还没有看到用于 SOAP 的这些选项。然而，随着时间的推移，其中一种或两种技术都可能会变得非常普及，也可能会出现其他基于 XML 的令牌。提供用于在 SOAP 消息中包含这些令牌的标准方法很有意义。

小结

有效的安全性对于 Web 服务至关重要。倘若已经拥有大多数所需的技术（问题仅仅是将这个现有的安全技术映射到 XML 和 SOAP），您可能会认为 WS-Security 及其关联的规范非常简单（本文可能就会非常简练）。然而，要适应目前使用的多种多样的安全机制，以及为将来出现的新技术留有余地，则要求有一组重要的技术。一旦出现这种技术，我们所有人都希望见到的安全和可互操作的 Web 服务就会成为现实。虽然我们彼此都不了解，但我仍然迫切盼望这一天的到来。

上一页  [1] [2] [3] [4]