Thread.CurrentPrincipal is not set in WCF service called using WebGet

This is an interesting question. I don't have the same setup as you, so its difficult to test whether my recommendations will apply exactly to your use case, but I can share what has worked for us with similar projects.

How we keep Thread.CurrentPrincipal and HttpContext.Current.User in Sync

We wrote an HttpModule called "AuthenticationModule" which inherits from IHtppModule.

We then attached to the HttpApplication.AuthenticateRequest event which happens very early in request lifecycle.

In our AuthenticateRequest event handler, we implement our application specific requirements including setting Thread.CurrentPrincipal and if necessary also the current context user. In this way you only implement this code once for your entire application and if it changes (like if you implement a custom Principal IIDentity) you have only one place to change it. (Don't duplicate this code in every service method.)

public class AuthenticationModule : IHttpModule{    public void Dispose() { return; }    public void Init(HttpApplication app)    {        app.AuthenticateRequest += new EventHandler(app_AuthenticateRequest);    }    void app_AuthenticateRequest(object sender, EventArgs e)    {        HttpApplication app = (HttpApplication)sender;        // This is what you were asking for, but hey you         // could change this behavior easily.        Thread.CurrentPrincipal = app.Context.User;    }}

Ours is actually a bit more complex as we implement a custom IIdentity, create an instance of GenericPrincipal and then assign it to both app.Context.User and Thread.CurrentPrincipal; but, the above is what you were asking for.

Don't forget to register your new HttpModule in your web.config!

For integrated app pools:

<system.webServer>    <modules>      <add name="AuthenticationModule" type="YourNameSpace.AuthenticationModule" preCondition="integratedMode" />    </modules></system.webServer>

For old classic app pools you'd have to put it in <system.web><httpModules></httpModules></system.web>

You might need to play with what goes inside that AuthenticationRequest event handler and/or the order with which you register the handler. Because ours is totally custom it might be different than what you need. We actually grab the Forms Authentication cookie, decrypt it, etc... you might need to ping some built in methods for WindowsAuthentication.

I believe this is a more generic way to handle your application authentication stuff as it applies to all HttpRequests whether that be a page request, an IHttpHandler, some 3rd party component, etc... That will keep it consistent throughout your app.

I'm not sure. Maybe this will help

<configuration>  <system.web>    <identity impersonate="true" />  </system.web></configuration>

http://msdn.microsoft.com/en-us/library/134ec8tc(v=vs.80).aspx