Sicherheit in Windows Communication Foundation

  • Artikel

Veröffentlicht: 14. Aug 2006

Von Keith Brown

Windows Communication Foundation nimmt Ihnen viel Arbeit ab und erleichtert es Ihrem Dienst, die grundlegenden Sicherheitsfunktionen bereitzustellen, die von den meisten verteilten Systemen benötigt werden. Die drei wichtigsten Sicherheitsbereiche – Vertraulichkeit, Integrität und Authentifizierung – werden von den meisten Windows ® ** Communication Foundation-Standardbindungen abgedeckt. Wenn Sie diese Sicherheitsfunktionen nicht nutzen möchten, müssen Sie sie deaktivieren, da sie standardmäßig aktiviert sind.**

Auf dieser Seite

Vorteile der Sicherheitsfunktionen und der Autorisierung Vorteile der Sicherheitsfunktionen und der Autorisierung
Wahlmöglichkeiten in Windows Communication Foundation Wahlmöglichkeiten in Windows Communication Foundation
Transportsicherheit Transportsicherheit
Nachrichtensicherheit Nachrichtensicherheit
Anmeldeinformationen Anmeldeinformationen
Standardsicherheit in Standardbindungen Standardsicherheit in Standardbindungen
Ermitteln der Clientidentität Ermitteln der Clientidentität
Installieren eines Zertifikats mit HTTPCFG Installieren eines Zertifikats mit HTTPCFG
Schlussbemerkung Schlussbemerkung
Der Autor Der Autor

Vorteile der Sicherheitsfunktionen und der Autorisierung

Was leisten also die einzelnen Sicherheitsfunktionen? Die Vertraulichkeit wird sichergestellt, indem Nachrichten verschlüsselt werden, damit Unbefugte ("Horcher") den Inhalt nicht lesen können. Die Integritätsfunktion sorgt dafür, dass Keyed-Hash zur Berechnung einer Prüfsumme für den Inhalt jeder Nachricht verwendet wird. Auf diese Weise haben Sie die Gewissheit, dass die Nachricht nicht verändert oder als Ganzes von einem Angreifer in die Nachrichtenfolge (Message Stream) eingefügt wurde, nachdem Sie die Nachricht verfasst haben. Und natürlich hat es wenig Sinn, eine Verbindung zu verschlüsseln, wenn die Person am anderen Ende unlautere Absichten hat! Daher verwendet Windows Communication Foundation für den Austausch von Schlüsseln, die der Vertraulichkeit und Integrität dienen, einen Authentifizierungshandshake, bei dem Client und Dienst diese Schlüssel ermitteln und die Identität des jeweils anderen feststellen.

Sobald der Dienst die Identität des Clients festgestellt hat, kann er den Client zur Ausführung verschiedener Operationen autorisieren. Die Autorisierung wird durch Überprüfung von Berechtigungen (Claims) durchgeführt, die der Client angegeben hat. Windows Communication Foundation bietet eine Reihe von Erweiterungsmöglichkeiten, die es ermöglichen, die gewünschten Autorisierungsrichtlinien zugrunde zu legen und die Gültigkeit der Berechtigungen zu überprüfen. Sie können bestehende Komponenten wie die ASP.NET-Mitgliedschaft und Role Provider sowie Authorization Manager (AzMan) verwenden (weitere Einzelheiten über die Anwendung finden Sie unter msdn.microsoft.com/msdnmag/issues/03/11/AuthorizationManager (in englischer Sprache)). Sie können auch die standardmäßige rollenbasierte .NET-Sicherheitsinfrastruktur mit den Eigenschaften Thread.CurrentPrincipal, IPrincipal.IsInRole und PrincipalPermissionAttribute verwenden. Sie können aber auch das Framework der Autorisierungsrichtlinien in Windows Communication Foundation verwenden, das um die IAuthorizationPolicy-Schnittstelle konstruiert wurde, die eine sorgfältige, detaillierte Kontrolle der Berechtigungen ermöglicht. Darüber hinaus können Sie die Aktionen des Clients prüfen. Sie werden feststellen, dass Windows Communication Foundation bereits standardmäßig viele Sicherheitsereignisse überprüft.

