Sicherheitsarchitektur

Artikel
02/27/2011

In diesem Abschnitt werden verschiedene Erweiterbarkeitspunkte beschrieben, die zum Ändern oder Erweitern der Funktionen der Windows Communication Foundation (WCF)-Sicherheitskomponente verwendet werden können. Zum Verständnis der Funktionsweise dieser Erweiterungspunkte sollte Ihnen die gesamte WCF-Sicherheitsarchitektur vertraut sein. In diesem Thema wird die WCF-Sicherheitsarchitektur hinsichtlich ihrer Komponenten und Beziehungen beschrieben. Außerdem wird weiter unten in diesem Abschnitt beschrieben, wie die Erweiterungspunkte in das gesamte Architekturmodell passen.

Bereich der WCF-Sicherheitskomponente

Die WCF-Sicherheit betrifft mehrere Komponenten der WCF-Architektur. Das Hauptziel der Sicherheit von WCF ist Integrität, Vertraulichkeit, Authentifizierung und Autorisierung sowie Überwachung für die Anwendungen, die mit dem WCF-Framework darauf aufbauen. Bei der WCF-Architektur werden diese Funktionen in folgende Teile aufgeteilt:

Übertragungssicherheit: Zuständig für die Nachrichtenvertraulichkeit, die Datenintegrität und die Authentifizierung der Kommunikationspartner.
Autorisierung: Zuständig für die Bereitstellung eines Frameworks zum Treffen von Autorisierungsentscheidungen.
Überwachung: Zuständig für die Protokollierung von sicherheitsrelevanten Ereignissen im Überwachungsprotokoll.

Sicherheitsmodi und Umfang dieses Dokuments

Die Übertragungssicherheit kann mithilfe der folgenden Sicherheitsmodi ausgeführt werden:

Transport. Alle drei Kommunikationssicherheitsfunktionen werden vom Transport bereitgestellt, der zum Übertragen von Nachrichten zwischen Client und Dienst verwendet wird.
Nachricht. Die Übertragungssicherheit wird lediglich auf der SOAP-Nachrichtenebene bereitgestellt. Das bedeutet, dass die Sicherheit direkt auf die SOAP-Nachricht auf XML-Ebene angewendet wird.
Transport mit Nachrichtenanmeldeinformationen. Die Übertragungssicherheit wird sowohl auf Transport- als auch auf Nachrichtenebene ausgeführt. Die Transportebene bietet Kommunikationsvertraulichkeit, Datenintegrität und Dienstauthentifizierung. Die Nachricht bietet eine Clientauthentifizierung.

Der Rest dieses Dokuments konzentriert sich auf den Nachrichtensicherheitsmodus, obwohl einige dieser Informationen auf den Modus Transport mit Nachrichtenanmeldeinformationen angewendet werden können. Insbesondere gilt der Teil dieser Dokumentation, der sich auf die Clientauthentifizierung bezieht, auch für den Modus Transport mit Nachrichtenanmeldeinformationen, da in diesem Modus die Nachrichtenebene für die Clientauthentifizierung genauso verwendet wird wie im Nachrichtenmodus.

Die Beschreibungen der Autorisierungs- und Überwachungskomponenten gelten für alle drei Sicherheitsmodi auf dieselbe Weise. Deshalb gelten alle in diesem Dokument beschriebenen Informationen, die sich auf diese Komponenten beziehen, für alle unterstützten Sicherheitsmodi.

Konzepte des Nachrichtensicherheitsmodus

WS-Sicherheit-Modell

Die Grundlage des Nachrichtensicherheitsmodus ist die WS-Sicherheit-Spezifikation. In der WS-Sicherheit-Spezifikation wird ein Framework beschrieben, das Sicherheit für SOAP-Nachrichten gewährleistet. Sie gibt ein Nachrichtensicherheitsmodell an, das mit digitalen Signaturen und Verschlüsselung kombinierte Sicherheitstoken zum Schützen und Authentifizieren von SOAP-Nachrichten verwendet. Die Spezifikation finden Sie unter Webdienstsicherheit (WS-Sicherheit) (möglicherweise in englischer Sprache).

Terminologie

