Freigeben über

Identitätswechsel und Transportsicherheit

Identitätswechsel ist die Fähigkeit einer Serveranwendung, die Identität des Clients zu übernehmen. Es ist üblich, dass Dienste den Identitätswechsel beim Überprüfen des Zugriffs auf Ressourcen verwenden. Die Serveranwendung wird mit einem Dienstbenutzerkonto ausgeführt, aber wenn der Server eine Clientverbindung akzeptiert, nimmt der Server die Identität des Clients an, sodass Zugriffsprüfungen mit den Anmeldeinformationen des Clients durchgeführt werden. Die Transportsicherheit ist ein Mechanismus zum Übergeben von Anmeldeinformationen und zum Sichern der Kommunikation mit diesen Anmeldeinformationen. In diesem Thema wird die Verwendung der Transportsicherheit in Windows Communication Foundation (WCF) zusammen mit der Impersonierungsfunktion beschrieben. Weitere Informationen zum Identitätswechsel mithilfe der Nachrichtensicherheit finden Sie unter Delegierung und Identitätswechsel.

Fünf Identitätswechselebenen

Die Transportsicherheit verwendet fünf Ebenen des Identitätswechsels, wie in der folgenden Tabelle beschrieben.

Ebene des Identitätswechsels BESCHREIBUNG
Nichts Die Serveranwendung versucht nicht, die Identität des Clients zu imitieren.
Anonym Die Serveranwendung kann Zugriffsprüfungen mit den Anmeldeinformationen des Clients durchführen, erhält jedoch keine Informationen zur Identität des Clients. Diese Ebene des Identitätswechsels ist nur sinnvoll bei einer computerinternen Kommunikation, z. B. bei Named Pipes (benannten Pipes). Die Verwendung von Anonymous mit einer Remoteverbindung erhöht die Ebene des Identitätswechsels auf Identifizieren.
Ermitteln Die Serveranwendung kennt die Identität des Clients und kann eine Zugriffsüberprüfung für die Anmeldeinformationen des Clients ausführen, kann jedoch nicht die Identität des Clients annehmen. Identifizieren ist die standardmäßig in WCF bei SSPI-Anmeldeinformationen verwendete Ebene des Identitätswechsels, es sei denn, der Tokenaussteller stellt eine andere Identitätswechselebene bereit.
Nachahmen Die Serveranwendung kann zusätzlich zur Durchführung von Zugriffsprüfungen auf Ressourcen auf dem Servercomputer als Client zugreifen. Die Serveranwendung kann nicht auf Ressourcen auf Remotecomputern zugreifen, die die Identität des Clients verwenden, da das imitierte Token keine Netzwerkanmeldeinformationen enthält.
Delegieren Zusätzlich zu den gleichen Funktionen wie Impersonate, ermöglicht es die Identitätswechselebene "Delegate" der Serveranwendung außerdem, mithilfe der Identität des Clients auf Ressourcen auf Remotecomputern zuzugreifen und die Identität an andere Anwendungen zu übergeben.

Wichtig Das Serverdomänenkonto muss für die Delegierung auf dem Domänencontroller als vertrauenswürdig gekennzeichnet sein, um diese zusätzlichen Features zu verwenden. Diese Ebene des Identitätswechsels kann nicht mit Clientdomänenkonten verwendet werden, die als vertraulich gekennzeichnet sind.

Die am häufigsten mit Transportsicherheit verwendeten Ebenen sind Identify und Impersonate. Die Ebenen None und Anonymous werden nicht für die typische Verwendung empfohlen, und viele Transporte unterstützen die Verwendung dieser Ebenen mit Authentifizierung nicht. Die Delegate Stufe ist ein leistungsfähiges Feature, das mit Bedacht verwendet werden sollte. Nur vertrauenswürdige Serveranwendungen sollten die Berechtigung zum Delegieren von Anmeldeinformationen erhalten.

Damit der Identitätswechsel mit den Ebenen Impersonate oder Delegate verwendet werden kann, muss die Serveranwendung die SeImpersonatePrivilege-Berechtigung aufweisen. Eine Anwendung verfügt standardmäßig über diese Berechtigung, wenn sie auf einem Konto in der Gruppe "Administratoren" oder auf einem Konto mit einer Dienst-SID (Netzwerkdienst, lokaler Dienst oder lokales System) ausgeführt wird. Der Identitätswechsel erfordert keine gegenseitige Authentifizierung von Client und Server. Einige Authentifizierungsschemas, die Identitätswechsel unterstützen, z. B. NTLM, können nicht mit gegenseitiger Authentifizierung verwendet werden.

Transportspezifische Aspekte beim Identitätswechsel

Die Auswahl des Transports in WCF beeinflusst die möglichen Optionen für den Identitätswechsel. In diesem Abschnitt werden Probleme beschrieben, die sich auf die standardmäßigen HTTP- und benannten Pipetransporte in WCF auswirken. Benutzerspezifische Transporte haben ihre eigenen Einschränkungen in Bezug auf die Unterstützung eines Identitätswechsels.

Named Pipe-Transport

Die folgenden Elemente werden mit dem Named Pipe-Transport verwendet:

  • Der Named Pipe-Transport ist nur für die Verwendung auf dem lokalen Computer bestimmt. Der Named Pipe-Transport in WCF lässt explizit keine computerübergreifenden Verbindungen zu.

  • Named Pipes können nicht mit den Identitätswechselebenen Impersonate und Delegate verwendet werden. Die Named Pipe kann bei diesen Identitätswechselebenen keine computerinterne Kommunikation garantieren.

Weitere Informationen zu Named Pipes finden Sie unter Auswählen eines Transports.

HTTP-Transport

Die Bindungen, die den HTTP-Transport (WSHttpBinding und BasicHttpBinding) verwenden, unterstützen mehrere Authentifizierungsschemas, wie unter "Grundlegendes zur HTTP-Authentifizierung" erläutert. Die unterstützte Impersonationsebene hängt vom Authentifizierungsschema ab. Die folgenden Elemente werden mit dem HTTP-Transport verwendet:

  • Das Anonymous Authentifizierungsschema ignoriert die Impersonation.

  • Das Basic Authentifizierungsschema unterstützt nur die Delegate Ebene. Alle niedrigeren Impersonierungsstufen werden hochgestuft.

  • Das Digest Authentifizierungsschema unterstützt nur die Impersonate und Delegate Ebenen.

  • Das NTLM Authentifizierungsschema, das entweder direkt oder durch Aushandlung ausgewählt werden kann, unterstützt nur die Delegate Ebene auf dem lokalen Computer.

  • Das Kerberos-Authentifizierungsschema, das nur über Aushandlung ausgewählt werden kann, kann mit jeder unterstützten Impersonationsebene verwendet werden.

Weitere Informationen zum HTTP-Transport finden Sie unter Auswählen eines Transports.

Siehe auch