Freigeben über

Delegierung und Identitätswechsel mit WCF

  • Artikel

DerIdentitätswechsel ist ein gängiges Verfahren, das Dienste verwenden, um den Clientzugriff auf die Ressourcen einer Dienstdomäne zu beschränken. Dienstdomänenressourcen können entweder Computerressourcen, wie lokale Dateien (Identitätswechsel), oder eine Ressource auf einem anderen Computer, z. B. eine Dateifreigabe (Delegierung), sein. Eine Beispielanwendung finden Sie unter Impersonating the Client. Ein Beispiel zur Verwendung von Identitätswechsel finden Sie unter How to: Impersonate a Client on a Service.

Wichtig

Beim Identitätswechsel eines Clients in einem Dienst wird der Dienst mit den Anmeldeinformationen des Clients ausgeführt, die höhere Rechte besitzen können als der Serverprozess.

Überblick

In der Regel ruft ein Client einen Dienst auf, damit dieser eine Aktion für ihn ausführt. Der Identitätswechsel ermöglicht es dem Dienst, während der Ausführung der Aktion als Client zu fungieren. Die Delegierung ermöglicht es einem Front-End-Dienst, die Clientanforderung so an einen Back-End-Dienst weiterzuleiten, dass auch der Back-End-Dienst die Identität des Clients annehmen kann. Der Identitätswechsel wird meist als Möglichkeit verwendet, mit der überprüft werden kann, ob ein Client zur Durchführung einer bestimmten Aktion berechtigt ist. Die Delegierung stellt dagegen eine Möglichkeit dar, die Fähigkeit zum Identitätswechsel und die Clientidentität an einen Back-End-Dienst zu übertragen. Die Delegierung ist eine Windows-Domänenfunktion, die verwendet werden kann, wenn eine auf Kerberos basierende Authentifizierung durchgeführt wird. Delegierung und Identitätsübergabe sind zwei verschiedene Dinge. Weil bei der Delegierung die Fähigkeit zur Annahme der Identität des Clients übertragen wird, ohne das Kennwort des Clients zu besitzen, handelt es sich um einen Vorgang mit höheren Sicherheitsberechtigungen als die Identitätsübergabe.

Sowohl Identitätswechsel als auch Delegierung erfordern, dass der Client eine Windows-Identität besitzt. Wenn der Client keine Windows-Identität besitzt, dann besteht nur die Möglichkeit, die Identität des Clients dem zweiten Dienst zu übertragen.

Grundlagen des Identitätswechsels

Windows Communication Foundation (WCF) unterstützt den Identitätswechsel für eine Vielzahl von Clientanmeldeinformationen. In diesem Thema wird die Dienstmodellunterstützung für den Identitätswechsel des Aufrufers während der Implementierung einer Dienstmethode beschrieben. Außerdem werden allgemeine Bereitstellungsszenarien erörtert, die Identitätswechsel und SOAP-Sicherheit sowie WCF-Optionen in diesen Szenarien beinhalten.

Der Schwerpunkt dieses Themas liegt auf dem Identitätswechsel und der Delegierung in WCF bei Verwendung der SOAP-Sicherheit. Sie können den Identitätswechsel und die Delegierung auch mit WCF verwenden, wenn Sie die Transportsicherheit nutzen, wie unter Identitätswechsel und Transportsicherheit beschrieben.

Zwei Methoden

Die WCF SOAP-Sicherheit verfügt über zwei unterschiedliche Methoden zum Ausführen des Identitätswechsels. Die verwendete Methode hängt von der Bindung ab. Die eine Methode besteht im Identitätswechsel von einem Windows-Token aus, das von SSPI (Security Support Provider Interface) oder der Kerberos-Authentifizierung stammt, die dann im Cache des Diensts gespeichert wird. Die zweite Methode besteht im Identitätswechsel von einem Windows-Token aus, das von Kerberos-Erweiterungen stammt, insgesamt als Service-for-User (S4U) bezeichnet.

Identitätswechsel mit im Cache gespeichertem Token

Sie können einen Identitätswechsel mit einem im Cache gespeicherten Token folgendermaßen ausführen:

Auf S4U basierender Identitätswechsel