Transparenz ist bei der Erstellung eines Sicherheitssystems wichtig. Wenn die Sicherheitsfunktionen, die Sie in ein System integriert haben, nicht ausreichend transparent sind, werden Benutzer sie ablehnen und versuchen, sie zu umgehen. Traurig aber wahr: Wenn man für Sicherheit zuständig ist, ist die eigene Arbeit dann am besten, wenn man sie gar nicht wahrnimmt! Windows Communication Foundation hilft Ihnen dabei, Transparenz auf vielerlei Weise zu erreichen, eines der wichtigsten Verfahren ist dabei das Single-Sign-On-Verfahren (SSO). Durch eine enge Verknüpfung mit der Windows-Domänenauthentifizierung können Sie die Domänenanmeldeinformationen des Benutzers wiederverwenden und die Menge der Anmeldedaten beschränken, die der Benutzer benötigt. Windows Communication Foundation vereinfacht zudem die Verwendung verbundener Identitäten, die es Partnerunternehmen ermöglicht, dasselbe SSO-Verfahren auch dann zu verwenden, wenn sie Webdienste nutzen, die Ihr Unternehmen verfügbar macht.

Ein weiterer wichtiger Sicherheitsaspekt ist die Form bösartiger Inhalte. Windows Communication Foundation kann dieses Problem nicht wirklich lösen, daher liegt es weiterhin in Ihrer Verantwortung, davon auszugehen, dass alle eingehenden Inhalte bösartig sind, sofern kein Beweis für das Gegenteil vorliegt. Zudem dürfen Sie nie annehmen, dass ein authentifizierter Benutzer Ihnen keine bösartigen Inhalte senden wird! Selbst wenn Sie nur interne Clients bedienen, müssen Sie auf Sicherheit achten. Was ich meine, ist die Widerstandsfähigkeit gegen SQL-Injektionsangriffe, falsch gebildete Ressourcennamen wie Dateipfade und in einigen Fällen sogar siteübergreifende Skripts. Wenn Sie jemanden sagen hören "Windows Communication Foundation ist bereits in der Standardkonfiguration sicher", können Sie davon ausgehen, dass die oben genannten Sicherheitsfunktionen gemeint sind.

Wahlmöglichkeiten in Windows Communication Foundation

Windows Communication Foundation vereint die wichtigsten Funktionen der zahlreichen Kommunikationsstacks, die wir in der Vergangenheit einzeln verwendet haben. Das bedeutet, dass Sie viele Entscheidungen treffen müssen, wenn Sie einen Dienst verfügbar machen, und einige dieser Entscheidungen beeinflussen die Sicherheit. Die wichtigste Entscheidung betrifft die zu verwendende Bindung. Sollen Nachrichten in eine Warteschlange eingefügt werden? Wünschen Sie Interoperabilität oder einfache Leistungsfähigkeit?

Denken Sie immer daran, dass Sie nicht nur eine Entscheidung treffen müssen. Sie können einen einzelnen Servicevertrag über so viele Bindungen verfügbar machen, wie Sie möchten. Stellen Sie einfach für jede Bindung einen anderen Endpunkt bereit. Sie könnten beispielsweise eine ganz einfache WS-I-Basisprofilbindung über HTTPS verfügbar machen, um mit bestehenden Partnern einer Lieferkette zusammenzuarbeiten. Gleichzeitig können Sie einen TCP-Endpunkt verfügbar machen, der die Windows-Authentifizierung für lokale Clients in Ihrer Domäne verwendet. Das funktioniert jedoch nur dann, wenn der Benutzer nicht die Eigenschaft ProtectionLevel im Vertrag definiert (mit ServiceContract, OperationContract, MessageHeader usw.).

Eine typische Standardbindung umfasst eine Vielzahl verschiedener Parameter für Sicherheitseinstellungen, jedoch bieten alle Bindungen in der Standardeinstellung geeigneten Schutz für die meisten Situationen, die auftreten können. Die Parameter, deren Einstellung Sie am häufigsten ändern müssen, sind der Sicherheitsmodus (Transport- oder Nachrichtensicherheit) und der Client-Anmeldedatentyp. Diese Parameter sind besonders wichtig, weshalb ich im Folgenden näher auf sie eingehe.

