Teilen über

Grundlegendes zur Schutzebene

Die ProtectionLevel Eigenschaft befindet sich in vielen verschiedenen Klassen, z. B. den ServiceContractAttribute Klassen und den OperationContractAttribute Klassen. Die Eigenschaft steuert, wie eine Nachricht zum Teil (oder ganz) geschützt wird. In diesem Thema wird das Windows Communication Foundation (WCF)-Feature und dessen Funktionsweise erläutert.

Anweisungen zum Festlegen der Schutzebene finden Sie unter How to: Set the ProtectionLevel Property.

Hinweis

Schutzstufen können nur im Code und nicht in der Konfiguration festgelegt werden.

Grundlagen

Um die Schutzniveaufunktion zu verstehen, gelten die folgenden grundlegenden Aussagen:

  • Für jeden Teil einer Nachricht gibt es drei grundlegende Schutzebenen. Die Eigenschaft (wo immer sie auftritt) wird auf einen der ProtectionLevel Enumerationswerte festgelegt. In aufsteigender Reihenfolge des Schutzes umfassen sie:

    • None.

    • Sign. Der geschützte Teil ist digital signiert. Dadurch wird sichergestellt, dass alle Manipulationen mit dem geschützten Nachrichtenteil erkannt werden.

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

  • Sie können Schutzanforderungen nur für Anwendungsdaten mit diesem Feature festlegen. Beispielsweise sind WS-Addressing-Header Infrastrukturdaten und daher nicht von ProtectionLevel betroffen.

  • Wenn der Sicherheitsmodus auf Transport festgelegt ist, wird die gesamte Nachricht durch den Transportmechanismus geschützt. Daher hat das Festlegen einer separaten Schutzebene für verschiedene Teile einer Nachricht keine Auswirkung.

  • Dies ProtectionLevel ist eine Möglichkeit für den Entwickler, die Mindeststufe festzulegen, die von einer Bindung eingehalten werden muss. Wenn ein Dienst bereitgestellt wird, kann die in der Konfiguration angegebene tatsächliche Bindung die Mindeststufe unterstützen oder nicht. Standardmäßig stellt die Klasse BasicHttpBinding beispielsweise keine Sicherheit zur Verfügung (obwohl sie aktiviert werden kann). Die Verwendung dieser Klasse in Verbindung mit einem Vertrag, der eine andere Einstellung als None hat, löst eine Ausnahme aus.

  • Wenn der Dienst erfordert, dass das Minimum ProtectionLevel für alle Nachrichten ist Sign, kann ein Client (möglicherweise von einer Nicht-WCF-Technologie erstellt) alle Nachrichten verschlüsseln und signieren (was mehr als das erforderliche Minimum ist). In diesem Fall löst WCF keine Ausnahme aus, da der Client mehr als das Minimum ausgeführt hat. Beachten Sie jedoch, dass WCF-Anwendungen (Dienste oder Clients) einen Nachrichtenteil nach Möglichkeit nicht übersichern, sondern die Mindeststufe einhalten. Beachten Sie außerdem, dass der Transport bei Verwendung von Transport als Sicherheitsmodus den Nachrichtendatenstrom möglicherweise übermäßig sichert, da er inhärent nicht auf einer granulareren Ebene gesichert werden kann.

  • Wenn Sie den ProtectionLevel explizit auf entweder Sign oder EncryptAndSign setzen, müssen Sie eine Bindung mit aktivierter Sicherheit verwenden, oder es wird eine Ausnahme ausgelöst.

  • Wenn Sie eine Bindung auswählen, die Sicherheit ermöglicht und Sie die ProtectionLevel Eigenschaft nicht an einer beliebigen Stelle im Vertrag festlegen, werden alle Anwendungsdaten verschlüsselt und signiert.

  • Wenn Sie eine Bindung auswählen, die keine Sicherheit aktiviert hat (z. B. die BasicHttpBinding Klasse hat standardmäßig die Sicherheit deaktiviert), und die ProtectionLevel nicht explizit festgelegt ist, werden keine Anwendungsdaten geschützt.

  • Wenn Sie eine Bindung verwenden, die Sicherheit auf Transportebene anwendet, werden alle Anwendungsdaten entsprechend den Funktionen des Transports gesichert.

  • Wenn Sie eine Bindung verwenden, die Sicherheit auf Nachrichtenebene anwendet, werden Anwendungsdaten entsprechend den auf dem Vertrag festgelegten Schutzebenen gesichert. Wenn Sie keine Schutzebene angeben, werden alle Anwendungsdaten in den Nachrichten verschlüsselt und signiert.

  • ProtectionLevel kann auf anderen bewertenden Ebenen festgelegt werden. Es gibt eine Hierarchie, die der Bereichsdefinition zugeordnet ist, die im nächsten Abschnitt erläutert wird.

