WIF基本原理(3)安全令牌服务

WIF基本原理(3)安全令牌服务

安全令牌服务(STS)是用于根据WS-TrustWS-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实现之前,先回顾一些基础知识。在主动联合中使用 STSWS-Federation主动请求者配置文件和(主要)WS-Trust 规范实现。

从较高层次看,WS-Trust使用四种服务操作来描述一个约定:颁发、验证、续订和取消。客户端分别调用这些操作来请求安全令牌、验证安全令牌、续订已过期安全令牌以及取消不应再继续使用安全令牌。根据WS-Trust 规范,每个操作都必须以请求安全令牌”(RST) 格式发送消息,并以RST 响应”(RSTR) 格式返回消息。在本节中,假定颁发令牌是安全声明标记语言SAML 1.1SAML 2.0令牌。

15-4展示主动令牌颁发时RSTRSTR核心内容。

WIF基本原理(3)安全令牌服务

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却在STS URL中被分解为查询字符串参数,而RSTR通常会作为表单参数被发布到 RP被动STSRP使用联合Web处理程序来截取这些参数。被动STS可以直接处理WS-Trust 请求,或者将其传递到底层WS-Trust实现。图15-5说明在被动联合方案中对 RST RSTR 处理方式。

WIF基本原理(3)安全令牌服务

15-5  被动联合方案令牌颁发

主动与被动联合方案一个本质差异在于颁发 SAML令牌类型。主动联合通常依靠使用密钥所有者”(holder-of-key) 类型主体确认 SAML令牌,这意味着前面所述,在实际当中存在着一个证明密钥,它可以证明发出令牌进行验证客户端是请求该令牌(也称为ActAs行为)主体。被动联合方案通常涉及带有持有者”(bearer) 类型主体确认 SAML令牌(也称为持有者令牌)。这种类型令牌不包含证明密钥,有时也称为无密钥令牌。它依靠传输来确保从 STS获得该令牌并将其传递给 RP

简单主动联合方案如图15-6所示。

WIF基本原理(3)安全令牌服务

15-6  使用单一RP 和主动 IP-STS 简单联合方案

如图所示,通常存在以参与者:

q  RP,由客户端调用服务。

q  单独 STS(也作为服务实现),支持 WS-Trust 协议。此 STS将对调用方进行身份验证并颁发具有标识调用方声明安全令牌,也称为标识提供者或 IP-STS

q  客户端,在本例中为基于 Windows应用程序,它依靠代理对 STS进行身份验证、检索令牌颁发结果以及发送消息给 RP(它会提供用于身份验证和授权颁发令牌)。

15-7说明在此实现中可以灵活设置部分。

WIF基本原理(3)安全令牌服务

15-7  自定义主动STS和主动IP-STS实现体系结构

图中包括自定义SecurityTokenService 实现、使用 ServiceHost 扩展 (WSTrustServiceHost) 初始化用于联合运行时、使用 WSTrustContract 类型派生配置一个或多个 WS-Trust 端点以及用于标识模型运行时相关配置设置。

声明转换

声明转换对于联合安全性至关重要:它可能在联合过程中任意时刻发生。在 IP-STS RP 属于同一域简单联合方案中,IP-STS 负责将声明从身份验证期间用户所提供一组初始身份标识声明转换 RP 能够用以授权调用声明。用户可以为 IP-STS 提供任何支持凭据类型来进行身份验证,其中每个都会评估一组代表该凭据声明。

IP-STS 将这些声明转换成一组标准应用程序声明,RP 可以通过这组声明授权调用,它们可以是角色或更精细声明,如创建、读取、更新或删除等权限。图15-8对这种方案进行说明,其中Admin用户登录并被授予 Role 声明和几项 Action 声明,其中包括创建、读取、更新和删除等。

WIF基本原理(3)安全令牌服务

15-8  IP-STS 声明转换

这种类型声明转换非常有用,因为对 STS身份验证会得到一个令牌,其中包含授予该用户所有声明。也有一些情况需要使用其方法进行声明转换;例如为减少颁发给那些仅与当前调用上文相关声明、为保护声明隐私性,或者为促进跨域联合等。

向经过验证调用方授予RP 公开所有功能,既无必要,也不合适。这不但会使声明列表变得非常长,而且很多列表中的功能不符合当前环境的上下文,因此在不具备该上情况不应授予该声明。例如,某用户正在与客户进行订单交互,只授予Delete声明即可,但如果正直接与客户记录交互,则不应授予该权限。

在其一些类似情况中,如果 RP 能够只从 IP-STS 请求少量声明即可标识调用方,然后使用一组特定仅适用于该调用上附加声明来请求一个新令牌,则将会非常有帮助。例如,用户正在 RP 服务中调用 DeleteCustomer 操作,在授权执行此操作之前,RP 将会调用从 IP-STS 传入令牌 RP-STS,并在 DeleteCustomer 操作文中请求 Delete 声明。如果该声明存在,则调用将获得授权。图15-9说明此示例。

WIF基本原理(3)安全令牌服务

15-9  RP-STS 声明转换

此外,有时还存在 STS颁发声明不应与 RP 直接共享情况。例如,可以不必通过颁发 Age 声明来使 RP 解用户年龄,RP 可以请求 IsOver13 声明来确保调用方年龄符合使用 RP 功能条件。这样可以确保 Age 声明实际值不会离开 STS。当然,这也表明 ST 将提供既能避免共享个人详细信息又可以包含 RP 所需数据声明。

当属于一个域用户被授予对另一个域中RP 访问权限时,联合方案中也会发生声明转换。在这种情况会涉及两个 STS:用户域 IP-STS RP 所属域 RP-STS

同样也是在这种情况IP-STS 会授予一些 RP-STS 能够理解且达成一致声明;但这些声明可能无法在 RP 应用程序中直接使用。相反,RP-STS 可能会负责将另一组可信声明转换为能够被 RP 域所理解声明。

15-10说明这种方案。

WIF基本原理(3)安全令牌服务

15-10  联合方案中声明转换

如图所示,当 Joe 试图在没有令牌情况访问 RP 时,将登录到自己所在域(域 B IP-STS。该请求将申请 RP 能够理解声明(在本例中为 RPClaim),以便 IP-STS 知道应该颁发 RP 能够使用令牌。当 RP-STS 接收到此令牌后,它将把该声明转换 RP 专用声明。为使此联合方案能够工作,必须在 RP-STS IP-STS 之间建立信任关系,而且它们必须对 IP-STS 应该为其用户颁发将被授予对 RP 访问权限一组声明达成一致。

对于那些热衷于构建自定义STS而又不需要STS平台全部功能(如Geneva服务器)用户而言,WIF框架是非常实用的工具。但即便使用WIF框架,构建自定义STS也不是一项简单任务,建议尽量使用完整功能STS以减少出现安全漏洞风险。

-----------------------------注:本文部分内容改变自《.NET 安全揭秘》

 

你可能感兴趣的:(安全)