Monthly Archives: November 2010

Double-Hop, WCF-Sessions und HTTPS…

This site is under construction.

So stay tuned…

Ein neuer Tag, ein neues Projekt…

Ein Projekt mit etwas „verzwickteren“ Anforderungen…

Wer kennt es nicht: Man meldet sich an seinen Rechner an, benutzt ein Programm, und beendet es wieder. Alles ganz normal. Was zum Teil für eine Technik dahintersteckt, wird einem nicht ersichtlich. Allein so eine feine Sache wie Single Sign-On ist vielen nicht bekannt, und diejenigen, die wissen, was dahinter steckt,  möchten es nicht mehr missen.

Gut, diese Story geht noch ein bisschen darüber hinaus. Soll aber auch nicht so wichtig sein. Fangen wir am besten mal an…

Für einen Kunden sollen wir eine Software-Lösung entwickeln. Es soll dabei aus zwei Teilen bestehen: dem Webservice, der die Daten bereitstellt, und ein Client, der auf die vom Webservice bereitgestellten Daten zugreift und diese dem Benutzer präsentiert. Zusätzlich befindet sich im Hintergrund eine Datenbank, in der sich die Daten, die vom Webservice bereitgestellt werden, befinden.

Soweit alles noch kein Problem, ist ja nichts Ungewöhnliches. Das Rollen-Rechte-Konzept sieht nun vor, dass der Benutzer des Clients mittels Windows-Authentifizierung am Service angemeldet wird und die Credentials dann benutzt werden, um sich an der Datenbank selbst ebenfalls per Windows-Authentifizierung anzumelden. Man ahnt nichts Böses…

Double Hop Issue

Doch genau hier steckt der Teufel im Detail: Die Credentials müssen vom Client an den WebServer und von diesem aus an den DBServer weitergegeben werden. Befinden sich diese auf verschiedenen physikalischen Maschinen, so hat man ein Problem: das Double Hop Issue. Standardmäßig ist es nämlich nicht möglich/erlaubt, die Credentials weiterzugeben. Hierzu müssen ein paar Anforderungen an die Infrastruktur erfüllt werden:

  • Die Domäne befindet sich mindestens in der Domänenfunktionsebene Windows Server 2003
  • Benutzer melden sich mittels Windows-Authentifizierung am Webservice an
  • Autorisierte Benutzer der Datenbank werden mit der Windows-Authentifizierung eingetragen
  • Das Kerberos-Token muss vom WebServer an den DBServer weitergegeben werden (Einrichtung der Delegation)

In welcher Domänenfunktionsebene die Domäne arbeitet, lässt sich relativ schnell im MMC-SnapIn „Active Directory-Benutzer und -Computer“ herausfinden. Eigenschaften der Domäne öffnen, dort steht dann auch schon die Funktionsebene unter der Registerkarte „Allgemein“. Eventuell muss man sie noch heraufstufen; dies geschieht im Kontextmenü der Domäne.

Die Windows-Authentifizierung im IIS lässt sich unter den Eigenschaften der Website->Verzeichnissicherheit->Authentifizierung und Zugriffsteuerung aktivieren. Den anonymen Zugriff lassen wir zunächst noch aktiviert.

Die Einrichtung der Benutzer für die Datenbank erkläre ich jetzt nicht, da man hier selber entscheiden soll,  ob nun jeder Benutzer einzeln eingetragen oder man das lieber über eine eigene Gruppe, die im Active Directory hinterlegt ist, regelt.

Letzter Punkt: Einrichtung der Delegation. Damit das Kerberos-Token erfolgreich seinen Weg vom Client über den WebServer zur DB findet, müssen die „Service Principal Names“ korrekt registriert und die Delegation zwischen den einzelnen Computerkonten eingerichtet werden. Hierzu auf dem Domain Controller folgendes ausführen:

setspn -l <dbserver>

Sollte man hier Einträge nach dem Schema „MSSQLSvc/<dbserver>“ sowie „MSSQLSvc/<dbserver-fqdn>“ finden, so ist dies schon mal nicht schlecht. Ansonsten müssen diese noch über folgende Befehle registriert werden:

setspn –a MSSQLSvc/<dbserver>:<Port bzw. Name der SQL Server-Instanz>
setspn –a MSSQLSvc/<dbserver-fqdn>:<Port bzw. Name der SQL Server-Instanz>

Ist dies geschehen, machen wir uns auf und suchen das Computerkonto des Rechners, auf dem der Webservice läuft. In den Eigenschaften des Kontos wählen wir die Registerkarte „Delegation“, und wählen hier „Computer bei Delegierungen angegebener Dienste vertrauen“->“Nur Kerberos verwenden“. Unter Hinzufügen->Benutzer oder Computer geben wir nun den Rechnernamen des DBServers ein, und wählen nach einem Klick auf OK den MSSQLSvc-Eintrag aus. Ein weiterer Klick auf OK, und die Konfiguration sollte damit fertig sein.

Anpassung der WCF-Webservices

Leider habe ich die genaue Konfiguration über HTTP nicht mehr vor Augen, es soll jedoch gesagt sein, dass wir als Binding das wsHttpBinding einsetzten. Die Umstellung des Bindings auf SSL gab dann aber Probleme: Sobald wir

<wsHttpBinding><binding name="wsHttpsBinding"><security mode="Transport"><transport clientCredentialType="Windows"></security></binding></wsHttpBinding>

als bindingConfiguration der Endpoints in der web.config benutzten, schmiss uns der Service eine Fehlermeldung entgegen, dass das Binding keine Sessions unterstützt oder diese nicht richtig konfiguriert seien. Die genaue Ursache ist uns bisher noch nicht klar, da es an sich zwei verschiedene Baustellen sind.

Die Lösung brachte uns ein CustomBinding mit folgenden Parametern:

<customBinding><binding name="customHttpsBinding"><reliableSession /><httpsTransport authenticationScheme="Negotiate" /></binding></customBinding>

Was noch zu erwähnen ist: Wenn die Endpoints mittels bindingConfiguration auf HTTPS umgestellt werden, sollten/müssen die Bindings der Metadata-Exchange-Endpoints (kurz: mex) auf „mexHttpsBinding“ umgestellt werden. Hier ein kurzes Beispiel:

<endpoint address="mex" binding="mexHttpsBinding" contract="IMetadataExchange" />

Dann noch unter

<behaviors><serviceBehaviors><behavior name="de.ecw.prunkster.TestService"><serviceMetadata httpsGetEnabled="true"></behavior></serviceBehaviors></behaviors>

sicherstellen, dass auch wirklich httpsGetEnabled auf true gesetzt ist. Das sollte es dann gewesen sein.