Sie können einen auf S4U basierenden Identitätswechsel folgendermaßen ausführen:

  • MitWSHttpBinding, WSDualHttpBindingund NetTcpBinding mit Zertifikatclient-Anmeldeinformationen, die der Dienst einem gültigen Windows-Konto zuordnen kann.

  • Mit jeder CustomBinding , die Windows-Clientanmeldeinformationen verwendet, bei denen die requireCancellation -Eigenschaft auf falseeingestellt ist.

  • Mit jeder CustomBinding , die einen Benutzernamen oder Windows-Clientanmeldeinformationen und eine sichere Konversation verwendet, wobei die requireCancellation -Eigenschaft auf falseeingestellt ist.

Inwieweit der Dienst die Identität des Clients annehmen kann, hängt von den Rechten ab, die das Dienstkonto beim Versuch des Identitätswechsels besitzt, vom verwendeten Typ des Identitätswechsels und möglicherweise vom Ausmaß des Identitätswechsels, den der Client zulässt.

Hinweis

Wenn Client und Dienst auf demselben Computer ausgeführt werden und der Client unter einem Systemkonto (z. B. unter Local System oder Network Service) ausgeführt wird, kann kein Clientidentitätswechsel vorgenommen werden, wenn mit Token für den Sicherheitszustandskontext eine Sicherheitsverbindung hergestellt wird. Eine Windows Forms- oder Konsolenanwendung wird in der Regel unter dem derzeit angemeldeten Konto ausgeführt, sodass für dieses Konto standardmäßig ein Identitätswechsel durchgeführt werden kann. Wenn es sich bei dem Client jedoch um eine ASP.NET-Seite handelt, die in IIS 6.0 oder IIS 7.0 gehostet wird, wird der Client standardmäßig unter dem Network Service-Konto ausgeführt. Alle vom System bereitgestellten Bindungen, die Sicherheitssitzungen unterstützen, verwenden standardmäßig ein zustandsloses Token für den Sicherheitskontext. Wenn es sich bei dem Client jedoch um eine ASP.NET-Seite handelt und sichere Sitzungen mit zustandsbehafteten SCTs verwendet werden, kann kein Clientidentitätswechsel durchgeführt werden. Weitere Informationen zur Verwendung zustandsbehafteter Sicherheitskontexttoken (SCTs) in einer sicheren Sitzung finden Sie unter Vorgehensweise: Erstellen eines Tokens für den Sicherheitskontext einer sicheren Sitzung.

Identitätswechsel in einer Dienstmethode: Deklaratives Modell

Die meisten Identitätswechselszenarien umfassen das Ausführen der Dienstmethode im Aufruferkontext. WCF bietet eine Identitätswechselfunktion, die dies erleichtert, da Benutzer*innen die Anforderung für den Identitätswechsel im OperationBehaviorAttribute-Attribut festlegen können. Im folgenden Codebeispiel nimmt die WCF-Infrastruktur die Identität des Aufrufers an, bevor die Hello-Methode ausgeführt wird. Jeder Versuch, auf die systemeigenen Ressourcen innerhalb der Hello -Methode zuzugreifen, ist nur erfolgreich, wenn die Zugriffsteuerungsliste der Ressource dem Aufrufer Zugriffsrechte erlaubt. Zum Aktivieren des Identitätswechsels legen Sie die Impersonation -Eigenschaft auf einen der ImpersonationOption -Enumerationswerte fest, entweder auf ImpersonationOption.Required oder auf ImpersonationOption.Allowed, wie im folgenden Beispiel dargestellt.

Hinweis

Wenn ein Dienst höhere Anmeldeinformationen besitzt als der Remoteclient, werden die Anmeldeinformationen des Diensts verwendet, wenn die Impersonation -Eigenschaft auf Allowedeingestellt ist. Wenn also ein Benutzer mit niedrigen Rechten seine Anmeldeinformationen angibt, führt ein Dienst mit höheren Rechten die Methode mit den Anmeldeinformationen des Diensts aus und kann Ressourcen verwenden, die der Benutzer mit den niedrigen Rechten sonst keinesfalls verwenden könnte.

[ServiceContract]
public interface IHelloContract
{
    [OperationContract]
    string Hello(string message);
}

