Delen via

Informatie over beveiligingsniveau

  • Artikel

De ProtectionLevel eigenschap is te vinden op veel verschillende klassen, zoals de ServiceContractAttribute en de OperationContractAttribute klassen. De eigenschap bepaalt hoe een deel (of geheel) van een bericht wordt beveiligd. In dit onderwerp wordt de WCF-functie (Windows Communication Foundation) uitgelegd en hoe deze werkt.

Zie Instructies voor het instellen van het beveiligingsniveau : De eigenschap ProtectionLevel instellen.

Notitie

Beveiligingsniveaus kunnen alleen worden ingesteld in code, niet in configuratie.

Basisprincipes

De volgende basisinstructies zijn van toepassing om inzicht te hebben in de beveiligingsniveaufunctie:

  • Er bestaan drie basisbeveiligingsniveaus voor elk deel van een bericht. De eigenschap (waar deze zich ook voordoet) wordt ingesteld op een van de ProtectionLevel opsommingswaarden. In oplopende volgorde van beveiliging zijn onder andere:

    • None.

    • Sign. Het beveiligde onderdeel is digitaal ondertekend. Dit zorgt voor detectie van manipulatie met het beveiligde berichtonderdeel.

    • EncryptAndSign. Het berichtonderdeel wordt versleuteld om vertrouwelijkheid te garanderen voordat het wordt ondertekend.

  • U kunt met deze functie alleen beveiligingsvereisten instellen voor toepassingsgegevens . WS-Addressing-headers zijn bijvoorbeeld infrastructuurgegevens en worden daarom niet beïnvloed door de ProtectionLevel.

  • Wanneer de beveiligingsmodus is ingesteld Transportop, wordt het hele bericht beveiligd door het transportmechanisme. Daarom heeft het instellen van een afzonderlijk beveiligingsniveau voor verschillende onderdelen van een bericht geen effect.

  • De ProtectionLevel ontwikkelaar kan het minimumniveau instellen waaraan een binding moet voldoen. Wanneer een service wordt geïmplementeerd, kan de werkelijke binding die is opgegeven in de configuratie, het minimumniveau wel of niet ondersteunen. Standaard levert de BasicHttpBinding klasse bijvoorbeeld geen beveiliging (hoewel deze wel kan worden ingeschakeld). Als u het gebruikt met een contract met een andere instelling dan None wordt er daarom een uitzondering gegenereerd.

  • Als de service vereist dat het minimum ProtectionLevel voor alle berichten is Sign, kan een client (mogelijk gemaakt door een niet-WCF-technologie) alle berichten versleutelen en ondertekenen (wat meer is dan het vereiste minimum). In dit geval genereert WCF geen uitzondering omdat de client meer dan het minimum heeft gedaan. Houd er echter rekening mee dat WCF-toepassingen (services of clients) een berichtonderdeel indien mogelijk niet te beveiligen, maar wel voldoen aan het minimumniveau. Houd er ook rekening mee dat wanneer het transport als beveiligingsmodus wordt gebruikt Transport , de berichtstroom overbeveiligt, omdat het inherent niet kan worden beveiligd op een gedetailleerder niveau.

  • Als u de ProtectionLevel binding expliciet instelt op of SignEncryptAndSign, moet u een binding gebruiken waarvoor beveiliging is ingeschakeld of er wordt een uitzondering gegenereerd.

  • Als u een binding selecteert die beveiliging mogelijk maakt en u de ProtectionLevel eigenschap nergens op het contract instelt, worden alle toepassingsgegevens versleuteld en ondertekend.

  • Als u een binding selecteert waarvoor geen beveiliging is ingeschakeld (de klasse heeft bijvoorbeeld BasicHttpBinding standaard beveiliging uitgeschakeld) en de ProtectionLevel binding niet expliciet is ingesteld, worden geen van de toepassingsgegevens beveiligd.

  • Als u een binding gebruikt die beveiliging toepast op transportniveau, worden alle toepassingsgegevens beveiligd op basis van de mogelijkheden van het transport.

  • Als u een binding gebruikt die beveiliging toepast op berichtniveau, worden toepassingsgegevens beveiligd volgens de beveiligingsniveaus die zijn ingesteld op het contract. Als u geen beveiligingsniveau opgeeft, worden alle toepassingsgegevens in de berichten versleuteld en ondertekend.

  • De ProtectionLevel kan worden ingesteld op verschillende bereikniveaus. Er is een hiërarchie gekoppeld aan bereik, wat wordt uitgelegd in de volgende sectie.

