Überschreiben der Identität eines Dienstes zur Authentifizierung
In der Regel müssen Sie die Identität für einen Dienst nicht festlegen, da die Auswahl eines Clientanmeldeinformationstyps über den in den Dienstmetadaten angezeigten Identitätstyp entscheidet. Der folgende Konfigurationscode verwendet z. B. das <wsHttpBinding>clientCredentialType-Element und legt das -Attribut auf "Windows" fest.
<configuration>
<system.serviceModel>
<bindings>
<wsHttpBinding>
<binding name="WSHttpBinding_Windows">
<security mode="Message">
<message clientCredentialType="Windows"
establishSecurityContext="false"/>
</security>
</binding>
</wsHttpBinding>
</bindings>
<!-- other configuration code not shown -->
</system.serviceModel>
</configuration>
Das folgende Web Services Description Language (WSDL)-Fragment zeigt die Identität für den zuvor definierten Endpunkt an. In diesem Beispiel wird der Dienst als selbst gehosteter Dienst unter einem bestimmten Benutzerkonto (benutzername@contoso.com) ausgeführt, und daher enthält die UPN (User Principal Name)-Identität den Kontonamen. Der UPN wird in einer Windows-Domäne auch als Benutzeranmeldename bezeichnet.
<wsdl:service name="CalculatorService">
<wsdl:port name="WSHttpBinding_ICalculator_Windows"
binding="tns:WSHttpBinding_ICalculator_Windows">
<soap12:address
location=
"https://localhost:8003/servicemodelsamples/service/upnidentity" />
<wsa10:EndpointReference>
<wsa10:Address>
https://localhost:8003/servicemodelsamples/service/upnidentity
</wsa10:Address>
<Identity
xmlns="https://schemas.xmlsoap.org/ws/2006/02/addressingidentity">
<Upn>username@contoso.com</Upn>
</Identity>
</wsa10:EndpointReference>
</wsdl:port>
</wsdl:service>
Eine Beispielanwendung, die die Identitätseinstellung veranschaulicht, finden Sie unter Dienstidentitätsbeispiel. Weitere Informationen über zur Dienstidentität finden Sie unter Dienstidentität und Authentifizierung.
Kerberos-Authentifizierung und Identität
Wenn ein Dienst für die Verwendung von Windows-Anmeldeinformationen konfiguriert wird, wird in WSDL standardmäßig ein <identity><userPrincipalName>-Element, das ein<servicePrincipalName>-Element oder ein -Element enthält, generiert. Wenn der Dienst unter dem LocalSystem-Konto, unter dem LocalService-Konto oder unter dem NetworkService-Konto ausgeführt wird, wird standardmäßig ein Dienstprinzipalname (Service Principal Name, SPN) im Format host/<Hostname> generiert, da diese Konten Zugriff auf die SPN-Daten des Computers haben. Wird der Dienst unter einem anderen Konto ausgeführt, generiert Windows Communication Foundation (WCF) einen UPN im Format <Benutzername>@<Domänenname>. Die Kerberos-Authentifizierung erfordert nämlich, dass für den Client ein UPN oder SPN zum Authentifizieren des Dienstes bereitgestellt wird.
Sie können auch das Tool Setspn.exe zur Registrierung eines zusätzlichen SPN beim Konto eines Dienstes in einer Domäne verwenden. Sie können dann den SPN als die Identität des Dienstes verwenden. Informationen zum Herunterladen des Tools finden Sie unter Windows 2000 Resource Kit Tool: Setspn.exe (in englischer Sprache). Weitere Informationen über über das Tool finden Sie unter Setspn Overview (in englischer Sprache).
Hinweis: |
---|
Zur Verwendung des Windows-Anmeldeinformationstyps ohne Aushandlung muss das Benutzerkonto des Dienstes Zugriff auf den bei der Active Directory-Domäne registrierten SPN haben. Sie können dazu folgendermaßen vorgehen: |
Verwenden Sie das NetworkService- oder das LocalSystem-Konto, um den Dienst auszuführen. Da diese Konten Zugriff auf den beim Hinzufügen des Computers zur Active Directory-Domäne erstellten Computer-SPN haben, generiert WCF automatisch das zutreffende SPN-Element im Endpunkt des Dienstes in den Dienstmetadaten (WSDL).
Verwenden Sie ein beliebiges Active Directory-Domänenkonto, um den Dienst auszuführen. Erstellen Sie in diesem Fall mit dem Tool Setspn.exe einen SPN für dieses Domänenkonto. Konfigurieren Sie nach dem Erstellen des SPN für das Konto des Dienstes WCF so, dass dieser SPN für die Clients des Dienstes über seine Metadaten (WSDL) veröffentlicht wird. Legen Sie dazu die Endpunktidentität für den angezeigten Endpunkt entweder mit einer Anwendungskonfigurationsdatei oder mit Code fest.
Weitere Informationen über zu SPNs, zum Kerberos-Protokoll sowie zu Active Directory finden Sie unter Technische Kerberos-Ergänzung für Windows (möglicherweise in englischer Sprache).
Wenn SPN oder UPN der leeren Zeichenfolge entspricht
Das Festlegen von SPN oder UPN gleich einer leeren Zeichenfolge führt abhängig von der Sicherheitsebene und dem verwendeten Authentifizierungsmodus zu verschiedenen Ergebnissen:
Wenn Sie Sicherheit auf Transportebene verwenden, wird die NT LanMan (NTLM)-Authentifizierung ausgewählt.
Wenn Sie Sicherheit auf Nachrichtenebene verwenden, schlägt die Authentifizierung abhängig vom Authentifizierungsmodus möglicherweise fehl:
Wenn Sie den spnego-Modus verwenden und das AllowNtlm-Attribut auf false festgelegt ist, schlägt die Authentifizierung fehl.
Verwenden Sie den spnego-Modus verwenden und ist das AllowNtlm-Attribut auf true festgelegt, schlägt die Authentifizierung fehl, wenn der UPN leer ist; sie ist jedoch erfolgreich, wenn der SPN leer ist.
Wenn Sie Kerberos direkt (wird auch als "One-Shot" bezeichnet) verwenden, schlägt die Authentifizierung fehl.
Verwenden des <identity>-Elements bei der Konfiguration
Wenn Sie den Clientanmeldeinformationstyp in der zuvor gezeigten Bindung zu Certificate, ändern, enthält die generierte WSDL ein serialisiertes Base64-X.509-Zertifikat als Identitätswert, wie im folgenden Code gezeigt. Dies ist der Standard für alle Clientanmeldeinformationstypen außer Windows.
<Identity xmlns="https://schemas.xmlsoap.org/ws/2006/02/addressingidentity">
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<X509Data>
<X509Certificate>MIIBxjCCAXSgAwIBAgIQmXJgyu9tro1M98GifjtuoDAJBgUrDgMCHQUAMBYxFDASBgNVBAMTC1Jvb3QgQWdlbmN5MB4XDTA2MDUxNzIxNDQyNVoXDTM5MTIzMTIzNTk1OVowKTEQMA4GA1UEChMHQ29udG9zbzEVMBMGA1UEAxMMaWRlbnRpdHkuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDBmivcb8hYbh11hqVoDuB7zmJ2y230f/b4e+4P6yXtKKuhUdYcIqc8mAforIM4WWJEVGeJVq9sFEwqrL5Ryid8jMTRwPLvA/x/wvj1gtD1GWJ+aUh2pqieiGL7MWTepHAQBIibUxgOrAOz0j9Xhg0iDFYScdYUjeqI3yZIDC7WbwIDAQABo0swSTBHBgNVHQEEQDA+gBAS5AktBh0dTwCNYSHcFmRjoRgwFjEUMBIGA1UEAxMLUm9vdCBBZ2VuY3mCEAY3bACqAGSKEc+41KpcNfQwCQYFKw4DAh0FAANBADB/J2QjdSPL8Doj3pAveCXd/5fY03eo9kUym/Tmb4ubdqsObri0qnYR/n8Wxsa1yJ4Dks6cNBTPS4l5B7zUeNo=</X509Certificate>
</X509Data>
</KeyInfo>
</Identity>
Sie können den Wert der standardmäßigen Dienstidentität oder den Typ der Identität mit dem <identity>-Element bei der Konfiguration oder durch Festlegen der Identität im Code ändern. Der folgende Konfigurationscode legt eine DNS-Identität (Domain Name System) mit dem Wert contoso.com
fest.
Programmgesteuertes Festlegen der Identität
Der Dienst muss nicht explizit eine Identität angeben, da sie von WCF automatisch bestimmt wird. Allerdings können Sie mit WCF nach Bedarf eine Identität für einen Endpunkt angeben. Mit dem folgenden Code wird ein neuer Dienstendpunkt mit einer bestimmten DNS-Identität hinzugefügt.
Dim ep As ServiceEndpoint = myServiceHost.AddServiceEndpoint(GetType(ICalculator), New WSHttpBinding(), String.Empty)
Dim myEndpointAdd As New EndpointAddress(New Uri("https://localhost:8088/calc"), EndpointIdentity.CreateDnsIdentity("contoso.com"))
ep.Address = myEndpointAdd
ServiceEndpoint ep = myServiceHost.AddServiceEndpoint(
typeof(ICalculator),
new WSHttpBinding(),
String.Empty);
EndpointAddress myEndpointAdd = new EndpointAddress(new Uri("https://localhost:8088/calc"),
EndpointIdentity.CreateDnsIdentity("contoso.com"));
ep.Address = myEndpointAdd;
Siehe auch
Aufgaben
Vorgehensweise: Erstellen einer benutzerdefinierten Clientidentitätsüberprüfung