public class HelloService : IHelloService
{
    [OperationBehavior(Impersonation = ImpersonationOption.Required)]
    public string Hello(string message)
    {
        return "hello";
    }
}


<ServiceContract()> _
Public Interface IHelloContract
    <OperationContract()> _
    Function Hello(ByVal message As String) As String
End Interface


Public Class HelloService
    Implements IHelloService

    <OperationBehavior(Impersonation:=ImpersonationOption.Required)> _
    Public Function Hello(ByVal message As String) As String Implements IHelloService.Hello
        Return "hello"
    End Function
End Class

Die WCF-Infrastruktur kann die Identität des Aufrufers nur annehmen, wenn der Aufrufer mit Anmeldeinformationen authentifiziert wird, die einem Windows-Benutzerkonto zugeordnet werden können. Wenn der Dienst für die Authentifizierung mit Anmeldeinformationen konfiguriert ist, die keinem Windows-Konto zugeordnet werden können, wird die Dienstmethode nicht ausgeführt.

Hinweis

Unter Windows XP schlägt der Identitätswechsel fehl, wenn ein zustandsbehaftetes Sicherheitskontexttoken erstellt wird, was zu einer InvalidOperationException führt. Weitere Informationen finden Sie unter Nicht unterstützte Szenarios.

Identitätswechsel in einer Dienstmethode: Imperatives Modell

Mitunter benötigt ein Aufrufer nicht die gesamte Dienstmethode für den Identitätswechsel, sondern nur einen Teil der Methode. In diesem Fall rufen Sie die Windows-Identität des Aufrufers innerhalb der Dienstmethode ab, und führen Sie den Identitätswechsel imperativ durch. Verwenden Sie dazu die WindowsIdentity -Eigenschaft des ServiceSecurityContext , um eine Instanz der WindowsIdentity -Klasse zurückzugeben und die Impersonate -Methode vor dem Verwenden der Instanz aufzurufen.

Hinweis

Stellen Sie sicher, dass Sie die Visual BasicUsing-Anweisung oder die C# using-Anweisung verwenden, um den Identitätswechsel automatisch rückgängig zu machen. Wenn Sie die Anweisung nicht verwenden oder wenn Sie eine andere Programmiersprache als Visual Basic oder C# verwenden, müssen Sie die Identitätswechselebene zurücksetzen. Wird dies versäumt, kann dies die Grundlage für Denial-of-Service-Angriffe und Rechteerweiterungsangriffe bilden.

public class HelloService : IHelloService
{
    [OperationBehavior]
    public string Hello(string message)
    {
        WindowsIdentity callerWindowsIdentity =
        ServiceSecurityContext.Current.WindowsIdentity;
        if (callerWindowsIdentity == null)
        {
            throw new InvalidOperationException
           ("The caller cannot be mapped to a WindowsIdentity");
        }
        using (callerWindowsIdentity.Impersonate())
        {
            // Access a file as the caller.
        }
        return "Hello";
    }
}

Public Class HelloService
    Implements IHelloService

    <OperationBehavior()> _
    Public Function Hello(ByVal message As String) As String _
       Implements IHelloService.Hello
        Dim callerWindowsIdentity As WindowsIdentity = _
            ServiceSecurityContext.Current.WindowsIdentity
        If (callerWindowsIdentity Is Nothing) Then
            Throw New InvalidOperationException( _
              "The caller cannot be mapped to a WindowsIdentity")
        End If
        Dim cxt As WindowsImpersonationContext = callerWindowsIdentity.Impersonate()
        Using (cxt)
            ' Access a file as the caller.
        End Using

        Return "Hello"

    End Function
End Class

Identitätswechsel für alle Dienstmethoden

In einigen Fällen müssen Sie alle Methoden eines Diensts im Kontext eines Aufrufers ausführen. Statt diese Funktion explizit für jede Methode einzeln zu aktivieren, verwenden Sie das ServiceAuthorizationBehavior. Wie im folgenden Code dargestellt, legen Sie die ImpersonateCallerForAllOperations -Eigenschaft auf truefest. Das ServiceAuthorizationBehavior wird aus den Verhaltenssammlungen der ServiceHost -Klasse abgerufen. Beachten Sie außerdem, dass die Impersonation -Eigenschaft des auf jede Methode angewendeten OperationBehaviorAttribute ebenfalls entweder auf Allowed oder Requiredeingestellt sein muss.

