Using SSRS Webservice inside another Thread

Question

I am calling the SQL Server Reporting Services Webservice from inside an asp.net application. I need to fire off all the subscriptions for a given report. But I don't want the user to have to wait around for it to all happen, so I want to have all the webservice calls inside a separate thread, and return to the user straight away.

I am using code that looks something like this:

public static void FireAllAsync(string ReportPath)
{
    Hashtable paramValues = new Hashtable();
    ThreadPool.QueueUserWorkItem(new WaitCallback(FireAll), ReportPath);
}

public static void FireAll(object ReportPath)
{

    ReportingService rs = new ReportingService();
    rs.Credentials = System.Net.CredentialCache.DefaultCredentials;

    Subscription[] SubList = rs.ListSubscriptions((string)ReportPath, null);

    foreach (Subscription CurSub in SubList) {
        rs.FireEvent(CurSub.EventType, CurSub.SubscriptionID);
    }

}

Calling FireAll works fine, but trying to call FireAllAsync to use the Thread fails with a 401 error. I believe the problem with the credentials not getting passed through properly. ie this line of code here:

rs.Credentials = System.Net.CredentialCache.DefaultCredentials;

I do not have a good understanding of how the credentials cache works, so I can't figure out why it doesn't like being in a separate thread.

I have tried grabbing the credentials in the outer function, and passing them through as an argument, but the same error occurs.

Does anyone have any ideas what may be happening?

Answer 1

When your primary thread is executing, it has an impersonation context prepared for it. In an authenticated scenario, IIS has authenticated the user, and then set the thread token - not the process token - for that user.

Because the thread token is set for the user, that thread can then act on behalf of the user (on the local box; acting on behalf of the user on another box requires delegation to be set up if Integrated Windows Authentication (NTLM/Kerberos) is used).

But, if you spin off a worker thread without any identity information, that worker thread will be spawned without its own token, so it'll use the process token.

If you can do what you need to do on the initial thread, you don't have a delegation problem, just a lack of the user token on the worker thread.

Threadpool threads will run as the process identity (NetworkService by default, so the computer account of the hosting machine, unless your App Pool is set to run as SomeUser, in which case all worker threads will run as SomeUser) - and if that user has access to whatever it is the initial user wants, all is good.

If not, 401sville.

There are web references that can help work around this, with various possible answers:

http://geekswithblogs.net/khanna/archive/2005/02/09/22441.aspx

http://aspalliance.com/articleViewer.aspx?aId=650&pId=2