Thread.CurrentPrincipal не установлен в службе WCF, вызванной с помощью WebGet

У меня есть веб-сайт, размещенный в IIS, который использует проверку подлинности Windows и предоставляет веб-службы WCF.

Я настраиваю эту службу с помощью поведения конечной точки:

<serviceAuthorization principalPermissionMode ="UseAspNetRoles" 
                   roleProviderName="MyRoleProvider"/>

и привязка:

 <security mode="TransportCredentialOnly">
    <transport clientCredentialType="Ntlm" />
 </security>

При вызове службы Thread.CurrentPrincipal устанавливается в RolePrincipal с идентификатором клиента и ролями, предоставленными сконфигурированным поставщиком.

Все хорошо с миром.

Теперь я добавил несколько дополнительных WCF-сервисов, которые используются REST-ful Ajax-вызовами: Factory="System.ServiceModel.Activation.WebScriptServiceHostFactory" в файле svc, WebGet в контракте на обслуживание и атрибут AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Allowed) в реализации службы.

Я также добавляю следующее заклинание в web.config, как рекомендовано в MSDN:

<system.serviceModel>
    ...
    <serviceHostingEnvironment aspNetCompatibilityEnabled="true" />
    ...
</system.serviceModel>

Моя служба Ajax почти работает так, как я ее хочу. Когда он вызывается, HttpContext.Current.User устанавливается в RolePrincipal с ролями, которые я ожидаю. Но Thread.CurrentPrincipal остается установленным не прошедшим проверку подлинности GenericPrincipal.

Поэтому мне нужно добавить строку кода в каждый из моих методов:

Thread.CurrentPrincipal = HttpContext.Current.User

Есть ли какое-либо заклинание в файле конфигурации, который я могу использовать для автоматического набора Thread.CurrentPrincipal, например, для нормальной службы SOAP?

UPDATE Вот блог от кого-то, у кого была такая же проблема, и решил его, внедряя пользовательские поведения. Наверняка есть способ сделать это из коробки?

ОБНОВЛЕНИЕ 2 Возвращаясь назад, чтобы добавить щедрость к этому, поскольку он снова прослушивает меня в новом проекте, используя службу WCF WebGet с поддержкой .NET 3.5.

Я экспериментировал с несколькими параметрами, включая настройку mainPermissionMode = "None", но ничего не работает. Вот что происходит:

• Я перехожу к URL-адресу WebGet, который вызывает мою службу: http://myserver/MyService.svc/...

• Я установил точку останова в Global.asax "Application_AuthorizeRequest". Когда эта точка останова ударяется, оба параметра "HttpContext.Current.User" и "Thread.CurrentPrincipal" были установлены в "RolePrincipal", который использует мой настроенный ASP.NET RoleProvider. Это поведение, которое я хочу.

• У меня есть вторая точка останова, когда вызывается мой метод OperationContract службы. Когда эта точка останова ударяется, HttpContext.Current.User все еще ссылается на мою RolePrincipal, но Thread.CurrentPrincipal был изменен на GenericPrincipal. Aaargh.

Я видел предложения реализовать пользовательскую IAuthorizationPolicy и будет изучать это, если я не найду лучшего решения, но почему следует ли мне реализовать пользовательскую политику для использования существующих полномочий авторизации ASP.NET? Если у меня есть mainPermissionMode = "UseAspNetRoles", конечно, WCF должен знать, что мне нужно?

Ответы

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;
    }
}

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

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