// Code to create a ServiceHost not shown.
ServiceAuthorizationBehavior MyServiceAuthorizationBehavior =
    serviceHost.Description.Behaviors.Find<ServiceAuthorizationBehavior>();
MyServiceAuthorizationBehavior.ImpersonateCallerForAllOperations = true;

' Code to create a ServiceHost not shown.
Dim MyServiceAuthorizationBehavior As ServiceAuthorizationBehavior
MyServiceAuthorizationBehavior = serviceHost.Description.Behaviors.Find _
(Of ServiceAuthorizationBehavior)()
MyServiceAuthorizationBehavior.ImpersonateCallerForAllOperations = True

In der folgenden Tabelle wird das WCF-Verhalten für alle möglichen Kombinationen aus ImpersonationOption und ImpersonateCallerForAllServiceOperations beschrieben.

ImpersonationOption ImpersonateCallerForAllServiceOperations Verhalten
Erforderlich – WCF nimmt die Identität des Aufrufers an
Zulässig False WCF nimmt die Identität des Aufrufers nicht an
Zulässig true WCF nimmt die Identität des Aufrufers an
Nicht zulässig False WCF nimmt die Identität des Aufrufers nicht an
Nicht zulässig true Disallowed. (Eine InvalidOperationException wird ausgelöst.)

Identitätswechselebene aus Windows-Anmeldeinformationen und Identitätswechsel mit im Cache gespeichertem Token

In einigen Szenarien besitzt der Client eine Teilkontrolle über die Ebene des Identitätswechsels, den der Dienst bei Verwendung von Windows-Clientanmeldeinformationen ausführt. Ein Szenario tritt auf, wenn der Client die Identitätswechselebene "Anonymous" angibt. Das andere Szenario liegt vor, wenn Sie einen Identitätswechsel mit einem im Cache gespeicherten Token ausführen. Legen Sie hierfür die AllowedImpersonationLevel -Eigenschaft der WindowsClientCredential -Klasse fest, auf die als Eigenschaft der generischen ChannelFactory<TChannel> -Klasse zugegriffen wird.

Hinweis

Durch Angeben der Identitätswechselebene "Anonymous" meldet sich der Client anonym beim Dienst an. Der Dienst muss daher anonyme Anmeldungen zulassen, unabhängig davon, ob ein Identitätswechsel durchgeführt wird.

Der Client kann die Identitätswechselebene als Anonymous, Identification, Impersonationoder Delegationangeben. Es wird nur ein Token auf der angegebenen Ebene erstellt, wie im folgenden Code veranschaulicht.

ChannelFactory<IEcho> cf = new ChannelFactory<IEcho>("EchoEndpoint");
cf.Credentials.Windows.AllowedImpersonationLevel  =
    System.Security.Principal.TokenImpersonationLevel.Impersonation;

Dim cf As ChannelFactory(Of IEcho) = New ChannelFactory(Of IEcho)("EchoEndpoint")
cf.Credentials.Windows.AllowedImpersonationLevel = _
System.Security.Principal.TokenImpersonationLevel.Impersonation

In der folgenden Tabelle wird die Identitätswechselebene angegeben, die der Dienst bei einem Identitätswechsel mit einem im Cache gespeicherten Token erhält.

Wert vom Typ AllowedImpersonationLevel Der Dienst hat das SeImpersonatePrivilege Dienst und Client sind delegierungsfähig. ImpersonationLevel
Anonym Ja – Identitätswechsel
Anonym Nein – Identifikation
Identifikation – – Identifikation
Identitätswechsel Ja – Identitätswechsel
Identitätswechsel Nein – Identifikation
Delegierung Ja Ja Delegierung
Delegierung Ja Nein Identitätswechsel
Delegierung Nein – Identifikation

Identitätswechselebene aus Benutzernamen-Anmeldeinformationen und Identitätswechsel mit im Cache gespeichertem Token

Durch Weitergabe des Benutzernamens und Kennworts an den Dienst ermöglicht ein Client WCF, sich als dieser Benutzer anzumelden, was dem Festlegen der AllowedImpersonationLevel-Eigenschaft auf Delegation entspricht. (AllowedImpersonationLevel ist in den Klassen WindowsClientCredential und HttpDigestClientCredential verfügbar.) Die folgende Tabelle enthält die Ebene des Identitätswechsels, die abgerufen wird, wenn der Dienst Benutzeranmeldeinformationen empfängt.

