difference between http.context.user and thread.currentprincipal and when to use them?

Question

I have just recently run into an issue running an asp.net web app under visual studio 2008. I get the error 'type is not resolved for member...customUserPrincipal'. Tracking down various discussion groups it seems that there is an issue with Visual Studio's web server when you assign a custom principal against the Thread.CurrentPrincipal.

In my code, I now use...

HttpContext.Current.User = myCustomPrincipal
//Thread.CurrentPrincipal = myCustomPrincipal

I'm glad that I got the error out of the way, but it begs the question "What is the difference between these two methods of setting a principal?". There are other stackoverflow questions related to the differences but they don't get into the details of the two approaches.

I did find one tantalizing post that had the following grandiose comment but no explanation to back up his assertions...

Use HttpConext.Current.User for all web (ASPX/ASMX) applications.

Use Thread.CurrentPrincipal for all other applications like winForms, console and windows service applications.

Can any of you security/dot.net gurus shed some light on this subject?

Answer 1

The first thing that the HttpApplication object does when it acquires a thread is to set the thread's principal to the HttpContext's principal. This syncs up the principals.

If, however, you go and set the Thread's principal later on, the HttpApplication internally still has a different principal set for the user context. This is why you should always set it through the HttpContext.

(If you take a look in Reflector, you can see the complex code that runs when you do a "set" on HttpContext.User - it does a lot of internal stuff with IIS to properly set the principal.)