Transportsicherheit

Wenn Sie die Sicherheit für eine Windows Communication Foundation-Bindung konfigurieren, müssen Sie als Erstes festlegen, ob die Sicherheitsfunktionen (Vertraulichkeit, Integrität und Authentifizierung) auf Transportebene oder auf Nachrichtenebene bereitgestellt werden sollen. Beide Möglichkeiten haben Vor- und Nachteile.

Wenn Sie wsHttpBinding für die Transportsicherheit konfigurieren, ist die Vertraulichkeit, Integrität und Authentifizierung durch Windows Communication Foundation nicht gewährleistet. Es wird vorausgesetzt, dass Sie HTTPS verwenden, sodass Secure Sockets Layer (SSL) diese Sicherheitsfunktionen übernimmt. Daher verweigert Windows Communication Foundation die Einrichtung der Verbindung, wenn kein URI für HTTPS vorhanden ist. Wenn Sie IIS für das Hosting verwenden, müssen Sie ein SSL-Zertifikat für die Website installieren. Wenn Sie hingegen Ihren eigenen Prozess für das Hosting verwenden und HTTP.SYS direkt nutzen, müssen Sie ein Zertifikat in HTTP.SYS registrieren, entweder programmtechnisch oder über das Befehlszeilentool HTTPCFG.EXE.

Gute Gründe sprechen für die Verwendung von SSL. Da es SSL schon seit so vielen Jahren gibt, wurde es von Kryptografen ausgiebig analysiert, und Administratoren kennen sich in der Bereitstellung aus. Zudem wird Hardware angeboten, die SSL beschleunigen kann und die Last für die CPU des Servers herabsetzt. Wenn Sie eine große plattformübergreifende Reichweite anstreben, gibt es zudem derzeit keine bessere Wahl als die Verwendung des WS-I-Basisprofils über SSL (was natürlich die Verwendung von basicHttpBinding anstatt von wsHttpBinding nach sich zieht).

Für die interne Kommunikation in einer Domänenumgebung, in der sowohl der Client als auch der Dienst Windows Communication Foundation verwenden, ist netTcpBinding mit Transportsicherheit möglicherweise eine bessere Wahl. Seine Leistungsfähigkeit ist aufgrund der binären Codierung sicher sehr viel größer, und da es Kerberos ausschließlich standardmäßig verwendet, sind keine Zertifikate nötig. Allerdings sollten Sie einen Dienstprinzipalnamen konfigurieren (siehe die Zusatzinformation "Konfigurieren eines Dienstprinzipalnamens (Service Principal Name, SPN)").

Nachrichtensicherheit

Anstatt die Sicherheitsfunktionen nur auf der Transportebene bereitzustellen, können Sie diese Informationen an die SOAP-Nachrichten selbst übergeben, indem Sie die Nachrichtensicherheit verwenden. Der Hauptvorteil liegt in der Flexibilität. Die WS-Sicherheit sowie die damit verbundenen Spezifikationen für die Sicherheit der SOAP-Nachrichten sind sehr flexibel. Sie können beliebige Arten von Anmeldeinformationen weitgehend unabhängig vom Transport verwenden, vorausgesetzt, dass Client und Dienst übereinstimmen. Sie können sogar mehrere Anmeldedatensätze senden, was bei der Delegierung nützlich ist, wenn Zwischenknoten verwendet werden.

Ein Beispiel dafür ist wsHttpBinding. Standardmäßig verwendet sie die Nachrichtenebenensicherheit, da sie voraussetzt, dass der Dienst und der Client sich gegenseitig anhand von Windows-Anmeldeinformationen identifizieren und authentifizieren. Bei Standardkonfiguration werden der Nachrichtentext und die meisten Header signiert, um die Integrität der Nachricht zu erhalten (d. h. es werden alle WS-Adressheader signiert und alle Anwendungsheader verschlüsselt und signiert), und der Nachrichtentext wird verschlüsselt. Ein Angreifer, der Nachrichten-Ablaufverfolgungsinformationen einsieht, würde den SOAP-Umschlag deutlich sehen, jedoch enthielte der SOAP-Text das Element <EncryptedData> mit base64-codiertem, verschlüsselten Text.

