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

指定策略：WS-SecurityPolicy

只要使用安全机制，就必须存在某些类型的安全策略。这些策略阐明了针对特殊情况的特定安全要求。例如，对于使用 WS-Security 的 Web 服务，许多细节都需要详细说明。这种服务是否接受用于身份验证的 Kerberos 票据、X.509 证书以及数字签名，还是别的什么东西？接受哪种数字签名算法？支持使用哪些加密算法来提供保密性？回答此类问题就意味着定义了安全策略。

当然，除了安全性以外，策略在其他领域中也非常有用。因此，Microsoft、IBM 和其他公司联手创建了 WS-Policy 规范。这个文档定义了一种为 Web 服务指定各种策略的一般方法。WS-SecurityPolicy 以此为基础，定义了可用于指定安全相关策略的 XML 元素。由于这些元素允许 Web 服务明确地指定其策略，因此它们被称为声明。由 WS-SecurityPolicy 定义的声明包括以下几种。

• <SecurityToken> 允许 Web 服务指定它将接受哪些类型的安全令牌以及它所信任的令牌发行方（可选）。

• <Integrity> 允许 Web 服务指定它将接受的有关数字签名的多种选项，例如用于创建消息摘要的算法。

• <Confidentiality> 允许 Web 服务指定有关应如何执行加密的选项，例如所使用的加密算法。

• <Visibility> 允许 Web 服务指定消息的哪些部分必须进行解密。

WS-SecurityPolicy 没有定义如何准确地从设计者向任何感兴趣的客户端传输安全策略。表示策略的 XML 元素可以通过 SOAP 消息发送，也可以通过其他方式传输。但是 WS-Policy 定义了一个通用的 <Policy> 元素，它可以包含一个或多个策略声明。以下是一个简单的示例，它说明了对于要求使用 Kerberos 票据进行身份验证的 Web 服务，<SecurityToken> 声明的形式：

<wsp:Policy 
 xmlns:wsp="http://schemas.xmlsoap.org/ws/2002/12/policy
 xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/12/secext">       
 <wsse:SecurityToken wsp:Usage="wsp:Required">
  <TokenType> wsse:Kerberosv5ST</TokenType>
 </wsse:SecurityToken>
</wsp:Policy>
 

该 <Policy> 元素指定了在 WS-Policy 和 WS-Security 中定义的命名空间，并且只包含 <SecurityToken> 子元素。该子元素的使用被标记为 Required，这意味着 Web 服务需要遵守这个策略。换句话说，正如 元素所指示的那样，这个特定的 Web 服务现在只接受 Kerberos 票据作为身份验证的基础。

单个的 <Policy> 元素可以包含有关安全令牌、完整性以及其它方面的策略。还有几个其他选择，包括指定相关首选项的方法。例如，Web 服务可以定义一个 <SecurityToken>，允许客户端使用 Kerberos 或 X.509 证书进行身份验证的 <SecurityToken>，然后指出优先使用 Kerberos。但是，无论使用哪种方案，策略值都是显而易见的。通过提供一种明确的方法以便 Web 服务声明其安全要求，它们使客户端能够明白要访问该服务所必须做的事情。

获得安全令牌：WS-Trust

安全令牌是 WS-Security 的基础，但是它们只是魔法般地出现，并没有定义分发它们的机制。事实是，正如已经存在的各种安全令牌一样，能够分发它们的软件服务已经存在。例如，要获得 Kerberos 票据，可以与 Kerberos 密钥发行中心 (KDC) 联系；要获得 X.509 证书，则可以与证书颁发机构 (CA) 联系。尽管 WS-Security 定义了如何在标准 XML 内包装 Kerberos 票据和 X.509 证书以便在 SOAP 消息中进行传输，但它没有定义使用 SOAP 与 KDC、CA 或者能够分发安全令牌的任何其他服务进行交谈的方法。

WS-Trust 修正了这个问题。这个规范定义的主要内容是从一些安全令牌服务（例如 KDC 或 CA）请求安全令牌的机制。图 5 对这一观点进行了解释。假设客户端希望调用 Web 服务 A 和 Web 服务 B，并进一步假设 Web 服务 A 需要 Kerberos 票据进行身份验证，而 Web 服务 B 需要数字签名以及相匹配的 X.509 证书。如图所示，客户端可能会首先向安全令牌服务 X（实际上是 KDC）发出 SOAP 请求，以请求包装在 <BinarySecurityToken> 内部的 Kerberos 票据。然后调用 Web 服务 A，将最新获得的令牌传递给 SOAP 消息的 <Security> 元素。接下来，客户端可以向安全令牌服务 Y（即 CA）发出 SOAP 请求，以请求 X.509 证书。在证书返回后，客户端就可以调用 Web 服务 B，以同时传递这个证书和匹配的数字签名。

WS-Trust 定义了向安全令牌服务进行请求的形式，以及如何返回响应。这种交互依赖于两个元素：<RequestSecurityToken> 和 <RequestSecurityTokenResponse>。其基本思想是发送包含 <RequestSecurityToken> 作为其正文的 SOAP 消息，然后获得包含 <RequestSecurityTokenResponse> 的 SOAP 消息以及新的安全令牌。图 6 显示了请求消息的一个简单示例。

Security 标头包含了一个 <UsernameToken>，以便对这个请求进行身份验证 <UsernameToken>。尽管在通过加密的 SSL 连接发送请求时，此处使用的简单选择可能是合理的，但是以明文形式发送这个请求可能要求同时包含数字签名和时间戳的更健壮的安全令牌。消息正文包含请求颁发 X.509 证书的 <RequestSecurityToken> 元素。假设请求成功，由安全令牌服务返回的响应正文可能如下所示：

<s:Body>
 <wsse:RequestSecurityTokenResponse>
<wsse:RequestedSecurityToken>
   <wsse:BinarySecurityToken 
     ValueType="wsse:X509v3" 
     EncodingType="wsse:Base64Binary">
     KkFPle ...        
   </wsse:BinarySecurityToken>
  </wsse:RequestedSecurityToken>
 </wsse:RequestSecurityTokenResponse>
</s:Body>
 

请求的证书被返回，它包装在由 WS-Security 定义的 <BinarySecurityToken> 元素中。虽然在示例中没有显示，但是也可能会返回与这个证书的公钥相关联的私钥。要允许这种情况，WS-Trust 定义了一个 <RequestedProofToken> 元素，以这样或类似的包含其他类型安全令牌的信息。

WS-Trust 还对基本的 <RequestSecurityToken> 元素定义了相当多的扩展。其中包括用于请求在构建所请求的安全令牌时使用的特定算法和密钥大小的选项。例如，请求方可以要求：应该使用带有 1024 位密钥的 RSA 算法来创建数字签名。除了请求方之外，还有一个代表某人请求安全令牌的机制。第三个扩展提供了一个指定安全令牌生存期以及该生存期是否可以更新的方法。

WS-Trust 还定义了在向安全令牌服务请求安全令牌时，可以选择使用的质询/响应机制。尽管在某些情况下，直接的身份验证机制（如图 5 中所示的机制）可能很好，但是安全令牌服务可能会需要有关正在交谈一方的更多证据。如果像上面的示例中那样，请求中没有包含时间戳会怎么样？安全令牌服务如何才能确定这不是先前请求的重发，而是由攻击者发送的请求？为了避免出现这种情况，安全令牌服务可能会要求请求方对一组特定的信息进行数字签名，然后在发出被请求的安全令牌之前验证该签名。