Ich habe zahlreiche msdn-Artikel und die Codeplex-Anleitung befolgt, kann aber WCF nicht mit Kerberos-Authentifizierung und Delegierung arbeiten lassen und würde mich über ein wenig Hilfe freuen.
Einrichtung
Ich habe den WCF-Dienst in einer IIS-Website auf einem Remote-Computer
Ich benutze Brian Booth's Debug-Site auf 8080 und die Site übergibt alle Anforderungen für die Kerberos-Delegation. Auf der Debug-IIS-Site ist die anonyme Authentifizierung deaktiviert und die integrierte Windows-Authentifizierung aktiviert.
Ich habe diese Einstellungen auf der Site gespiegelt, die den WCF-Dienst hostet.
Webdienst - Webkonfiguration (Original)
%Vor%Webdienst - Webmethode
%Vor%Client-App - App-Konfiguration
%Vor%Anwendungsfehler
Der folgende Fehler tritt auf, wenn meine Testanwendung, eine WinForms-Anwendung, versucht, die Webmethode aufzurufen:
"Die HTTP-Anfrage ist nicht autorisiert mit Client-Authentifizierungsschema 'Anonym'. Der Authentifizierungsheader vom Server empfangen wurde 'Verhandeln, NTLM'. "
Ereignisprotokoll
Der folgende Fehler ist im Ereignisprotokoll:
Ausnahme: System.ServiceModel.ServiceActivationException: Der Dienst '/ Service.svc' kann nicht sein aktiviert wegen einer Ausnahme während Zusammenstellung. Die Ausnahmemeldung ist: Sicherheitseinstellungen für diesen Dienst erfordert "Anonymous" -Authentifizierung aber Es ist nicht für den IIS aktiviert Anwendung, die diesen Dienst hostet.
Was ich nicht verstehe. Der ganze Sinn dieses Dienstes besteht darin, keine anonyme Authentifizierung zuzulassen, jeder Benutzer / jede Anfrage muss mit Kerberos-Tickets authentifiziert werden und dann an andere Maschinen weitergeleitet werden.
Wie sollte ich diesen WCF-Dienst für die Kerberos-Authentifizierung und Delegierung konfigurieren?
Revision 1
Nach dem Lesen von dieser SO-Frage habe ich den Metadatenendpunkt entfernt. Dies hat das Problem nicht gelöst.
Revision 2
Nach weiteren Recherchen habe ich ein paar Posts gefunden, die vorschlagen, wsHttpBinding zu basicHttpBinding zu ändern. Die Änderung an diesem Teil der Datei web.config wurde unten eingefügt, und der Dienstendpunkt wurde aktualisiert, um auf diese Bindung zu verweisen.
Web-Service - Web-Konfiguration (überarbeitet)
%Vor%Client-App - App-Konfiguration (überarbeitet)
%Vor%Fehler (überarbeitet)
Der aktuelle Fehler sieht so aus, als ob er einen Kerberos-Authentifizierungsheader enthält.
Die HTTP-Anfrage ist nicht autorisiert mit Client-Authentifizierungsschema 'Verhandeln'. Der Authentifizierungsheader vom Server empfangen wurde 'Verhandeln SOMEHUGESCARYKEYHERE
Für mich funktioniert das aktuelle Setup:
Auf dem Server:
%Vor%Legen Sie das folgende Attribut für alle Methoden für den WCF fest:
%Vor%Auf dem Client:
%Vor%HTH, Sven
Etwas, das ich bemerkt habe: Die Client- und Serverkonfiguration scheinen sich nicht auf den Sicherheitsmodus zu einigen.
Im ursprünglichen Abschnitt haben Sie <security>..... in der Datei web.config (die Option mode="message" ausgelassen) und <security mode="Message"> auf der Clientseite.
Nach der Bearbeitung scheint die Clientseite unverändert zu sein, aber der Server (web.config) enthält jetzt <security mode="TransportCredentialOnly"> .
Die Frage ist wirklich: Können Sie garantieren, dass es immer nur einen Netzwerkabschnitt zwischen dem Client und dem Server gibt, der aufgerufen wird? I.e. ist das hinter einer Unternehmensfirewall? In diesem Fall würde ich die netTcp-Bindung mit <security mode="Transport"> an beiden Enden empfehlen.
Wenn das nicht der Fall ist, dann geht es Ihnen entweder mit wsHttpBinding (das mehr Sicherheits- und Zuverlässigkeitsfunktionen unterstützt, aber langsamer und "schwerer" ist) oder basicHttpBinding. In diesem Fall müssten Sie <security mode="Message"> an beiden Enden verwenden und den Dienst mit einem Zertifikat authentifizieren (so dass der Dienst und der Client ein gemeinsames "Geheimnis" haben, das für die Verschlüsselung verwendet werden kann).
Ich würde versuchen, die Identitätswechsel-Teile für den Anfang auszulassen und nur die grundlegende Kommunikation und gegenseitige Authentifizierung zwischen Dienst und Client zu erhalten - sobald das vorhanden ist, können Sie beginnen, die Identitätswechsel-Bits hinzuzufügen, und Sie können immer auf eine bekannte Konfiguration zurückgreifen, die funktioniert.
David Sackstein hat eine eine großartige Reihe von Blogposts , in denen die fünf Sicherheitsszenarien erläutert werden, die der Branchenguru Juval Lowy (in seiner Programmierung WCF <) identifiziert hat / a> book - the WCF Bible) als das gebräuchlichste und nützlichste - um die Anzahl der möglichen Kombinationen von Parametern zu begrenzen, die Sie vielleicht optimieren möchten. Einer von ihnen ist ein "Internet" -Szenario, das wahrscheinlich hier gelten würde, wenn Ihr Dienst nach außen ausgerichtet ist.
Marc
Sie sollten Ihre anfängliche Konfiguration versuchen und sicherstellen, dass der IIS gleichzeitig als anonyme und Windows-Authentifizierung festgelegt wird. Der Grund ist, wenn Sie wsHttpBinding verwenden, ist die Standardsicherheit die Nachrichtensicherheit und es ist keine Transportsicherheit definiert, außer Sie möchten um https zu machen. SO Clr gibt an, dass auf dem IIS eine anonyme Authentifizierung aktiviert sein muss.
Tags und Links wcf kerberos wcf-security