Windows Communication Foundation ermöglicht es Ihnen zudem, Transportsicherheit mit Nachrichtensicherheit zu mischen. In diesem Modus werden Vertraulichkeit, Integrität und die Serverauthentifizierung auf Transportebene sichergestellt (daher wird der gesamte Bytestream und nicht nur der Nachrichtentext verschlüsselt), während die Client-Authentifizierung auf der Nachrichtenebene durchgeführt wird. Der Client kann dann die WS-Sicherheit zum Senden beliebiger Arten von Anmeldeinformationen verwenden. Bei diesem Modus werden die Leistungsfähigkeit und die Ausgereiftheit der Transportsicherheit mit erhöhter Flexibilität bei der Wahl der Anmeldeinformationen verknüpft.

Anmeldeinformationen

Nachdem Sie entweder Transport- oder Nachrichtensicherheit (oder den Mischmodus) gewählt haben, d. h. unter der Annahme, dass Sie nicht die Option "None" (Keine) für den Sicherheitsmodus eingestellt haben, müssen Sie als Nächstes die Art der Anmeldeinformationen festlegen, die Client und Dienst verwenden sollen. Windows Communication Foundation vereinfacht diesen Vorgang, indem es Ihnen nur einen Parameter – den Anmeldeinformationstyp – bietet, der zudem den erforderlichen Anmeldeinformationstyp für den Dienst im jeweiligen Szenario bestimmt. Es gibt wenigstens fünf Optionen für Client-Anmeldeinformationen, wenngleich einige Optionen in bestimmten Situationen möglicherweise nicht verfügbar sind.

Die erste Option lautet "None" (Keine), bei der der Client anonym bleibt. In diesem Fall verwendet der Dienst ein Zertifikat, um dem Client Gewissheit über die Identität des Dienstes zu geben. Das ist vergleichbar mit dem Besuch einer typischen Website über ein sicheres Protokoll (HTTPS).

Die zweite Option ist "UserName" (Benutzername), bei der der Benutzer des Clients einen Benutzernamen und ein Kennwort angeben muss. Auch in diesem Fall verwendet der Dienst ein Zertifikat, um sich gegenüber dem Client zu identifizieren. Dieses Zertifikat wird auch dazu verwendet, die Anmeldeinformationen des Clients für die Übermittlung an den Dienst zu verschlüsseln.

Eine weitere Option lautet "Windows". Dabei verwenden sowohl der Client als auch der Dienst ein Windows-Konto zur Authentifizierung. Windows Communication Foundation verhandelt Kerberos- oder NTLM-Authentifizierung, vorzugsweise jedoch Kerberos, wenn eine Domäne vorhanden ist (NTLM authentifiziert den Dienst nicht gegenüber dem Client, sondern nur den Client gegenüber dem Dienst). Wenn Sie Kerberos verwenden möchten, ist es wichtig, dass der Client den Dienst anhand eines Dienstprinzipalnamens (SPN) in der CONFIG-Datei identifiziert. Wenn Sie einen Dienst für Clients in einer Domänenumgebung erstellen, sollten Sie es Clients unbedingt ermöglichen, Windows-Anmeldedaten zu senden. Dann können sie ihre bestehenden Windows-Anmeldedaten verwenden und ganz nebenbei auch noch SSO nutzen!

"Certificate" (Zertifikat) ist wieder eine andere Option, bei der sowohl der Dienst als auch der Client über ein eigenes Zertifikat verfügen. Das ist für viele Business-to-Business-Szenarios der heutigen Zeit typisch.

