Delegierung und Identitätswechsel mit WCF

Artikel
02/27/2011

Der Identitä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 Vorgehensweise: Annahme der Clientidentität durch einen Dienst.

Hinweis:
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.

Übersicht

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 ein Windows-Domänenfeature, das 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 und 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

WCF-SOAP-Sicherheit verfügt über zwei verschiedene Methode zum Durchführen von Identitätswechsel. 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:

Mit WSHttpBinding, WSDualHttpBinding und NetTcpBinding mit Windows-Clientanmeldeinformationen.
Mit BasicHttpBinding, mit einem BasicHttpSecurityMode, der auf die TransportWithMessageCredential-Anmeldeinformationen eingestellt ist, oder einer anderen Standardbindung, bei der der Client Benutzernamen-Anmeldeinformationen präsentiert, die der Dienst einem gültigen Windows-Konto zuordnen kann.
Mit jeder CustomBinding, die Windows-Clientanmeldeinformationen verwendet, bei denen requireCancellation auf true eingestellt ist. (Die Eigenschaft ist für folgende Klassen verfügbar: SecureConversationSecurityTokenParameters, SslSecurityTokenParameters und SspiSecurityTokenParameters.) Bei Verwendung einer sicheren Konversation auf der Bindung muss die requireCancellation-Eigenschaft auch auf true eingestellt sein.
Mit jeder CustomBinding, bei der der Client Benutzernamen-Anmeldeinformationen präsentiert. Bei Verwendung einer sicheren Konversation auf der Bindung muss die requireCancellation-Eigenschaft auch auf true eingestellt sein.

Auf S4U basierender Identitätswechsel

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

Mit WSHttpBinding, WSDualHttpBinding und 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 false eingestellt ist.
Mit jeder CustomBinding, die einen Benutzernamen oder Windows-Clientanmeldeinformationen und eine sichere Konversation verwendet, wobei die requireCancellation-Eigenschaft auf false eingestellt 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 auf 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 Sicherheitsverbindungen mit Token für den Sicherheitszustandskontext verwendet werden, kann kein Clientidentitätswechsel durchgeführt werden. Weitere Informationen über zur Verwendung von Token für den Sicherheitszustandskontext in Sicherheitssitzungen finden Sie unter Vorgehensweise: Erstellen eines Tokens für den Sicherheitskontext einer sicheren Sitzung.

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 auf 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 Sicherheitsverbindungen mit Token für den Sicherheitszustandskontext verwendet werden, kann kein Clientidentitätswechsel durchgeführt werden. Weitere Informationen über zur Verwendung von Token für den Sicherheitszustandskontext in Sicherheitssitzungen 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 beinhalten das Ausführen der Dienstmethode im Aufruferkontext. WCF bietet eine Identitätswechselfunktion, die dies erleichtert, indem der Benutzer die Anforderung für den Identitätswechsel im OperationBehaviorAttribute-Attribut festlegen kann. 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 System.ServiceModel.ImpersonationOption.Required oder auf System.ServiceModel.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 Allowed eingestellt 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.

Wenn ein Dienst höhere Anmeldeinformationen besitzt als der Remoteclient, werden die Anmeldeinformationen des Diensts verwendet, wenn die Impersonation-Eigenschaft auf Allowed eingestellt 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()>  _
    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

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

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

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 beim Erstellen eines zustandsbehafteten SCT fehl, was zu einer InvalidOperationException führt. Weitere Informationen finden Sie unter Nicht unterstützte Szenarien.

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 Basic Using-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.

Stellen Sie sicher, dass Sie die Visual Basic Using-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
    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

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

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 true fest. 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 Required eingestellt sein muss.

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

// Code to create a ServiceHost not shown.
ServiceAuthorizationBehavior MyServiceAuthoriationBehavior = 
    serviceHost.Description.Behaviors.Find<ServiceAuthorizationBehavior>();
MyServiceAuthoriationBehavior.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	nicht verfügbar	WCF nimmt die Identität des Aufrufers an
Allowed	false	WCF nimmt die Identität des Aufrufers nicht an
Allowed	true	WCF nimmt die Identität des Aufrufers an
NotAllowed	false	WCF nimmt die Identität des Aufrufers nicht an
NotAllowed	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-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, Impersonation oder Delegation angeben. Es wird nur ein Token auf der angegebenen Ebene erstellt, wie im folgenden Code veranschaulicht.

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

ChannelFactory<IEcho> cf = new ChannelFactory<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.

AllowedImpersonationLevel-Wert	Der Dienst hat das SeImpersonatePrivilege	Dienst und Client sind delegierungsfähig.	ImpersonationLevel mit im Cache gespeichertem Token
Anonymous	Ja	nicht verfügbar	Identitätswechsel
Anonym (Anonymous)	Nein	nicht verfügbar	Identifikation
Identifikation	nicht verfügbar	nicht verfügbar	Identifikation
Identitätswechsel	Ja	nicht verfügbar	Identitätswechsel
Identitätswechsel	Nein	nicht verfügbar	Identifikation
Delegierung	Ja	Ja	Delegierung
Delegierung	Ja	Nein	Identitätswechsel
Delegierung	Nein	nicht verfügbar	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. Dies entspricht einem Festlegen der AllowedImpersonationLevel-Eigenschaft auf Delegation. (Die AllowedImpersonationLevel ist in der WindowsClientCredential-Klasse und in der HttpDigestClientCredential-Klasse verfügbar.) In der folgenden Tabelle wird die Identitätswechselebene angegeben, die erhalten wird, wenn der Dienst Benutzernamen-Anmeldeinformationen empfängt.

AllowedImpersonationLevel	Der Dienst hat das SeImpersonatePrivilege	Dienst und Client sind delegierungsfähig.	ImpersonationLevel mit im Cache gespeichertem Token
nicht verfügbar	Ja	Ja	Delegierung
nicht verfügbar	Ja	Nein	Identitätswechsel
nicht verfügbar	Nein	nicht verfügbar	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 mit im Cache gespeichertem Token
Ja	Ja	nicht verfügbar	Identitätswechsel
Ja	Nein	nicht verfügbar	Identifikation
Nein	nicht verfügbar	nicht verfügbar	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("https://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 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 Impersonation festgelegt wird, müssen Front-End- und Back-End-Dienst auf dem gleichen Computer ausgeführt werden. Wenn die Identitätswechselebene Delegation verwendet 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 (Seite möglicherweise auf Englisch).

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.

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	Nein
Delegation	Ja	Ja

Im folgenden Codebeispiel wird die Verwendung der Delegierung veranschaulicht.

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("https://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

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("https://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);
        }
    }
}

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 betreffenden Abschnitt unter Windows Server 2003 Kerberos Extensions (Seite möglicherweise auf Englisch).

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.
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.
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.
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 in den folgenden MSDN-Themen:

Siehe auch

Freigeben über