安全令牌服务(STS)是用于根据WS-Trust和WS-Federation协议构建、签署和颁发安全令牌的服务组件。实施这些协议需要进行大量的工作，但WIF能为你完成所有这些工作，让那些不精通协议的人不费吹灰之力即可启动并运行STS。可以使用云STS（如LiveID STS）、预先构建的STS（如ADFS 2.0），或者如果想要颁发自定义令牌或提供自定义身份验证或授权，可以使用WIF构建自定义的STS。借助WIF即可轻松地构建自己的STS。
STS身份验证支持多种方案：
q 从身份验证机制中分离出应用程序和服务，从而使其能够专注于授权相关声明。
q 支持多种凭据类型，而不会使应用程序和服务的实现变复杂。
q 支持联合方案，用户可以通过在自身的域中进行身份验证来获得对另一个域中资源的访问权限（通过建立不同域的STS之间的信任关系）。
q 简化标识委派方案，经过身份验证的用户将获得对下游服务的访问权限。
q 简化声明转换，使相关声明能够用于对应用程序和服务进行授权。
其中的任何方案都可以基于被动联合（基于浏览器）或主动联合（基于Windows客户端）。下面详细介绍这些方案，同时说明如何使用Geneva框架在自定义STS中构建相关逻辑。
主动联系与被动联合
在深入探讨STS的实现之前，先回顾一些基础知识。在主动联合中使用的STS是WS-Federation主动请求者配置文件和（主要）WS-Trust 规范的实现。
从较高层次看，WS-Trust使用四种服务操作来描述一个约定：颁发、验证、续订和取消。客户端分别调用这些操作来请求安全令牌、验证安全令牌、续订已过期的安全令牌以及取消不应再继续使用的安全令牌。根据WS-Trust 规范，每个操作都必须以“请求安全令牌”(RST) 的格式发送消息，并以“RST 响应”(RSTR) 的格式返回消息。在本节中，假定颁发的令牌是“安全声明标记语言”SAML 1.1或SAML 2.0令牌。
图15-4展示了主动令牌颁发时RST和RSTR的核心内容。
图15-4 主动联合方案的令牌颁发
如图所示，RST消息包括请求安全令牌所需的必要信息，其中涉及待颁发令牌的类型（本书中是SAML）、将要被纳入到颁发令牌中的“依赖方”(RP) 所请求的声明、有关RP (AppliesTo) 的信息（包括URL和通常用于标识RP的证书），以及将被用于RSTR所返回的“证明密钥”(proof key) 的可选（未显示）密钥材料。
如果令牌颁发成功，RSTR将包括颁发的SAML令牌和证明密钥（假定STS决定使用哪个证明密钥，因此必须在RSTR中返回它）。SAML令牌将包括已验证方的相关声明，它由STS签名来保护令牌不被篡改，令牌中将包含用于 RP 加密的证明密钥，并且它会为 RP 加密自身以确保只有目标接收节点才能处理该令牌。
客户端使用证明密钥来签署发往RP的消息。RP必须能够在 SAML 令牌中解密证明密钥，否则拒收该消息。如果令牌中的证明密钥与消息中的签名匹配，则证明此次对 RP 的调用是由请求该令牌的调用方所发送的。
被动联合方案基于WS-Federation 被动请求者配置文件，其中涉及基于浏览器的通信。虽然底层消息传递仍基于WS-Trust，但RST却在STSURL中被分解为查询字符串参数，而RSTR通常会作为表单参数被发布到 RP。被动STS和RP使用联合Web处理程序来截取这些参数。被动STS可以直接处理WS-Trust 请求，或者将其传递到底层WS-Trust实现。图15-5说明了在被动联合方案中对RST和RSTR 的处理方式。
图15-5 被动联合方案的令牌颁发