Ein Sicherheitstoken versichert Ansprüche und kann für die Bindung zwischen Authentifizierungsgeheimnissen oder -schlüsseln und Sicherheitsidentitäten verwendet werden.

Ein Anspruch ist eine Deklaration, die von einer Entität über eine Entität erfolgt (z. B. ein Name, eine Identität, eine Gruppe, ein Schlüssel oder eine Berechtigung). Die Entität, die den Anspruch ausführt, wird als Anspruchsaussteller bezeichnet. Die Entität, für die der Anspruch ausgeführt wird, wird als Anspruchssubjekt bezeichnet.

Ein Anspruchsaussteller kann sich für die Ansprüche in einem Sicherheitstoken verbürgen oder diese unterstützen. Dazu verwendet er einen Schlüssel, um das Sicherheitstoken zu signieren oder zu verschlüsseln. Dadurch wird die Authentifizierung der Ansprüche im Sicherheitstoken aktiviert.

Nachrichtensignaturen werden zum Prüfen des Nachrichtenursprungs und der Nachrichtenintegrität verwendet. Die Nachrichtensignaturen werden auch von Nachrichtenerstellern (normalerweise Drittanbieter) verwendet, um eine Vertrautheit mit dem Schlüssel zu demonstrieren, der zum Bestätigen der Ansprüche in einem Sicherheitstoken verwendet wird, und um ihre Identität (und alle anderen durch das Sicherheitstoken dargestellten Ansprüche) an die Nachrichten zu binden, die durch sie erstellt werden.

Sicherheitstoken

WS-Sicherheit definiert mehrere Typen von Sicherheitstoken und bietet ein erweiterbares Modell, mit dem weitere Sicherheitstokentypen unabhängig voneinander definiert werden können. Jede Tokentypdefinition enthält eine XML-Serialisierung des Tokens. Dadurch wird das direkte Hinzufügen der Tokendarstellung zur Nachricht ermöglicht.

Im Folgenden werden einige der in WS-Sicherheit definierten Sicherheitstokentypen dargestellt:

Benutzernamentoken.
X.509-Zertifikatstoken.
Kerberos-Token.
SAML-Token.

Die Verwendung von Token ist auf vier Arten möglich, und die an eine Nachricht angehängten Token fallen in genau eine dieser Kategorien:

SignedSupporting
SignedEndorsing
SignedEncrypted
EncryptedEndorsing

In .NET Framework 3.0 kann eine Clientnachricht pro Typ lediglich ein einzelnes Token enthalten. Es können jedoch mehrere Token unterschiedlichen Typs enthalten sein.

In .NET Framework 3.5 können Clientnachrichten mehrere Token eines Typs sowie Token unterschiedlichen Typs enthalten.

Durch diese Funktion werden unter anderem folgende Szenarien möglich:

Inkrementelles Senden von Ansprüchen. Es kann vorkommen, dass alle Vorgänge eines Diensts das Vorhandensein eines Satzes von Ansprüchen erfordern, für andere Vorgänge jedoch zusätzliche Ansprüche erforderlich sind. Statt eigens für jeden Vorgang ausgestellte Token zu verwenden, kann der Client ein für den anfänglichen Satz von Ansprüchen ausgestelltes Token beziehen und für den Vorgang, der aufgerufen wird, ein anderes, für die restlichen Ansprüche ausgestelltes Token verwenden.
Mehrfaktoren-Authentifizierung. Wenn der Client ausgestellte Token von mehreren Ausstellern und/oder ausgestellte Token mit verschiedenen Sätzen von Ansprüchen erfassen muss, bevor er einen Vorgang ausführen kann. Da WCF das ausgestellte Token als Tokentyp betrachtet, ist es für dieses Szenario erforderlich, dass eine Nachricht zwei unterstützende ausgestellte Token enthalten kann.

Ein Dienst kann nicht auf diese Weise konfiguriert werden, da ein Dienst lediglich ein einzelnes unterstützendes Token enthalten kann.

Weitere Informationen finden Sie unter Vorgehensweise: Verwenden mehrerer Sicherheitstokens desselben Typs.

WS-Sicherheit-Implementierung

