Grundlagen der Schutzebene

  • Artikel

Die ProtectionLevel-Eigenschaft ist in vielen anderen Klassen zu finden, z. B. die ServiceContractAttribute-Klasse und die OperationContractAttribute-Klasse. Die Eigenschaft steuert, wie eine Nachricht zum Teil (oder ganz) geschützt wird. Dieses Thema erklärt die Funktion der Windows Communication Foundation (WCF) und ihre Funktionsweise.

Anweisungen zum Festlegen der Schutzebene finden Sie unter Vorgehensweise: Festlegen der ProtectionLevel-Eigenschaft.

Hinweis

Schutzebenen können nur im Code, nicht in der Konfiguration festgelegt werden.

Grundeinstellungen

Um die Schutzebenenfunktion zu verstehen, sind die folgenden grundlegenden Anweisungen wichtig:

  • Drei grundlegende Ebenen des Schutzes sind für jeden Teil einer Nachricht vorhanden. Die Eigenschaft wird (bei jedem Auftreten) auf einen der ProtectionLevel-Enumerationswerte festgelegt. In aufsteigender Reihenfolge des Schutzes umfassen sie:

    • None.

    • Sign. Der geschützte Teil wird digital signiert. Dies stellt sicher, dass eine Manipulation am Nachrichtenteil erkannt wird.

    • EncryptAndSign. Der Nachrichtenteil wird verschlüsselt, um Vertraulichkeit sicherzustellen, bevor er signiert wird.

  • Sie können Schutzanforderungen nur für Anwendungsdaten mit dieser Funktion festlegen. WS-Adressierungsheader sind z. B. Infrastrukturdaten und werden deshalb nicht vom ProtectionLevel beeinflusst.

  • Wenn der Sicherheitsmodus auf Transport festgelegt wird, wird die ganze Nachricht vom Transportmechanismus geschützt. Deshalb hat das Festlegen einer separaten Schutzebene für andere Teile einer Nachricht keine Auswirkungen.

  • Die ProtectionLevel stellt eine Möglichkeit für den Entwickler dar, die Mindestebene festzulegen, die eine Bindung aufweisen muss. Beim Bereitstellen eines Diensts kann die tatsächliche in der Konfiguration angegebene Bindung die Mindestebene unterstützen oder nicht. Standardmäßig stellt die BasicHttpBinding-Klasse keine Sicherheit bereit (diese kann allerdings aktiviert werden). Die Verwendung dieser Klasse in Verbindung mit einem Vertrag, der eine andere Einstellung als None hat, löst eine Ausnahme aus.

  • Wenn es der Dienst erfordert, dass die kleinste ProtectionLevel für alle Nachrichten Sign ist, kann ein Client (der möglicherweise von einer Nicht--Technologie erstellt wurde) alle Nachrichten verschlüsseln und signieren (was über die erforderliche Mindestebene hinausgeht). In diesem Fall löst WCF keine Ausnahme aus, da der Client über die Mindestebene hinausgeht. Beachten Sie jedoch, dass WCF-Anwendungen (Dienste oder Clients) einen Nachrichtenteil nicht übermäßig schützen, sofern möglich, sondern die Mindestebene einhalten. Außerdem ist zu beachten, dass der Transport den Nachrichtenstrom bei Verwendung von Transport als Sicherheitsmodus übermäßig schützt, da in diesem Fall ein Schutz auf niedrigerer Ebene nicht möglich ist.

  • Wenn Sie ProtectionLevel ausdrücklich entweder auf Sign oder EncryptAndSign festlegen, müssen Sie eine Bindung mit aktivierter Sicherheit verwenden. Andernfalls wird eine Ausnahme ausgelöst.

  • Wählen Sie eine Bindung aus, die Sicherheit aktiviert, und legen Sie im Vertrag keine ProtectionLevel-Eigenschaft fest, werden alle Daten verschlüsselt und signiert.

  • Wählen Sie eine Bindung aus, für die keine Sicherheit aktiviert wurde (für die BasicHttpBinding-Klasse ist die Sicherheit beispielsweise standardmäßig deaktiviert) und für die ProtectionLevel nicht ausdrücklich festgelegt ist, werden keine Anwendungsdaten geschützt.

  • Bei Verwendung einer Bindung, die Sicherheit auf der Transportebene anwendet, werden alle Anwendungsdaten den Transportfunktionen entsprechend geschützt.

  • Wenn Sie eine Bindung verwenden, die die Sicherheit auf der Nachrichtenebene anwendet, werden alle Anwendungsdaten den im Vertrag festgelegten Schutzebenen entsprechend geschützt. Wenn Sie keine Schutzebene festlegen, werden alle Anwendungsdaten in den Nachrichten verschlüsselt und signiert.

  • ProtectionLevel kann auf anderen bewertenden Ebenen festgelegt werden. Dem Bewerten ist eine Hierarchie zugeordnet. Diese wird im nächsten Abschnitt erklärt.

Bereichsdefinition

Durch Festlegen von ProtectionLevel auf der obersten API wird die Ebene für alle untergeordneten Ebenen festgelegt. Wenn ProtectionLevel auf einer untergeordneten Ebene auf einen anderen Wert festgelegt ist, werden alle APIs unterhalb dieser Ebene in der Hierarchie auf die neue Ebene geändert (APIs oberhalb dieser Ebene richten sich nach wie vor nach der obersten Ebene). Die Hierarchie lautet wie folgt. Attribute auf der gleichen Ebene sind Peers.

