设置自定义主体/身份的最佳位置在哪里？

Question

我一直在开发一个网站（使用 ASP.NET C#），该网站同时使用基于表单和基于声明的身份验证。我想重写 ClaimsIdentity 类，以便可以实现自定义 IsAuthenticated 方法，并为特定于声明身份验证的身份添加更多属性。

我当前正在实现一个自定义 WSFederationAuthentionModule，但我试图找出应该重写哪个模块（具体来说是什么方法），以便我可以设置自定义身份/主体而不是默认的 ClaimsPrincipal？

到目前为止，我已经查看了 SessionAuthenticationModule 和 ClaimsPrincipalHTTPModule，但我无法弄清楚主体在哪一步设置/覆盖它的最佳方法。

谢谢

补充： 由于我在这方面是新手，请确保这是正确的：设置身份的方法是设置一个自定义主体，该主体被设置为使用该身份：

System.Threading.Thread.CurrentPrincipal = customClaimsPrincipal;

或者，如果不需要自定义主体，则 ClaimPrincipal 类可以使用 ClaimsIdentityCollection 构建。

Answer 1

您可以在多个地方执行此操作，但如果您使用 SessionAuthenticationModule，则某些过程没有很好地记录下来，这可能会使使用自定义主体变得棘手。本答案的其余部分解释了使用 SessionAuthenticationModule 时处理此问题的一种可能方法。

重写 SessionAuthenticationModule.SetPrincipalFromSessionToken 方法。

SessionAuthenticationModule 将安全令牌、主体、身份和声明存储在 cookie 和内存缓存中，以避免每次请求时都必须往返身份提供程序/令牌服务。没有很好地记录的是缓存的存在以及它是第一个检查的地方，然后是 cookie，以及序列化 ClaimsPrincipal 的限制。

如果您已在 ClaimsAuthenticationManager.Authenticate 中设置自定义主体，并且缓存完好无损，则您的自定义主体很可能已经存在，因为缓存存储本机 .NET 对象。如果您尚未设置自定义主体，或者未填充缓存，则将从 FedAuth 会话 cookie 中检索安全令牌。

当令牌被序列化到 cookie 或从 cookie 反序列化时，该过程使用自定义序列化，该序列化只能读取和写入 IClaimsPrincipal 和 IClaimsIdentity 接口（或ClaimsPrinicpal 和 ClaimsIdentity 类 - 我不记得是哪个）。将不包括任何自定义主体和身份对象属性。可以覆盖序列化，但这需要几层（3 IIRC）类覆盖。

您还需要注意，基本 SetPrincipalFromSessionToken 方法会创建一个新的 ClaimsPrincipal 对象并将其设置在线程和上下文上，因此即使 >sessionSecurityToken 参数包含自定义主体对象，它将被转换回 ClaimsPrincipal 对象。

下面是一个示例重写方法：

protected override void SetPrincipalFromSessionToken(SessionSecurityToken sessionSecurityToken)
{
    SessionSecurityToken newToken = MyClaimsPrincipalUtility.CreateCustomClaimsPrincipalToken(sessionSecurityToken);

    base.SetPrincipalFromSessionToken(newToken);

    //the following lines need to be set after the base method call, because the base method overwrites the Principal object
    HttpContext.Current.User = newToken.ClaimsPrincipal;
    Thread.CurrentPrincipal = newToken.ClaimsPrincipal;
}

基类 (SessionAuthenticationModule) 实现如下所示。因此，您可以通过几种不同的方法来实现覆盖并获取自定义声明主体。

protected virtual void SetPrincipalFromSessionToken(SessionSecurityToken sessionSecurityToken)
{
    IClaimsPrincipal fromIdentities = ClaimsPrincipal.CreateFromIdentities(this.ValidateSessionToken(sessionSecurityToken));

    HttpContext.Current.User = (IPrincipal) fromIdentities;
    Thread.CurrentPrincipal = (IPrincipal) fromIdentities;

    //tracing code removed

    this.ContextSessionSecurityToken = sessionSecurityToken;
}

以防万一您想知道，这里是 SessionAuthenticationModule.ContextSessionSecurityToken 的基类实现。

public virtual SessionSecurityToken ContextSessionSecurityToken
{
    get
    {
        return (SessionSecurityToken) HttpContext.Current.Items[(object) typeof (SessionSecurityToken).AssemblyQualifiedName];
    }
    internal set
    {
        HttpContext.Current.Items[(object) typeof (SessionSecurityToken).AssemblyQualifiedName] = (object) value;
    }
}

Answer 2

您是正确的，HttpModules 是可扩展性方面的最佳选择，但请确保您实现的任何逻辑都不会抑制应用程序的性能。在向应用程序添加太多 HttpModule 后，我的网站在性能方面彻底陷入疯狂。缓存查询结果可能是值得的，具体取决于您使用的身份验证模型。

您需要弄清楚在什么条件下需要使用自定义的 ClaimsPrincipal。在你这样做之前，你就是在黑暗中刺伤。是否存在需要声明身份验证的特定 URL？