Da WS-Sicherheit eine Grundlage für die Nachrichtensicherheit bietet, stellt die WCF-Implementierung von WS-Sicherheit einen Grundpfeiler des gesamten Nachrichtensicherheitsmodus dar. Wenn Sie die Funktionen des Nachrichtensicherheitsmodus erweitern möchten, sollten Sie wissen, wie die WS-Sicherheit-Implementierung funktioniert.

Die WS-Sicherheit-Implementierung in WCF bietet Folgendes:

Serialisierung von Sicherheitstoken in und aus SOAP-Nachrichten.
Authentifizierung von Sicherheitstoken.
Anwendung und Prüfung von Nachrichtensignaturen.
Verschlüsselung und Entschlüsselung von SOAP-Nachrichten.

WCF-Erweiterungspunkte ermöglichen die Anpassung der ersten beiden Elemente. Es ist möglich, die Serialisierung bereits vorhandener Sicherheitstoken sowie die Art und Weise zu ändern, wie die WCF-Sicherheit diese Token authentifiziert. Es ist ebenfalls möglich, völlig neue Sicherheitstokentypen in die WCF-Sicherheit zu integrieren, einschließlich Serialisierungs- und Authentifizierungsfunktionen.

In den folgenden Themen in diesem Abschnitt wird gezeigt, wie die Erweiterungspunkte der WS-Sicherheit-Implementierung für die Anpassung der Sicherheitstokenfunktionen verwendet werden können.

Autorisierung

Die Sicherheitstoken werden aus den eingehenden Nachrichten serialisiert und authentifiziert. Der Authentifizierungsprozess resultiert in einer Reihe von Objekten der Autorisierungsrichtlinie. Jedes Objekt stellt einen Teil der Sicherheitstokendaten dar. Die Daten werden während der Autorisierungsphase verwendet.

Die Autorisierungsrichtlinie erstellt eine Reihe von Ansprüchen, die von einem bestimmten Sicherheitstoken dargestellt werden. Dieser Satz von Ansprüchen wird dann dem ServiceAuthorizationManager und der Logik innerhalb der AuthorizationContext-Eigenschaft für die Autorisierungsentscheidungen zur Verfügung gestellt.

Identität

Zusätzlich zu den Ansprüchen erstellt WCF eine Implementierung der IIdentity-Schnittstelle , um den Aufrufer der vorhandenen Infrastruktur (erstellt mit dem .NET Framework-Sicherheitsmodell) darzustellen. Diese IIdentity-Instanz stellt entweder die Windows-Identität des Aufrufers dar, falls das Sicherheitstoken einem Windows-Konto zugeordnet ist, oder eine primäre Identität, die den Namen des Aufrufers enthält. Diese Identitäten können auch mit ServiceSecurityContext verwendet werden. (Weitere Informationen finden Sie unter Vorgehensweise: Prüfen des Sicherheitskontexts.) Es ist möglich, die Art und Weise anzupassen, wie in WCF Identitäten erstellt werden. Verwenden Sie dazu eine der folgenden Methoden:

Implementierung einer benutzerdefinierten Erweiterung der SecurityTokenAuthenticator-Klasse.
Integration mit ASP.NET durch Erweiterung der MembershipProvider-Klasse oder durch Erstellen einer benutzerdefinierten IAuthorizationPolicy-Implementierung und Integration in den ServiceAuthorizationManager.
Erstellen einer benutzerdefinierten IAuthorizationPolicy.

Der benutzerdefinierte Mitgliedschaftsanbieter funktioniert nur, wenn für die Authentifizierung des Aufrufers die Benutzernamen-/Kennwortauthentifizierung verwendet wird. MembershipProvider überprüft das Benutzername-Kennwort-Paar. Falls das Paar gültig ist, erstellt WCF eine primäre Identität, mit der der authentifizierte Aufrufer nach der MembershipProvider-Validierung dargestellt wird.

Um die Integration mit der bereits vorhandenen .NET Framework-Sicherheitsinfrastruktur zu vereinfachen, legt WCF standardmäßig die CurrentPrincipal-Eigenschaft auf eine IPrincipal-Instanz fest, die den Aufrufer darstellt. Die IPrincipal-Instanz wird basierend auf den Informationen erstellt, die in der generierten IIdentity enthalten sind.

