I disagree with Jeff Moser's answer.
The standard .NET authorization stuff all works using Thread.CurrentPrincipal. e.g.:
PrincipalPermissionAttribute
PrincipalPermission.Demand
Also, if you configure a .NET RoleProvider, it will set Thread.CurrentPrincipal
to the same principal as HttpContext.User
.
Therefore this is the standard way to do it, and I would do the same thing in your custom authentication code (or even better - implement it as a custom RoleProvider).
As for asynchronous I/O, this blog post states that Thread.CurrentPrincipal
and culture settings are automatically passed to the new thread.
Using Thread.CurrentPrincipal
is arguably more secure, if your library is using the principal for authorization purposes, because untrusted code can pass in a principal as an argument, while CAS might prevent it from setting Thread.CurrentPrincipal
.