本文档已存档,并且将不进行维护。

会话管理

Windows Identity Foundation

客户端首次尝试访问信赖方托管的受保护资源时,必须先向信赖方信任的安全令牌服务 (STS) 证明自己的身份。 然后,STS 向客户端颁发安全令牌。 客户端向信赖方出示此令牌,然后信赖方向客户端授予访问受保护资源的权限。 然而,您并不希望客户端必须针对每个请求重新向 STS 证明自己的身份,特别是因为客户端甚至可能与信赖方不在同一台计算机或同一个域中。 而 WIF 会让客户端和信赖方建立一个会话,在该会话期间,对于第一个请求之后的所有请求,客户端使用会话安全令牌向信赖方证明自己的身份。 信赖方可以使用这个会话安全令牌(存储在 Cookie 内)重新构建客户端的 IClaimsPrincipal。 有关详细信息,请参阅WS-联合身份验证模块概述中的“WSFAM 的工作原理”一节。

STS 定义了客户端必须提供的身份验证。 然而,客户端可能拥有多个凭据,客户端可以使用这些凭据向 STS 证明自己的身份。 例如,客户端可能拥有来自 Windows Live 的令牌、用户名和密码、证书以及智能密钥。 在这种情况下,STS 会向客户端授予多个标识,每个标识与客户端所出示的凭据之一相对应。 信赖方可以使用一个或多个上述标识来决定向客户端授予何种级别的访问权限。

SessionSecurityToken 用于重新构建客户端的 IClaimsPrincipal,它包含 ClaimsIdentityCollection 中的所有客户端标识。 该集合中的每个 IClaimsIdentity 包含与该标识相关联的引导令牌。

如果颁发的新会话令牌与原始会话令牌具有相同的会话 ID,则 SessionSecurityTokenHandler 不会更新令牌缓存中的会话令牌。 因此,始终应使用唯一会话 ID 来实例化会话令牌。

note注意:
ReadToken 在收到无效输入时会引发 XmlException 异常;例如,在包含会话令牌的 Cookie 已损坏的情况下。 我们建议您捕获此异常,并提供应用程序特定的行为。

如果受保护的网页中包含大量资源(如小图),而且这些资源也位于受保护的域中,则客户端必须重新向信赖方证明自己的身份才能下载每个资源。 使用会话身份验证令牌时,就不必针对每个请求都向 STS 证明自己的身份,但仍需要发送许多 Cookie。 您可能希望对网页进行设置,以便将重要数据和资源存储在受保护的域中,而将次要内容存储在不受保护的域中,并通过主页链接到这些次要内容。 另外,将 Cookie 路径设置为仅引用受保护的域。

扩展性

您可以扩展会话管理机制。 原因之一是为了提高性能。 例如,您可以创建自定义 Cookie 处理程序,用于在内存中状态和进入 Cookie 的状态之间转换或优化会话安全令牌。 为此,可以将 SessionAuthenticationModuleCookieHandler 属性配置为使用从 CookieHandler 派生的自定义 Cookie 处理程序。ChunkedCookieHandler 是默认 Cookie 处理程序,这是因为 Cookie 超过超文本传输协议 (HTTP) 所允许的大小;如果您使用自定义 Cookie 处理程序,则必须实施分块功能。

显示: