WCF-Dienst, der asynchron in ASP.NET verwendet den falschen Identitätswechsel

Dieser Artikel hilft Ihnen, das Problem zu beheben, bei dem ein wcf-Dienst (Windows Communication Foundation), der asynchron in ASP.NET aufgerufen wird, den falschen Identitätswechsel verwendet.

Ursprüngliche Produktversion:   Windows Communication Foundation
Ursprüngliche KB-Nummer:   2890435

Problembeschreibung

Stellen Sie sich folgendes Szenario vor:

  • Ein WCF-Dienst verwendet Identitätswechsel und Windows Authentifizierung.
  • Ein WCF-Client ruft den Dienst asynchron auf.
  • Der Clientcode wird unter der ASP.NET-Umgebung in Microsoft-Internetinformationsdienste (IIS) ausgeführt.

In diesem Szenario tritt möglicherweise ein Problem auf, bei dem der Dienstvorgang nicht unter dem beabsichtigten Identitätswechselkontext ausgeführt wird. Stattdessen wird der Dienstvorgang möglicherweise unter der Identität des Prozesses ausgeführt, z. B. einem IIS-Anwendungspool.

Hinweis

  • Wenn dieses Problem auftritt, wird keine Ausnahme ausgelöst, und aufgrund dieses Verlusts des Identitätswechselkontexts wird kein Fehler protokolliert.
  • Ein Beispiel für ein solches Szenario ist eine ASP.NET Anwendung, die so konfiguriert ist, dass der Kontext für den eingehenden Identitätswechsel asynchron an einen separaten WCF-Dienst delegiert wird.

Ursache

Dieses Problem tritt aufgrund der folgenden Faktoren auf:

  • Die Common Language Runtime (CLR) des Hosts unterdrückt absichtlich den Identitätswechselkontext, da ASP.NET nicht für den Fluss WindowsIdentity über asynchrone Vorgänge konfiguriert wurde.
  • Wenn der Clientcode automatisch geöffnet wird und sofort asynchrone Vorgänge für den WCF-Clientproxy aufruft, nachdem er erstellt wurde, wird der Identitätswechselkontext möglicherweise nicht ordnungsgemäß ausgeführt.

Lösung

Gehen Sie folgendermaßen vor, um dieses Problem zu beheben:

  1. Konfigurieren Sie ASP.NET für den Fluss WindowsIdentity über asynchrone Vorgänge hinweg. Stellen Sie hierzu sicher, dass für die aspnet.config Datei die folgenden Elemente festgelegt sind:

    <configuration>
        <runtime>
            <legacyImpersonationPolicy enabled="false"/> 
            <alwaysFlowImpersonationPolicy enabled="true"/>
        </runtime>
    </configuration>
    

    Hinweis

    • Diese Einstellungen müssen in der aspnet.config-Datei vorgenommen werden, da diese Einstellungen die CLR konfigurieren, die für den Anwendungspool verwendet wird. Einstellungen in web.config nur die einzelne Anwendung konfigurieren, nicht den Anwendungspool.
    • Stellen Sie sicher, dass Sie die entsprechenden aspnet.config für das installierte Framework ändern, %WINDIR%\Microsoft.NET\Framework64\v4.0.30319\Aspnet.config z. B. den Pfad.
    • Wenn Sie die aspnet.config Datei(n) für den Server ab IIS 7 nicht ändern können, können Sie jedem Anwendungspool eine benutzerdefinierte aspnet.config zuordnen. Weitere Informationen finden Sie im Abschnitt "Weitere Informationen".
  2. Fügen Sie dem Clientcode einen expliziten Open() Aufruf hinzu. Nachdem Sie eine Instanz eines WCF-Clients erstellt haben, rufen Sie die Open() Methode auf, bevor Sie Vorgänge asynchron aufrufen. Gehen Sie z. B. wie folgt vor:

    // Invoke a service operation asynchronously with impersonation.
    static async void Demo()
    {
       using (CalculatorClient client = new CalculatorClient())
       {
          // Enable the server to impersonate.
          client.ClientCredentials.Windows.AllowedImpersonationLevel = TokenImpersonationLevel.Impersonation;
          // Open the client before the first asynchronous request.
          client.Open();
          // Invoke the Add operation asynchronously and display the result.
          double result = await client.AddAsync(1.0, 2.0);
          Console.WriteLine("Add returned {0}", result); client.Close();
       }
    }
    

Weitere Informationen

Das explizite Öffnen von Clientproxys, wenn sie freigegeben oder asynchron verwendet werden, wird aus mehreren Gründen als bewährte Methode in WCF betrachtet. Weitere Informationen finden Sie unter Best Practice: Immer WCF-Clientproxy explizit öffnen, wenn er freigegeben wird.

Weitere Informationen zu einem ähnlichen Problem, bei dem freigegebene Clientproxys und asynchrone Kommunikation verwendet werden, finden Sie unter WCF-Dienstvorgänge, die asynchron über freigegebene Clientproxys mithilfe des Identitätswechsels aufgerufen werden, möglicherweise den falschen Identitätswechselkontextverwenden.