This humble static property of the Thread class is central to the way role-based security works in the .NET Framework, as I show in HowToTrackClientIdentityUsingThreadDotCurrentPrincipal. It's used as a simple channel for communicating client identity and authorization information from plumbing to application developers. (Authentication is tricky, so we let frameworks like ASP.NET do this heavy lifting for us, and then we look for the results via this property.) Think of Thread.CurrentPrincipal as simply a hook that each thread exposes on which we can hang a user identity. It's just extra context information that the runtime helps us track.

I gave a security talk at Tech Ed 2003 in Dallas, and while I was there, a training company asked me to post some code in their booth as a quiz for developers walking by. So I posted the following code, which compiles just fine, and asked folks to enumerate what must be true about the system in order for the code to run without exceptions on Windows Server 2003. Here’s the code.

 // this process is running as Bob
 Thread.CurrentPrincipal = new WindowsPrincipal(new WindowsIdentity(@"DomainA\Alice"));
 new FileStream(@"c:\hello.txt", FileMode.Open,FileAccess.Read, FileShare.Read).Close();

It was interesting to see how many people thought that Alice, as opposed to Bob, had to have permissions to the file merely because I was setting Thread.CurrentPrincipal. It turns out that this property of a managed thread has no effect on how the Windows operating system perceives your code. This is not the same as impersonation (WhatIsImpersonation). Thread.CurrentPrincipal is simply a helpful property for keeping track of a principal, and is primarily used in server applications to track client identity. But the operating system knows nothing about it. So in my code Thread.CurrentPrincipal was a red herring — it's Bob who needs to be granted permissions to the file via an ACL.

One interesting property of Thread.CurrentPrincipal is that it propagates during asynchronous activities (well, usually it does, as you’ll see shortly). Say you're doing work on thread 101 for Alice and so Thread.CurrentPrincipal holds an IPrincipal that represents her. Now you make an asynchronous call through a delegate, using BeginInvoke. The worker thread that eventually calls through the delegate only does so after setting Thread.CurrentPrincipal for you. Thus role-based security continues to work even when you switch threads in this case. The same thing happens if you create a new thread: The CLR copies the Thread.CurrentPrincipal reference to the new thread for you. This is all based on the principle of least surprise, and it’s a good thing. Contrast this to the way impersonation works in the underlying operating system, where thread switches don't propagate the impersonation token.

As of this writing (version 1.1 of the .NET Framework), System.Threading.Timer is an asynchronous vehicle that doesn't propagate Thread.CurrentPrincipal. The same is true with ThreadPool.QueueUserWorkItem. So, if you use these low-level mechanisms, be sure to propagate Thread.CurrentPrincipal manually if you're using role-based security.

As an aside, the evidence-based security architecture in the CLR considers setting Thread.CurrentPrincipal to be a privileged operation¹. Partially trusted code likely will not be allowed to change this property. This makes sense, as plumbing like ASP.NET will always be fully trusted while application code such as ASPX pages may run under partial trust.

¹ The permission required is part of SecurityPermission. See SecurityPermissionFlag.ControlPrincipal.