"IssuedToken" (ausgegebenes Token) schließlich gestattet es Ihrem Dienst, einen signierten Satz Berechtigungen von einem Security Token Service (STS) entgegenzunehmen. Wenngleich diese Option Ihnen zu Anfang vielleicht fremdartig erscheint, gewinnt sie später an Bedeutung, da sie verbundene Identitäten und InfoCard unterstützt. Wenn Sie ein Bündnis mit einem Partnerunternehmen eingehen, gestatten Sie es dem Partner, seine Benutzer anhand eines Verfahrens zu authentifizieren, das für diese sinnvoll erscheint. Im günstigsten Fall können die Benutzer im Partnerunternehmen Ihren Dienst mit SSO verwenden, und zwar auch dann, wenn sie keine Active Directory-Domäne gemeinsam mit Ihnen nutzen und keine Vertrauensstellung ermittelt wurde. Die Benutzer im Partnerunternehmen müssen die Authentifizierung anhand eines STS durchführen, der ein SAML-Token ausgibt (SAML = Security Assertion Markup Language). Sie können das Token entweder direkt akzeptieren oder definieren, dass das Token einem STS in Ihrem Unternehmen vorgelegt wird, damit er die Berechtigungen des Partners prüfen und ein zweites SAML-Token ausgeben kann, das Sie verwenden können.

In jedem Fall empfängt Ihr Dienst ein Sicherheitstoken, das von einem vertrauenswürdigen STS ausgegeben wurde. Windows Communication Foundation prüft die Signatur und Vertrauenswürdigkeit und legt die Berechtigungen im Token über eine ServiceSecurityContext-Instanz Ihrem Dienst vor. Ihr Dienst kann während der Verarbeitung einer Anforderung auf dieses Objekt zugreifen, indem er die statische Eigenschaft ServiceSecurityContext.Current liest. Sie können diese Informationen anschließend zur Durchführung sowohl der Autorisierung als auch der Überwachung verwenden.

Ein großer Pluspunkt des Identitätsverbunds liegt darin, dass bestehende Vertrauensbeziehungen zwischen Partnern automatisiert werden: Wenn verbundene Identitäten verwendet werden, brauchen Sie keine Windows-Schattenkonten oder -zertifikate an jeden Benutzer im Partnerunternehmen auszugeben. Die Automatisierung dieser Beziehungen birgt eine große Zahl von Vorteilen. Die Automatisierung verringert Fehler und Latenzzeiten, was bedeutet, Sie erhalten genauere und aktuellere Informationen über die Benutzer im Partnerunternehmen. Darüber hinaus sinken die Kosten für das IT-Personal, da keine Benutzerkonten für Partner erstellt werden müssen. Verbundene Identitäten ist ein wichtiges Thema, mit dem ich mich in einem anderen Beitrag eingehender befassen werde.

Standardsicherheit in Standardbindungen

Die drei meistverwendeten Standardbindungen sind basicHttpBinding, wsHttpBinding und netTcpBinding. Die einfachste Bindung, die zudem die größte Interoperabilität bietet, ist basicHttpBinding. Sie unterstützt das Basisprofil WS-I. Dabei ist zu beachten, dass diese Bindung die Sicherheitsfunktionen Vertraulichkeit, Integrität und Authentifizierung nicht wie die meisten anderen standardmäßig umfasst. Üblicherweise wird die Sicherheit dieser Bindung hergestellt, indem HTTPS (das SSL nutzt) zur Ausführung verwendet wird. Zu diesem Zweck müssen Sie die Bindung anpassen, damit Windows Communication Foundation erkennt, dass Sie Transportsicherheit verwenden werden:

<bindings>
  <basicHttpBinding>
    <binding name="MyBindingTweaks">
      <security mode="Transport">
        <transport clientCredentialType="None"/>
      </security>
    </binding>
  </basicHttpBinding>
</bindings>

Nachdem Sie das getan haben, besteht die einfachste Möglichkeit der Bereitstellung darin, das Hosting in IIS durchzuführen und SSL-Unterstützung für Ihr virtuelles Verzeichnis zu aktivieren (das bedeutet, Sie müssen ein Zertifikat für die Website installieren, sofern Sie es nicht bereits getan haben). Beachten Sie, dass ich in dieser speziellen Bindung anonyme Clients zugelassen habe. Wenn Sie IIS zur Bereitstellung nutzen und beabsichtigen, Client-Zertifikate anzufordern, ändern Sie clientCredentialType in "Certificate".

