.Net/CLR Security Discussion
Late last week I was in contact with an internal team which had trouble with their ASP.Net application. The issue was that when their webpage set impersonation to true, the impersonated identity did not flow across threads like it was supposed to. This behavior was a change from last summer's Beta1. So what's changed? In Beta 2 the ExecutionContext will only flow impersonation tokens set in managed code. ASP.Net does not do this, and therefore when the ExecutionContext was captured and placed on a new thread, the impersonation did not flow.
Performance and reliability were the main reasons for many of the changes to the ExecutionContext since Beta 1. Luckily there's a very easy way around this - take a look at the code sample below
using (WindowsIdentity.GetCurrent().Impersonate())
{
ThreadPool.QueueUserWorkItem(new WaitCallback(MyCallback), someObject);
}
In the ASP.Net scenario, there's already an impersonation token on the thread, but there's no associated managed object for it. Calling Impersonate on the current WindowsIdentity object will ensure that the identity is flowed across to the new thread. This is a bit of a "gotcha" - and I spent a couple hours trying to figure out why this was happening before I tried this solution - hopefully this will save someone the effort in the future.
Anonymous comments are disabled