Programmieren von ProtectionLevel

Zum Programmieren von ProtectionLevel an einem beliebigen Punkt der Hierarchie legen Sie die Eigenschaft beim Anwenden des Attributs einfach auf einen entsprechenden Wert fest. Beispiele finden Sie unter Vorgehensweise: Festlegen der ProtectionLevel-Eigenschaft.

Hinweis

Um die Eigenschaft für Fehler- und Nachrichtenverträge festlegen zu können, müssen Sie die Funktionsweise dieser Funktionen verstehen. Weitere Informationen finden Sie unter Vorgehensweise: Festlegen der ProtectionLevel-Eigenschaft und Verwenden von Nachrichtenverträgen.

WS-Adressierungsabhängigkeit

In den meisten Fällen wird durch die Verwendung des ServiceModel Metadata Utility Tool (Svcutil.exe) zur Erstellung eines Clients sichergestellt, dass der Client und die Serviceverträge identisch sind. Scheinbar identische Verträge können jedoch den Client veranlassen, eine Ausnahme auszulösen. Dies ist der Fall, wenn eine Bindung die WS-Adressierungsspezifikation nicht unterstützt und mehrere Schutzebenen für den Vertrag festgelegt sind. Beispielsweise unterstützt die BasicHttpBinding-Klasse die Spezifikation nicht oder wenn Sie eine benutzerdefinierte Bindung erstellen, die die WS-Adressierung nicht unterstützt. Die ProtectionLevel-Funktion ist von der WS-Adressierungsspezifikation abhängig, um andere Schutzebenen für einen einzelnen Vertrag zu aktivieren. Wenn die Bindung die WS-Adressierungsspezifikation nicht unterstützt, werden alle Ebenen auf dieselbe Schutzebene festgelegt. Die effektive Schutzebene für alle Bereiche des Vertrags wird auf die höchste Schutzebene festgelegt, die für den Vertrag verwendet wird.

Dies verursacht möglicherweise ein Problem, das auf den ersten Blick schwer zu debuggen ist. Es ist möglich, einen Dienstvertrag (eine Schnittstelle) zu erstellen, der Methoden für mehrere Dienste umfasst, d. h. dieselbe Schnittstelle wird zum Erstellen eines Clients verwendet, der mit vielen Diensten kommuniziert, und die einzelne Schnittstelle umfasst Methoden für alle Dienste. Der Entwickler muss in diesem seltenen Fall darauf achten, nur die Methoden aufzurufen, die für die einzelnen Dienste gelten. Wenn die Bindung die BasicHttpBinding-Klasse ist, können mehrere Schutzebenen nicht unterstützt werden. Ein auf den Client antwortender Dienst kann jedoch auf einen Client mit einer niedrigeren Schutzebene als erforderlich reagieren. In diesem Fall löst der Client eine Ausnahme aus, da er eine höhere Schutzebene erwartet.

Im folgenden Codebeispiel wird dieses Problem veranschaulicht. Das folgende Beispiel zeigt einen Dienst- und einen Clientvertrag. Angenommen, die Bindung ist das <basicHttpBinding-Element> . Deshalb haben alle Vorgänge im Rahmen eines Vertrags die gleiche Schutzebene. Diese einheitliche Schutzebene wird als maximale Schutzebene für alle Vorgänge bestimmt.

Der Dienstvertrag lautet:

[ServiceContract()]
public interface IPurchaseOrder
{
    [OperationContract(ProtectionLevel = ProtectionLevel.Sign)]
    int Price();
}

<ServiceContract()> _
Public Interface IPurchaseOrder
    <OperationContract(ProtectionLevel:=ProtectionLevel.Sign)> _
    Function Price() As Integer
End Interface

Im folgenden Codebeispiel wird die Clientvertragsschnittstelle dargestellt. Beachten Sie, dass eine Tax-Methode enthalten ist, die mit einem anderen Dienst verwendet werden sollte:

[ServiceContract()]
public interface IPurchaseOrder
{
    [OperationContract()]
    int Tax();

    [OperationContract(ProtectionLevel = ProtectionLevel.Sign)]
    int Price();
}

<ServiceContract()> _
Public Interface IPurchaseOrder
    <OperationContract()> _
    Function Tax() As Integer

    <OperationContract(ProtectionLevel:=ProtectionLevel.Sign)> _
    Function Price() As Integer
End Interface

Wenn der Client die Price-Methode aufruft, wird eine Ausnahme ausgelöst, sobald eine Antwort vom Dienst eingeht. Der Grund hierfür liegt darin, dass der Client keine ProtectionLevel im ServiceContractAttribute angibt und daher den Standardwert (EncryptAndSign) für alle Methoden, einschließlich der Price-Methode, verwendet. Der Dienst gibt jedoch den Wert unter Verwendung der Sign-Ebene zurück, da der Dienstvertrag eine einzelne Methode definiert, deren Schutzebene auf Sign festgelegt ist. In diesem Fall löst der Client einen Fehler aus, wenn er die Antwort vom Dienst überprüft.

Siehe auch