Die IIdentity kann weiter erhöht werden durch die Integration mit dem ASP.NET-RoleProvider. Der RoleProvider fügt Sätze von Rollen hinzu, denen der Aufrufer angehört. Die Autorisierungslogik nutzt diese Informationen für die Zugriffsentscheidung.

Weitere Informationen über zur Identität finden Sie unter Dienstidentität und Authentifizierung.

Senden von gesicherten Nachrichten

In der folgenden Abbildung wird gezeigt, wie eine Nachricht mit dem Nachrichtensicherheitsmodus des Clients gesichert wird. In der Abbildung werden die beteiligten Komponenten sowie die Beziehungen zwischen den Komponenten dargestellt:

Der Anwendungscode wird ausgeführt und generiert eine Nachricht.
In der Phase der Tokenbereitstellung sind die Clientanmeldeinformationen (z. B. X.509-Zertifikate) angehängt. In einem verbundenen Szenario wird ein Tokenaussteller kontaktiert, um die Anmeldeinformationen zu liefern.
Die Anmeldeinformationen werden zum Erstellen des Sicherheitstokens verwendet.
In der Phase Tokenauthentifizierung werden die Token geprüft.
Schließlich werden die Sicherheitstoken serialisiert und gesendet.

Senden einer gesicherten Nachricht

Empfangen von gesicherten Nachrichten

In der folgenden Abbildung werden die Prozesse dargestellt, die stattfinden, wenn eine sichere Nachricht aus der Verbindung extrahiert und auf der Empfangsseite geprüft wird.

Die Sicherheitstoken werden in der Tokenauthentifizierungsphase deserialisiert und verarbeitet. Falls erwünscht, kann ein ASP.NET-Mitgliedschaftsanbieter zum Angeben von Benutzername und Kennwort an diesem Punkt verwendet werden.
Nach der Authentifizierung werden die Autorisierungsrichtlinien extrahiert.
In der Phase Evaluierung der Autorisierungsrichtlinien werden die Autorisierungsrichtlinien evaluiert und können einem Evaluierungskontext hinzugefügt werden. An diesem Punkt werden auch externe Autorisierungsrichtlinien verwendet. Dieser und der nachfolgende Schritt werden von den Methoden eines ServiceAuthorizationManager ausgeführt.
In der Phase Dienstautorisierung werden die richtigen Autorisierungen basierend auf den Ansprüchen angegeben, die von den Autorisierungsrichtlinien hinzugefügt wurden. Dieser Schritt wird von Methoden eines ServiceAuthorizationManager ausgeführt.
Nach der Autorisierung findet ein Aufruferidentitätswechsel statt, falls der Aufrufer dies zugelassen hat und es von der Dienstmethode verlangt wird oder die ImpersonateCallerForAllOperations-Eigenschaft auf das Dienstautorisierungsverhalten festgelegt ist. Weitere Informationen finden Sie unter Delegierung und Identitätswechsel mit WCF.
WCF generiert an diesem Punkt anhand der Anmeldeinformationen eine PrincipalPermission. An diesem Punkt kann ggf. ein ASP.NET-Rollenanbieter verwendet werden.
Der Anwendungscode wird ausgeführt.

Empfangen einer gesicherten Nachricht

Übersicht über Sicherheitserweiterungspunkte

In der folgenden Abbildung werden die von den WCF-Sicherheitskomponenten bereitgestellten Erweiterungspunkte dargestellt. Die Abbildung ist in vier verschiedene Kategorien unterteilt, die sich danach richten, wann der Erweiterungspunkt während der Nachrichtenverarbeitung erreicht wird. Diese Kategorien werden den Verarbeitungsphasen der Nachrichtensicherheit zugeordnet, wie in den vorhergehenden beiden Abschnitten beschrieben. In der Abbildung wird ebenfalls dargestellt, dass die vorhandenen Infrastrukturtechnologien mit der WCF-Sicherheit integriert werden können.

WCF-Sicherheitserweiterungspunkte

Siehe auch