AllowedImpersonationLevel Der Dienst hat das SeImpersonatePrivilege Dienst und Client sind delegierungsfähig. ImpersonationLevel
– Ja Ja Delegierung
– Ja Nein Identitätswechsel
– Nein – Identifikation

Identitätswechselebene aus einem auf S4U basierenden Identitätswechsel

Der Dienst hat das SeTcbPrivilege Der Dienst hat das SeImpersonatePrivilege Dienst und Client sind delegierungsfähig. ImpersonationLevel
Ja Ja – Identitätswechsel
Ja Nein – Identifikation
Nein n/v – Identifikation

Zuordnen eines Clientzertifikats zu einem Windows-Konto

Ein Client kann sich gegenüber einem Dienst mithilfe eines Zertifikats ausweisen; der Dienst kann angewiesen werden, den Client mittels Active Directory einem vorhandenen Konto zuzuordnen. Im folgenden XML wird gezeigt, wie der Dienst so konfiguriert wird, dass er das Zertifikat zuordnet:

<behaviors>  
  <serviceBehaviors>  
    <behavior name="MapToWindowsAccount">  
      <serviceCredentials>  
        <clientCertificate>  
          <authentication mapClientCertificateToWindowsAccount="true" />  
        </clientCertificate>  
      </serviceCredentials>  
    </behavior>  
  </serviceBehaviors>  
</behaviors>

Im folgenden Code wird gezeigt, wie der Dienst konfiguriert wird:

// Create a binding that sets a certificate as the client credential type.  
WSHttpBinding b = new WSHttpBinding();  
b.Security.Message.ClientCredentialType = MessageCredentialType.Certificate;  
  
// Create a service host that maps the certificate to a Windows account.  
Uri httpUri = new Uri("http://localhost/Calculator");  
ServiceHost sh = new ServiceHost(typeof(HelloService), httpUri);  
sh.Credentials.ClientCertificate.Authentication.MapClientCertificateToWindowsAccount = true;

Delegierung

Damit ein Dienst an einen Back-End-Dienst delegiert werden kann, muss er sich gegenüber dem Back-End-Dienst mittels bilateraler (SSPI ohne Rückgriff auf NTLM) oder direkter Kerberos-Authentifizierung unter Verwendung der Windows-Identität des Clients authentifizieren. Um einen Dienst an einen Back-End-Dienst zu delegieren, erstellen Sie eine ChannelFactory<TChannel> und einen Kanal und leiten die Kommunikation über diesen Kanal, solange die Identität des Clients angenommen wird. Bei dieser Form der Delegierung hängt die maximale Entfernung zwischen Back-End-Dienst und Front-End-Dienst von der Identitätswechselebene des Front-End-Diensts ab. Wenn die Identitätswechselebene Impersonationfestgelegt wird, müssen Front-End- und Back-End-Dienst auf dem gleichen Computer ausgeführt werden. Wenn die Identitätswechselebene Delegationverwendet wird, können Front-End- und Back-End-Dienst auf unterschiedlichen Computern oder dem gleichen Computer ausgeführt werden. Ein Identitätswechsel auf Delegierungsebene erfordert, dass die Windows-Domänenrichtlinie entsprechend konfiguriert wurde, um eine Delegierung zuzulassen. Weitere Informationen zum Konfigurieren von Active Directory für die Delegierung finden Sie unter Enabling Delegated Authentication.

Hinweis

Wenn sich der Client dem Front-End-Dienst gegenüber mit einem Benutzernamen und einem Kennwort authentifiziert, die einem Windows-Konto für den Back-End-Dienst entsprechen, dann kann sich der Front-End-Dienst durch erneute Angabe des Benutzernamens und des Kennworts des Clients dem Back-End-Dienst gegenüber authentifizieren. Dies ist eine besonders mächtige Form der Identitätsübergabe, weil die Weitergabe von Benutzernamen und Kennwort an den Back-End-Dienst diesen in die Lage versetzt, einen Identitätswechsel durchzuführen. Weil Kerberos nicht verwendet wird, stellt dieser Vorgang jedoch keine Delegierung dar. Die Delegierung betreffende Active Directory-Steuerelemente gelten nicht für die Authentifizierung durch Benutzername und Kennwort.

