问题 ASP .NET中的Thread.CurrentPrincipal.Identity - 使用安全


在我的AuthenticateRequest事件处理程序中,我设置了Thread的主体。这是我的IHttpModule的一部分:

    public void Init(HttpApplication context)
    {
        context.AuthenticateRequest += AuthenticateRequest;
    }

    private void AuthenticateRequest(object sender, EventArgs e)
    {
        var principal = CreatePrincipal();
        HttpContext.Current.User = principal;
    }

但我有一个程序集,不应该访问System.Web,所以我不能使用HttpContext.Current.User,但我需要访问当前主体。我的第一个想法是将我的方法改为:

System.Threading.Thread.CurrentPrincipal = HttpContext.Current.User = principal;

并在需要时使用Thread.CurrentPrincipal。

但据我记得,在线程本地存储中存储请求特定的东西是不安全的,因为多个线程可以处理相同的请求,所以我猜它是相同的 Thread.CurrentPrincipal中。或不?


1617
2017-10-30 13:30


起源

听起来你可以改变组件 - 是不是可以传递它需要工作的主体? - Damien_The_Unbeliever
在最近的类似情况下,我只是强迫调用者提供主要对象。 - asawyer
这就是我要做的事 - 注入校长。无论如何,我希望有更好的方法 - dragonfly


答案:


我不同意Jeff Moser的回答。

标准的.NET授权内容都可以使用Thread.CurrentPrincipal。例如。:

PrincipalPermissionAttribute
PrincipalPermission.Demand

此外,如果您配置.NET RoleProvider,它将设置 Thread.CurrentPrincipal 与...相同的原则 HttpContext.User

因此,这是执行此操作的标准方法,我会在您的自定义身份验证代码中执行相同的操作(甚至更好 - 将其实现为自定义RoleProvider)。

至于异步I / O, 这篇博文 说明 Thread.CurrentPrincipal 和文化设置会自动传递给新线程。

运用 Thread.CurrentPrincipal 如果您的库使用委托人进行授权,可以说更安全,因为不受信任的代码可以作为参数传递主体,而CAS可能会阻止它设置 Thread.CurrentPrincipal


12
2017-10-30 14:10



谢谢你的链接!我没有意识到ASP.NET为你做了那件事。我会删除我的答案。 - Jeff Moser
实际上它是有道理的。我在整个应用程序中使用像PrincipalPermission这样的授权属性,显然这些属性在幕后使用Thread.CurrentPrincipal。非常感谢! - dragonfly