Die nächste Bindung, wsHttpBinding, verwendet standardmäßig Nachrichtensicherheit und nutzt hierzu WS-Sicherheit und WS-SecureConversation. Der Standardtyp für Client-Anmeldeinformationen ist "Windows". Diese Option kann direkt genutzt werden, da einfach die Windows-Anmeldung des Clients und des Dienstes als Anmeldeinformationen verwendet werden. Eine der am häufigsten durchgeführten Sicherheitsanpassungen dieser Bindung ist das Umschalten auf TransportWithMessageCredential. Dann wird ein HTTPS-Endpunkt für eine beschleunigte Serverauthentifizierung, Integrität und Vertraulichkeit verwendet, während die Client-Anmeldeinformationen aus Flexibilitätsgründen im SOAP-Sicherheitsheader bleiben. Ein Vorteil dieser Technik ist es, dass der gesamte SOAP-Umschlag vom Transport verschlüsselt wird, einschließlich aller Header. Zudem können Sie Hardwarebeschleunigung verwenden, um die CPU Ihres Servers von Secure Sockets Layer/Transport Layer Security (SSL/TLS) zu entlasten. Es gibt jedoch auch ein paar Nachteile wie beispielsweise das Fehlen von End-to-End-Sicherheit auf Nachrichtenebene. Das folgende Beispiel zeigt, wie Sie diese Bindungsanpassung vornehmen, um ein SAML-Token auf Nachrichtenebene zu akzeptieren:

<binding name="MyBindingTweaks">
  <security mode="TransportWithMessageCredential">
    <transport clientCredentialType="None"/>
    <message clientCredentialType="IssuedToken"/>
  </security>
</binding>

Wenn Sie Geschwindigkeit für Webdienste in einem Windows-basierten Intranet wünschen, sollten Sie die Verwendung von netTcpBinding ernsthaft in Betracht ziehen. Sie codiert jeden SOAP-Umschlag anhand einer proprietären Binärcodierung des Definitionssatzes von XML Infoset anstatt der herkömmlichen Codierung mit eckigen Klammern. Diese Bindung verwendet standardmäßig Transportsicherheit mit Windows-Anmeldeinformationen und ist sehr effizient. Sie kommt dem Leistungs- und Sicherheitsmodell DCOM wahrscheinlich am nächsten. Die Standardbindung verwendet Transportsicherheit mit verhandelter Authentifizierung. Bei der Verhandlung wird versucht, Kerberos zu verwenden. Gelingt das nicht, wird auf das ältere Protokoll NTLM zurückgegriffen. Kerberos ist eine gute Wahl, wenn Sie sich in einer Domänenumgebung befinden. Um das Protokoll zu verwenden, müssen sowohl für Ihren Dienst als auch Ihre Clients Domänenkonten eingerichtet sein. Sie sollten zudem einen Dienstprinzipalnamen (SPN) für Ihren Dienst konfigurieren (siehe hierzu die Zusatzinformationen auf dieser Seite). Die Clients müssen ihre Endpunktbeschreibungen anpassen, um die Identität des Dienstes aufzunehmen. Dabei handelt es sich um den SPN, bei dem sich der Dienst angemeldet hat. (Dies ist nicht immer erforderlich. Wird der Dienst in IIS gehostet und unter dem NetworkService-Konto ausgeführt, wird der SPN automatisch aufgerufen. Windows Communication Foundation leitet ihn korrekt vom URL auf der Client-Seite ab.) Es folgt die Syntax für die CONFIG-Datei. Achten Sie auf das Element servicePrincipalName:

<client>
  <endpoint name="MyEndpoint" address="net.tcp://..." 
    binding="netTcpBinding" contract="IFoo" >
    <identity>
      <servicePrincipalName value='MyService/MyMachine' />
    </identity>
  </endpoint>
</client>

