Dela via

Förstå skyddsnivå

  • Artikel

Egenskapen ProtectionLevel finns i många olika klasser, till exempel klasserna ServiceContractAttributeOperationContractAttribute och . Egenskapen styr hur en del (eller hela) av ett meddelande skyddas. I det här avsnittet beskrivs WCF-funktionen (Windows Communication Foundation) och hur den fungerar.

Anvisningar om hur du anger skyddsnivå finns i Så här anger du egenskapen ProtectionLevel.

Kommentar

Skyddsnivåer kan endast anges i kod, inte i konfigurationen.

Grundläggande

Följande grundläggande instruktioner gäller för att förstå skyddsnivåfunktionen:

  • Det finns tre grundläggande skyddsnivåer för alla delar av ett meddelande. Egenskapen (var den än inträffar) är inställd på ett av uppräkningsvärdena ProtectionLevel . I stigande skyddsordning omfattar de:

    • None.

    • Sign. Den skyddade delen är digitalt signerad. Detta säkerställer identifiering av eventuell manipulering av den skyddade meddelandedelen.

    • EncryptAndSign. Meddelandedelen krypteras för att säkerställa konfidentialitet innan den signeras.

  • Du kan endast ange skyddskrav för programdata med den här funktionen. Till exempel är WS-Adresseringshuvuden ProtectionLevelinfrastrukturdata och påverkas därför inte av .

  • När säkerhetsläget är inställt på Transportskyddas hela meddelandet av transportmekanismen. Därför har det ingen effekt att ange en separat skyddsnivå för olika delar av ett meddelande.

  • ProtectionLevel Är ett sätt för utvecklaren att ange den lägsta nivå som en bindning måste uppfylla. När en tjänst distribueras kan den faktiska bindningen som anges i konfigurationen ha stöd för miniminivån. Klassen tillhandahåller till exempel som standard BasicHttpBinding inte säkerhet (även om den kan aktiveras). Om du använder det med ett kontrakt som har någon annan inställning än None kommer därför ett undantag att genereras.

  • Om tjänsten kräver att minimivärdet ProtectionLevel för alla meddelanden är Signkan en klient (kanske skapad av en icke-WCF-teknik) kryptera och signera alla meddelanden (vilket är mer än det minsta som krävs). I det här fallet utlöser WCF inget undantag eftersom klienten har gjort mer än det minsta. Observera dock att WCF-program (tjänster eller klienter) inte överbeskyddar en meddelandedel om möjligt, men att de uppfyller miniminivån. Observera också att när du använder Transport som säkerhetsläge kan transporten överbeskydda meddelandeströmmen eftersom den inte kan skyddas på en mer detaljerad nivå.

  • Om du uttryckligen ProtectionLevel anger till antingen Sign eller EncryptAndSignmåste du använda en bindning med säkerhet aktiverad, annars utlöses ett undantag.

  • Om du väljer en bindning som möjliggör säkerhet och du inte anger ProtectionLevel egenskapen någonstans i kontraktet krypteras och signeras alla programdata.

  • Om du väljer en bindning som inte har säkerhetsaktiverad (till exempel BasicHttpBinding att klassen har säkerhet inaktiverad som standard) och inte uttryckligen ProtectionLevel har angetts kommer ingen av programdata att skyddas.

  • Om du använder en bindning som tillämpar säkerhet på transportnivå skyddas alla programdata enligt transportens funktioner.

  • Om du använder en bindning som tillämpar säkerhet på meddelandenivå skyddas programdata enligt de skyddsnivåer som anges i kontraktet. Om du inte anger någon skyddsnivå krypteras och signeras alla programdata i meddelandena.

  • ProtectionLevel Kan anges på olika omfångsnivåer. Det finns en hierarki som är associerad med omfång, vilket förklaras i nästa avsnitt.

Omfång

ProtectionLevel Om du anger det översta API:et anges nivån för alla nivåer under den. ProtectionLevel Om värdet är inställt på ett annat värde på en lägre nivå kommer alla API:er under den nivån i hierarkin nu att återställas till den nya nivån (API:er ovanför den påverkas dock fortfarande av den översta nivån). Hierarkin är följande. Attribut på samma nivå är peer-datorer.

ProgrammeringsskyddNivå

Om du vill programmera när som ProtectionLevel helst i hierarkin anger du helt enkelt egenskapen till ett lämpligt värde när du använder attributet. Exempel finns i Så här: Ange egenskapen ProtectionLevel.

Kommentar

Om du ställer in egenskapen på fel och meddelandekontrakt måste du förstå hur dessa funktioner fungerar. Mer information finns i Så här: Ange egenskapen ProtectionLevel och Använda meddelandekontrakt.

WS-adresseringsberoende

I de flesta fall säkerställer användning av ServiceModel Metadata Utility Tool (Svcutil.exe) för att generera en klient att klient- och tjänstkontrakten är identiska. Till synes identiska kontrakt kan dock orsaka att klienten utlöser ett undantag. Detta inträffar när en bindning inte stöder WS-Addressing-specifikationen och flera skyddsnivåer anges i kontraktet. Klassen stöder till exempel BasicHttpBinding inte specifikationen, eller om du skapar en anpassad bindning som inte stöder WS-Adressering. Funktionen ProtectionLevel förlitar sig på WS-Addressing-specifikationen för att aktivera olika skyddsnivåer på ett enda kontrakt. Om bindningen inte stöder specifikationen för WS-Adressering anges alla nivåer till samma skyddsnivå. Den effektiva skyddsnivån för alla omfång i kontraktet kommer att ställas in på den starkaste skyddsnivån som används i kontraktet.

Detta kan orsaka ett problem som är svårt att felsöka vid första anblicken. Det är möjligt att skapa ett klientkontrakt (ett gränssnitt) som innehåller metoder för mer än en tjänst. Det vill: samma gränssnitt används för att skapa en klient som kommunicerar med många tjänster, och det enda gränssnittet innehåller metoder för alla tjänster. Utvecklaren måste vara försiktig i det här sällsynta scenariot för att endast anropa de metoder som är tillämpliga för varje viss tjänst. Om bindningen är BasicHttpBinding klassen kan flera skyddsnivåer inte stödjas. En tjänst som svarar på klienten kan dock svara på en klient med en lägre skyddsnivå än vad som krävs. I det här fallet utlöser klienten ett undantag eftersom den förväntar sig en högre skyddsnivå.

Ett exempel på koden illustrerar det här problemet. I följande exempel visas en tjänst och ett klientkontrakt. Anta att bindningen är elementet <basicHttpBinding> . Därför har alla åtgärder i ett kontrakt samma skyddsnivå. Den här enhetliga skyddsnivån bestäms som den maximala skyddsnivån för alla åtgärder.

Tjänstkontraktet är:

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

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

Följande kod visar klientkontraktsgränssnittet. Observera att den innehåller en Tax metod som är avsedd att användas med en annan tjänst:

[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

När klienten anropar Price metoden utlöser den ett undantag när den tar emot ett svar från tjänsten. Detta beror på att klienten inte anger en ProtectionLevel på ServiceContractAttribute, och därför använder klienten standardvärdet (EncryptAndSign) för alla metoder, inklusive Price metoden. Tjänsten returnerar dock värdet med hjälp av Sign nivån eftersom tjänstkontraktet definierar en enda metod som har sin skyddsnivå inställd på Sign. I det här fallet utlöser klienten ett fel när svaret verifieras från tjänsten.

Se även