Delegierungsfähigkeit als Funktion der Identitätswechselebene

Ebene des Identitätswechsels Dienst kann eine prozessübergreifende Delegierung ausführen Dienst kann eine computerübergreifende Delegierung ausführen
Identification Nein Nein
Impersonation Ja Keine
Delegation Ja Ja

Im folgenden Codebeispiel wird die Verwendung der Delegierung veranschaulicht.

public class HelloService : IHelloService
{
    [OperationBehavior(Impersonation = ImpersonationOption.Required)]
    public string Hello(string message)
    {
        WindowsIdentity callerWindowsIdentity = ServiceSecurityContext.Current.WindowsIdentity;
        if (callerWindowsIdentity == null)
        {
            throw new InvalidOperationException
             ("The caller cannot be mapped to a Windows identity.");
        }
        using (callerWindowsIdentity.Impersonate())
        {
            EndpointAddress backendServiceAddress = new EndpointAddress("http://localhost:8000/ChannelApp");
            // Any binding that performs Windows authentication of the client can be used.
            ChannelFactory<IHelloService> channelFactory = new ChannelFactory<IHelloService>(new NetTcpBinding(), backendServiceAddress);
            IHelloService channel = channelFactory.CreateChannel();
            return channel.Hello(message);
        }
    }
}

Public Class HelloService
    Implements IHelloService

    <OperationBehavior(Impersonation:=ImpersonationOption.Required)> _
    Public Function Hello(ByVal message As String) As String Implements IHelloService.Hello
        Dim callerWindowsIdentity As WindowsIdentity = ServiceSecurityContext.Current.WindowsIdentity
        If (callerWindowsIdentity Is Nothing) Then
            Throw New InvalidOperationException("The caller cannot be mapped to a Windows identity.")
        End If

        Dim backendServiceAddress As EndpointAddress = New EndpointAddress("http://localhost:8000/ChannelApp")
        ' Any binding that performs Windows authentication of the client can be used.
        Dim channelFactory As ChannelFactory(Of IHelloService) = _
          New ChannelFactory(Of IHelloService)(New NetTcpBinding(), backendServiceAddress)
        Dim channel As IHelloService = channelFactory.CreateChannel()
        Return channel.Hello(message)
    End Function
End Class

Konfigurieren einer Anwendung für die Verwendung der eingeschränkten Delegierung

Die eingeschränkte Delegierung kann erst verwendet werden, nachdem Absender, Empfänger und Domänencontroller entsprechend konfiguriert wurden. Die folgende Prozedur listet die Schritte auf, die eine eingeschränkte Delegierung ermöglichen. Nähere Angaben zu den Unterschieden zwischen Delegierung und eingeschränkter Delegierung finden Sie in dem Abschnitt unter Windows Server 2003 Kerberos Extensions , der sich mit eingeschränkter Delegierung befasst (Seite möglicherweise auf Englisch).

  1. Deaktivieren Sie auf dem Domänencontroller das Kontrollkästchen Konto ist vertraulich und kann nicht delegiert werden für das Konto, unter dem die Clientanwendung ausgeführt wird.

  2. Aktivieren Sie auf dem Domänencontroller das Kontrollkästchen Konto wird für Delegierungszwecke vertraut für das Konto, unter dem die Clientanwendung ausgeführt wird.

  3. Konfigurieren Sie auf dem Domänencontroller den Computer der mittleren Schicht, sodass diesem für Delegierungszwecke vertraut wird, indem Sie auf die Option Computer für Delegierungszwecke vertrauen klicken.

  4. Konfigurieren Sie auf dem Domänencontroller den Computer der mittleren Schicht für die Verwendung der eingeschränkten Delegierung, indem Sie auf die Option Computer nur für Delegierungszwecke angegebener Dienste vertrauen klicken.

Ausführlichere Anweisungen zum Konfigurieren der eingeschränkten Delegierung finden Sie unter Kerberos-Protokollübergang und eingeschränkte Delegierung.

Siehe auch