使用信任链的联合
在这种方法中，Currency 服务将接受带任何安全性令牌的请求，但它不处理请求，除非它可以获得基于提供的安全性令牌（和证明）的 Business456 安全性令牌。
为做到这一点，Currency 服务将初始请求转发给评价初始安全性令牌的 Business456 安全性令牌服务。如果该令牌有效，它认可该请求，并且可以为 Alice 包括进一个 Business456 安全性令牌以供后面的请求使用。下图演示了这个过程。
图 16. 使用信任链的联合
在这种方法中，Business456 安全性令牌服务被配置为接受 Adventure456 签发的带身份声明的安全性令牌。
使用安全性令牌交换的联合（PKI - Kerberos）
在这种方法中，Adventure456 已向 Alice 签发了一个公用密钥安全性令牌，并且 Currency 服务的策略指出它只接受来自它的 KDC 的 Kerberos 安全性令牌。
按照 Currency 服务的策略的指示，Alice 向 Business456 的安全性令牌服务出示（且证明）她的公用密钥安全性令牌。这个安全性令牌服务封装了 Business456 的 KDC。结果，它能够验证 Alice 的公用密钥安全性令牌并签发了一个用于 Currency 服务的 Kerberos 安全性令牌。下图中演示了这个过程。
图 17. 使用安全性令牌交换（PKI - Kerberos）的联合
在这种方法中，Business456 安全性令牌服务被配置为接受 Adventure456 签发的带身份声明的公用密钥安全性令牌。
使用安全性令牌交换（Kerberos - 安全性令牌服务）的联合
在这种方法中，Adventure456 已向 Alice 签发了一个 Kerberos 安全性令牌，并且 Currency 服务的策略指出它只接受它自己的安全性令牌服务签发的安全性令牌。
这里我们假设 Adventure456 和 Business456 的管理员们为联合安全性已经交换了公用密钥证书。我们进一步假设 Alice 只支持对称密钥技术。
根据 Currency Web 服务的策略，Alice 需要获得一个可用于访问 Business456 处的安全性令牌服务的安全性令牌。因为 Alice 使用的是对称密钥安全性令牌，Alice 首先联系她的安全性令牌服务以获取为 Business456 安全性令牌服务准备的安全性令牌。注意，这个安全性令牌将包含一个与 Business456 安全性令牌服务的公用密钥编码在一起的对称密钥，Sab。
使用为 Business456 安全性令牌服务准备的安全性令牌，Alice 请求一个用于 Currency 服务的安全性令牌。Business456 安全性令牌服务向 Alice 提供了一个对称密钥 Sac 和一个用于 Currency 服务的安全性令牌。
使用为 Currency 服务准备的安全性令牌和相关的对称密钥，Alice 向 Currency 服务发送了一个请求。
图 18. 使用安全性令牌交换（Kerberos - 安全性令牌服务）的联合
使用凭证交换（Kerberos - Kerberos）的联合
在这种方法中，Adventure456 已经向 Alice 签发了一个 Kerberos 安全性令牌，并且 Currency 服务的策略声明它只接受封装它的 KDC 的它自己的安全性令牌服务签发的 Kerberos 安全性令牌。
这里，我们假设 Adventure456 和 Business456 处的管理员不想建立跨域的传输信任，但为了联合安全性，想交换公用密钥证书。我们进一步假设 Alice 和 Currency 服务都只支持对称密钥技术。
就象前面的示例中那样，安全性令牌服务有能力向它们信任域内的服务提供对称密钥安全性令牌。所以，上面描述的这种方法在这个案例中是可行的。
图 19. 使用凭证交换（Kerberos - Kerberos）的联合
验证服务
10 这个 Web 服务安全性模型还支持这样的案例，在这个案例中，请求者外包（outsource）处理消息和安全性令牌验证。应该注意误用这种服务会导致可伸缩性问题。也就是说，根据实现，服务执行验证服务的代价可能更便宜，也可能更昂贵。Web 服务安全性模型支持其中一种方法，因此可以使该案例成功。
在这个案例中，我们已经将验证服务与安全性令牌服务分开了。在其它案例中，它们可以组合在一起或者具有直接信任关系（因此不需要 WS-Federation）。
图 20. 与安全性令牌服务分开的验证服务
在这个案例中，请求者从安全性令牌服务获得了一个安全性令牌。然后它将消息发送给 Web 服务并在消息中包括了所有权证明（例如，一个签名）。Web 服务发送签名块、安全性令牌和计算出的已签名的摘要给验证服务。然后，Web 服务信任的这个验证服务发出一个有效／无效决定。
应该注意，验证服务可以通过签发一个代表声称正确声明的请求者的安全性令牌来表明它的决定。
支持委托
11 Web 服务安全性支持委托。下面是用来显示这种方法的灵活性的一个复杂的委托案例：Alice 使用 calendar456 管理她的日程。她希望允许 Bob 在周二为她安排一次会议。但是，Bob 并不直接安排时间。Bob 而是使用服务 schedule456 来安排需要放在 Alice 日程上的会议。
Alice 并不知道 Bob 将如何安排会议的日程，但她希望限制可以看到她的日程的一组服务。
图 21. 信任委托
Alice 向 Bob 提供了一个安全性令牌，这个令牌使 Bob 能够根据她的日程安排会议。这个安全性令牌包含限制 Bob 将会议安排到周二的声明。而且，只要主题（一个或多个）能够证明它们有一个来自 TrustUs456（一个第三方服务）的隐私权证明，这个安全性令牌就会使 Bob 能够签发后继的安全性令牌。
既然服务 schedule456 已经被 TrustUs456 审核过了，那么它们就有了一个声明它们的隐私权证明的安全性令牌。
当日程服务在 calendar456 处访问 Alice 的日程时，它可以验证它的隐私权证明的所有权证明及其访问声明，并根据来自 Alice，通过 Bob，到达它自身的安全性令牌安排会议日程。
访问控制
在一起工作时，Alice 和 Bob 发现他们经常要互相协商会议的时间并建立一种信任级别。因此，Alice 希望允许 Bob 安排会议时间而不必每次都委托他。她可以增加委托安全性令牌的期限，但需要重新签发那些令牌，如果她想废除 Bob 安排会议日程的能力，这就会比较麻烦。
图 22. 访问控制
Alice 与她的日程服务通信（认证她自己）获得授权列表。她更新授权列表来允许 Bob 查看她的闲／忙数据、安排会议并将数据提交给服务。现在，当 Bob 为这些操作访问她的日程服务时，他不需要来自 Alice 的委托安全性令牌。
审核
12 在上面的委托案例中，有可能一个敌人尝试不用委托安全性令牌安排会议或者使用一个过期的安全性令牌安排会议。在这种情况下请求将失败，因为敌人无法证明所需的声明。
为跟踪这种类型的活动，服务可以提供审核功能。也即，当发生与安全性有关的事件，比如认证或者未证明的声明或者错误的签名时，就记录下来。管理员可以安全地访问日志来检查与安全性相关的事件并管理日志。
例如，敌人可能会努力假扮 Bob。使用监视器／管理工具，安全性管理员 Carol 查看审核日志时看到 Alice 的日程已经有了许多安全性失败记录。在查看数据时，她看到有时 Bob 的请求失败是因为他的签名与消息（一条或多条）不匹配，消息是旧的（被重用的）。于是 Carol 便收集审核记录以用于追查这些敌人。
图 23. 审核服务操作
总结
随着 Web 服务的应用日益广泛，随着应用程序拓扑继续发展到支持防火墙、负载平衡器和消息传递中心之类的中介体并且人们对组织所面临的威胁理解得更加深刻，对 Web 服务的增加的安全性规范的需要就变得更加明了。在这个文档中，我们提议了一个集成的 Web 服务安全性模型和一组用于实现该模型的规范。通过扩展和利用（而不是代替）现有的安全性技术和资产，这些新规范将使客户和组织能够更快速地开发安全的、互操作的 Web 服务。
IBM 和 Microsoft 相信这是定义一个全面的 Web 服务安全性策略的第一步。它将反映我们迄今为止已经确定的问题和解决方案。由于我们将继续与客户、伙伴以及标准组织合作来保护 Web 服务，我们希望会有使这个策略更加全面所需的其它思想和规范。