Bereik bepalen

Als u de ProtectionLevel bovenste API instelt, wordt het niveau voor alle niveaus eronder ingesteld. Als de ProtectionLevel waarde is ingesteld op een andere waarde op een lager niveau, worden alle API's onder dat niveau in de hiërarchie nu opnieuw ingesteld op het nieuwe niveau (API's erboven worden echter nog steeds beïnvloed door het hoogste niveau). De hiërarchie is als volgt. Kenmerken op hetzelfde niveau zijn peers.

Programming ProtectionLevel

Als u het ProtectionLevel op een willekeurig punt in de hiërarchie wilt programmeren, stelt u de eigenschap in op een geschikte waarde bij het toepassen van het kenmerk. Zie Instructies voor voorbeelden : De eigenschap ProtectionLevel instellen.

Notitie

Als u de eigenschap instelt voor fouten en berichtcontracten, moet u begrijpen hoe deze functies werken. Zie Instructies voor meer informatie: De eigenschap ProtectionLevel instellen en Berichtcontracten gebruiken.

WS-adresseringsafhankelijkheid

In de meeste gevallen zorgt het gebruik van het hulpprogramma ServiceModel Metadata Utility (Svcutil.exe) ervoor dat de client- en servicecontracten identiek zijn. Schijnbaar identieke contracten kunnen echter ertoe leiden dat de client een uitzondering genereert. Dit gebeurt wanneer een binding de WS-Adresseringsspecificatie niet ondersteunt en er meerdere beveiligingsniveaus zijn opgegeven in het contract. De BasicHttpBinding klasse biedt bijvoorbeeld geen ondersteuning voor de specificatie of als u een aangepaste binding maakt die WS-Addressing niet ondersteunt. De ProtectionLevel functie is afhankelijk van de WS-Adresseringsspecificatie om verschillende beveiligingsniveaus voor één contract in te schakelen. Als de binding de WS-Adresseringsspecificatie niet ondersteunt, worden alle niveaus ingesteld op hetzelfde beveiligingsniveau. Het effectieve beveiligingsniveau voor alle bereiken op het contract wordt ingesteld op het sterkste beveiligingsniveau dat op het contract wordt gebruikt.

Dit kan een probleem veroorzaken dat moeilijk op het eerste gezicht kan worden opgespoord. Het is mogelijk om een clientcontract (een interface) te maken dat methoden voor meer dan één service bevat. Dat wil gezegd, dezelfde interface wordt gebruikt om een client te maken die communiceert met veel services, en de enkele interface bevat methoden voor alle services. De ontwikkelaar moet in dit zeldzame scenario alleen de methoden aanroepen die van toepassing zijn voor elke specifieke service. Als de binding de BasicHttpBinding klasse is, kunnen meerdere beveiligingsniveaus niet worden ondersteund. Een service die de client beantwoordt, kan echter reageren op een client met een lager beveiligingsniveau dan vereist is. In dit geval genereert de client een uitzondering omdat er een hoger beveiligingsniveau wordt verwacht.

Een voorbeeld van de code illustreert dit probleem. In het volgende voorbeeld ziet u een service en een clientcontract. Stel dat de binding het <basicHttpBinding-element> is. Daarom hebben alle bewerkingen op een contract hetzelfde beveiligingsniveau. Dit uniforme beveiligingsniveau wordt bepaald als het maximale beveiligingsniveau voor alle bewerkingen.

Het servicecontract is:

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

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

De volgende code toont de interface van het clientcontract. Houd er rekening mee dat het een Tax methode bevat die is bedoeld voor gebruik met een andere service:

[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

Wanneer de client de Price methode aanroept, genereert deze een uitzondering wanneer er een antwoord van de service wordt ontvangen. Dit gebeurt omdat de client geen op ProtectionLevel de ServiceContractAttributeclient opgeeft en daarom de standaardwaarde (EncryptAndSign) gebruikt voor alle methoden, inclusief de Price methode. De service retourneert echter de waarde met behulp van het Sign niveau omdat het servicecontract één methode definieert waarop het beveiligingsniveau is ingesteld Sign. In dit geval genereert de client een fout bij het valideren van het antwoord van de service.

Zie ook