Bereichsdefinition

Durch Festlegen von ProtectionLevel auf der obersten API wird die Ebene für alle untergeordneten Ebenen festgelegt. Wenn die ProtectionLevel Einstellung auf einen anderen Wert auf einer niedrigeren Ebene festgelegt ist, werden alle APIs unter dieser Ebene in der Hierarchie jetzt auf die neue Ebene zurückgesetzt (APIs darüber sind jedoch weiterhin von der obersten Ebene betroffen). Die Hierarchie lautet wie folgt. Attribute auf der gleichen Ebene sind Peers.

Programmieren von ProtectionLevel

Um die ProtectionLevel Eigenschaft an einem beliebigen Punkt in der Hierarchie zu programmieren, legen Sie die Eigenschaft einfach auf einen geeigneten Wert fest, wenn Sie das Attribut anwenden. Beispiele finden Sie unter So ändern Sie die ProtectionLevel-Eigenschaft.

Hinweis

Das Festlegen der Eigenschaft für Fehler- und Nachrichtenverträge setzt voraus, dass Sie verstehen, wie diese Funktionen funktionieren. Weitere Informationen finden Sie unter So wird’s gemacht: Eigenschaft ProtectionLevel festlegen und Verwendung von Message Contracts.

WS-Adressierungsabhängigkeit

In den meisten Fällen stellt die Verwendung des ServiceModel Metadata Utility Tools (Svcutil.exe) zum Generieren eines Clients sicher, dass der Client und die Serviceverträge identisch sind. Anscheinend identische Verträge können jedoch dazu führen, dass der Client eine Ausnahme auslöst. Dies geschieht, wenn eine Bindung die WS-Addressing Spezifikation nicht unterstützt und mehrere Schutzebenen im Vertrag angegeben werden. Beispielsweise unterstützt die Klasse die BasicHttpBinding Spezifikation nicht, oder wenn Sie eine benutzerdefinierte Bindung erstellen, die WS-Adressierung nicht unterstützt. Das ProtectionLevel Feature basiert auf der WS-Addressing Spezifikation, um unterschiedliche Schutzebenen für einen einzelnen Vertrag zu ermöglichen. Wenn die Bindung die WS-Addressing Spezifikation nicht unterstützt, werden alle Ebenen auf die gleiche Schutzebene festgelegt. Die effektive Schutzebene für alle Bereiche des Vertrags wird auf die stärkste Schutzstufe festgelegt, die für den Vertrag verwendet wird.

Dies kann zu einem Problem führen, das auf den ersten Blick schwer zu debuggen ist. Es ist möglich, einen Clientvertrag (eine Schnittstelle) zu erstellen, der Methoden für mehrere Dienste enthält. Das heißt, die gleiche Schnittstelle wird verwendet, um einen Client zu erstellen, der mit vielen Diensten kommuniziert, und die einzelne Schnittstelle enthält Methoden für alle Dienste. Der Entwickler muss in diesem seltenen Szenario darauf achten, nur die Methoden aufzurufen, die für jeden bestimmten Dienst gelten. Wenn es sich bei der Bindung um die BasicHttpBinding Klasse handelt, können nicht mehrere Schutzebenen unterstützt werden. Ein Dienst, der auf den Client antwortet, antwortet jedoch möglicherweise auf einen Client mit einer niedrigeren Schutzstufe als erforderlich. In diesem Fall löst der Client eine Ausnahme aus, da er eine höhere Schutzstufe erwartet.

Ein Beispiel für den Code veranschaulicht dieses Problem. Das folgende Beispiel zeigt einen Dienst und einen Clientvertrag. Angenommen, die Bindung ist das <basicHttpBinding-Element> . Daher haben alle Vorgänge in einem Vertrag das gleiche Schutzniveau. Diese einheitliche Schutzebene wird als maximale Schutzebene für alle Vorgänge bestimmt.

Der Servicevertrag 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

Der folgende Code zeigt die Clientvertragsschnittstelle. Beachten Sie, dass sie eine Tax Methode enthält, die mit einem anderen Dienst verwendet werden soll:

[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, löst er eine Ausnahme aus, wenn er eine Antwort vom Dienst empfängt. Dies tritt auf, weil der Client keinen ProtectionLevel auf dem ServiceContractAttribute angibt, und daher verwendet der Client die Standardeinstellung (EncryptAndSign) für alle Methoden, einschließlich der Price-Methode. Der Dienst gibt jedoch den Wert mithilfe der Sign Ebene zurück, da der Dienstvertrag eine einzelne Methode definiert, auf die die Schutzebene festgelegt ist Sign. In diesem Fall löst der Client beim Überprüfen der Antwort des Diensts einen Fehler aus.

Siehe auch

  • Last updated on