Wenn das Windows Communication Foundation-System den Domänencontroller nach einem Kerberos-Authentifizierungsticket für den Dienst fragt, verwendet es gewöhnlich den Namen MyService/MyMachine für die Anforderung; und sofern dieser SPN in Active Directory für das Domänenkonto des Dienstes registriert wurde, wird das Ticket für den Client ausgestellt und Kerberos verwendet. Anderenfalls, wenn Kerberos verfügbar, aber der SPN falsch ist, tritt eine Ausnahme auf. Ist Kerberos hingegen für die Authentifizierung des Dienstes nicht verfügbar, erhält der Client kein Ticket (was einen erfolglosen Round-Trip zum Domänencontroller bedeutet) und der NTLM-Fallback-Modus wird eingeleitet, was zu weiteren Round-Trips für die Verhandlung erneuter Zugriffe führt. So kommen Sie zudem nicht in den Genuss von Kerberos-Funktionen wie der Möglichkeit zur Delegierung von Client-Anmeldeinformationen.

Ermitteln der Clientidentität

Der einfachste Weg, die Identität eines Clients zu ermitteln, besteht darin, Thread.CurrentPrincipal zu verwenden, denn das ist das Standardverfahren in .NET; Systeme wie ASP.NET und Windows Communication Foundation geben die Identität eines authentifizierten Clients an Ihren Code weiter. Diese fast "magische" statische Eigenschaft gibt dann je nach dem Thread, von dem die Anforderung stammt, unterschiedliche Werte aus. Dadurch wird es möglich, dass mehrere Threads unterschiedliche Clients bedienen und jeweils deren Identität sehen, ohne sich gegenseitig in die Quere zu kommen.

Wenn Sie "Windows" als clientCredentialType angegeben haben, verweist Thread.CurrentPrincipal auf einen WindowsPrincipal-Namen, und Sie können sehen, zu welchen Gruppen der Benutzer gehört, indem Sie WindowsPrincipal.IsInRole aufrufen. Der einzige Nachteil dabei ist, dass Sie aus Sicherheitsgründen den vollständigen qualifizierten Gruppennamen angeben sollten, d. h. einschließlich der Domäne bzw. des Computers, in der/auf dem die Gruppe definiert ist:

IPrincipal client = Thread.CurrentPrincipal;
if (client.IsInRole(@"MyMachine\Managers")) {
    // allow client to do manager stuff
}

Wenn ich Systeme erstelle, die auf der Grundlage von Gruppen wie dieser autorisieren, füge ich gewöhnlich ein gewisses Maß an Dereferenzierung hinzu, die den Computer- oder Domänennamen für die Gruppen anhand der CONFIG-Datei ermittelt. Das vereinfacht die Bereitstellung ungemein.

Auf die Autorisierung werde ich in einem Folgebeitrag näher eingehen, denn zu diesem Thema gibt es noch viel zu sagen. Beachten Sie, dass Windows Communication Foundation Thread.CurrentPrincipal nicht immer einstellt. Das ist nur dann der Fall, wenn PrincipalPermissionAttribute verwendet wird oder die Konfiguration dies erfordert. Anstatt auf Thread.CurrentPrincipal zurückzugreifen, sollten Sie ServiceSecurityContext.Current.WindowsIdentity verwenden, um die Identität des Clients zu ermitteln, sofern eine verfügbar ist. Und so ermitteln Sie den Namen des Clients, wenn Sie die Aktivität des Clients protokollieren möchten:

string clientAccountName = 
    ServiceSecurityContext.Current.WindowsIdentity.Name;

Wenn der Client eine ausgegebene Token-Anmeldeinformation zur Authentifizierung verwendet, müssen Sie ServiceSecurityContext.AuthorizationContext verwenden, um diese Details zu erfassen. Wenn der Client die Authentifizierung mit einem Zertifikat durchführt, das keinem Windows-Konto zugeordnet ist, kann ServiceSecurityContext.Current.PrimaryIdentity verwendet werden. Das werde ich zu einem späteren Zeitpunkt näher ausführen.

Installieren eines Zertifikats mit HTTPCFG

Wenn Sie SSL verwenden möchten, Ihren Dienst jedoch nicht in IIS hosten wollen, können Sie SSL-Unterstützung durch Verwendung von HTTP.SYS erreichen. Um die SSL-Unterstützung in HTTP.SYS nutzen zu können, müssen Sie HTTP.SYS anweisen, wo das SSL-Zertifikat abgelegt ist. Hierzu können Sie die API von HTTP verwenden, oder Sie rufen die APIs mit HTTPCFG.EXE von der Befehlszeile aus auf. HTTPCFG.EXE ist nicht standardmäßig installiert, jedoch können Sie sie nutzen, nachdem Sie die Supporttools aus dem Verzeichnis SUPPORT\TOOLS des Installationsverzeichnisses Ihres Betriebssystems installiert haben.

Wenn Sie ein Zertifikat mit HTTP.SYS verwenden möchten, müssen Sie es im lokalen Speicher des Computers installieren, nicht im Benutzerspeicher. Sie können dies tun, indem Sie das Snap-in Certificates Microsoft® Management Console (MMC) ausführen. Wenn Sie das Snap-in hinzufügen, wählen Sie die Option "Computer Account" (Computerkonto), wenn Sie danach gefragt werden, und geben Sie dann den Computer an, auf dem der Dienst bereitgestellt wird, oder wählen Sie "Local Computer" (Lokaler Computer), wenn Sie bereits auf diesem Computer angemeldet sind. Importieren Sie das Zertifikat dann in den persönlichen Speicher des Computers. Der persönliche Speicher ist der, in dem Sie gewöhnlich Zertifikate ablegen, für die Sie einen privaten Schlüssel besitzen.

Zeigen Sie die Details des Zertifikats an und laden Sie den Sha1-Fingerabdruck des Zertifikats (siehe Abbildung 1). Diese Eigenschaft verwendet HTTP.SYS bei der Suche nach Zertifikaten, weshalb Sie diesen Wert benötigen. Und so registrieren Sie das Zertifikat in HTTP.SYS von einer Eingabeaufforderung auf dem Computer aus, auf dem der Dienst bereitgestellt wird:

HTTPCFG add ssl -i 0.0.0.0:4242 31883a61892d8c...

Zertifikatsfingerabdruck
Abbildung 1:   Zertifikatsfingerabdruck

Die erste Zahl, die Sie sehen, ist die IP-Adresse 0.0.0.0, die für alle IP-Adressen steht, die der Computer haben kann. Wenn Sie die Bindung zu einer bestimmten IP-Adresse herstellen, sollten Sie stattdessen diesen Wert verwenden. Als Nächstes folgt die Nummer des Ports, an dem der Dienst wartet. Die letzte Angabe ist der Fingerabdruck. (Sie müssen die Leerzeichen zwischen den Bytes entfernen, wenn Sie ihn aus dem Anzeigefenster des Zertifikats kopieren.) Ich habe nur den ersten Teil des Hashwertes angezeigt, da er 20 Byte lang ist.

Schlussbemerkung

Dieser Artikel ist der erste einer Reihe von Beiträgen, die ich über die Sicherheit in Windows Communication Foundation zu schreiben plane. Im vorliegenden Artikel habe ich die Sicherheitsfunktionen vorgestellt und einige der grundlegenden Einstellungen beschrieben, die Sie vornehmen müssen, um die von Ihnen erstellten Dienste zu sichern. Wie Sie sehen konnten, bietet Windows Communication Foundation Nachrichtenvertraulichkeit, -integrität und -authentifizierung über viele verschiedene Bindungen, wobei die Sicherheit der meisten Bindungen standardmäßig gewährleistet ist. Die von mir vorgestellten Tipps zur Anpassung der Bindungen helfen Ihnen dabei, diese Funktionen optimal zu nutzen. In Folgebeiträgen werden ich auf andere Aspekte der Sicherheit in Windows Communication Foundation eingehen, unter anderem die berechtigungsbasierte Autorisierung sowie andere interessante Themen. Bleiben Sie am Ball!

Senden Sie Fragen und Kommentare an Keith Brown an  briefs@microsoft.com (in englischer Sprache).

Der Autor

Keith Brown ist Mitgründer von Pluralsight, einem führenden Microsoft .NET-Schulungsanbieter. Keith Brown ist der Autor des Pluralsight-Kurses "Applied .NET Security" sowie mehrerer Bücher, unter anderem "The .NET Developer's Guide to Windows Security", das als Druckversion und im Internet erhältlich ist. Weitere Informationen finden Sie unter www.pluralsight.com/keith.

Aus der Ausgabe August 2006 des MSDN Magazine.