Megosztás:

A védelmi szint ismertetése

A ProtectionLevel tulajdonság számos különböző osztályban található, például a és az ServiceContractAttributeOperationContractAttribute osztályokban. A tulajdonság szabályozza az üzenet egy részének (vagy egészének) védelmét. Ez a témakör a Windows Communication Foundation (WCF) funkcióját és működését ismerteti.

A védelmi szint beállításával kapcsolatos utasításokért lásd: Útmutató: A Védelmi szint tulajdonság beállítása.

Megjegyzés:

A védelmi szintek csak kódban állíthatók be, konfigurációban nem.

Alapkifejezések

A védelmi szint funkciójának megértéséhez az alábbi alapvető utasítások érvényesek:

  • Az üzenetek bármely részén három alapvető védelmi szint létezik. A tulajdonság (bárhol is történik) az ProtectionLevel enumerálási értékek egyikére van állítva. Növekvő védelmi sorrendben a következők:

    • None.

    • Sign. A védett rész digitálisan alá van írva. Ez biztosítja a védett üzenetrész illetéktelen beavatkozásának észlelését.

    • EncryptAndSign. Az üzenetrész titkosítva van, hogy az aláírás előtt biztosítsa a bizalmasságot.

  • Ezzel a funkcióval csak az alkalmazásadatokra vonatkozó védelmi követelményeket állíthat be. Például a WS-Addressing fejlécek infrastruktúra adatok, ezért nem érinti őket a ProtectionLevel.

  • Ha a biztonsági mód be van állítva Transport, a teljes üzenetet az átviteli mechanizmus védi. Ezért az üzenet különböző részeihez külön védelmi szint beállítása nincs hatással.

  • A ProtectionLevel fejlesztő így állíthatja be azt a minimális szintet , amelynek a kötésnek meg kell felelnie. Egy szolgáltatás üzembe helyezésekor a konfigurációban megadott tényleges kötés esetleg nem támogatja a minimális szintet. Az osztály például alapértelmezés szerint BasicHttpBinding nem biztosít biztonságot (bár engedélyezhető). Ezért ha olyan szerződéssel használja, amely bármely más beállítással None rendelkezik, kivételt fog dobni.

  • Ha a szolgáltatás megköveteli, hogy az összes üzenet minimális értéke ProtectionLevel legyen Sign, az ügyfél (esetleg egy nem WCF-technológiával létrehozott) képes az összes üzenet titkosítására és aláírására (ami több, mint a minimálisan szükséges). Ebben az esetben a WCF nem fog kivételt kivenni, mert az ügyfél a minimálisnál többet tett. Vegye figyelembe azonban, hogy a WCF-alkalmazások (szolgáltatások vagy ügyfelek) nem fogják túl biztonságossá tenni az üzenetrészeket, ha lehetséges, de megfelelnek a minimális szintnek. Azt is vegye figyelembe, hogy biztonsági módként való használat Transport esetén az átvitel túl biztonságossá teheti az üzenetstreamet, mivel az eredendően nem képes részletesebb szinten biztonságossá tenni.

  • Ha explicit módon beállítja a ProtectionLevel értékét Sign vagy EncryptAndSign értékére, akkor engedélyezett biztonsággal rendelkező kötést kell használnia, különben kivétel keletkezik.

  • Ha olyan kötést választ, amely lehetővé teszi a biztonságot, és nem állítja be a ProtectionLevel tulajdonságot bárhol a szerződésben, minden alkalmazásadat titkosítva és aláírva lesz.

  • Ha olyan kötést választ ki, amelynek nincs engedélyezve a biztonsága (például az osztály alapértelmezés szerint letiltotta a BasicHttpBinding biztonságot), és a ProtectionLevel kötés nincs explicit módon beállítva, akkor az alkalmazás adatai nem lesznek védettek.

  • Ha olyan kötést használ, amely az átvitel szintjén alkalmazza a biztonságot, akkor minden alkalmazási adat biztonságos lesz az átvitel képességeinek megfelelően.

  • Ha olyan kötést használ, amely az üzenet szintjén alkalmazza a biztonságot, akkor az alkalmazásadatok a szerződésben meghatározott védelmi szinteknek megfelelően lesznek biztosítva. Ha nem ad meg védelmi szintet, akkor az üzenetekben szereplő összes alkalmazásadat titkosítva és aláírva lesz.

  • A ProtectionLevel beállítás különböző hatóköri szinteken állítható be. A hatókörkezeléshez tartozik egy hierarchia, amelyet a következő szakaszban ismertetünk.

Hatókörkezelés

ProtectionLevel A legfelső API beállítása beállítja az alatta lévő összes szint szintjét. Ha a ProtectionLevel beállítás egy másik értékre van beállítva egy alacsonyabb szinten, a hierarchia ezen szintje alatti összes API-t visszaállítjuk az új szintre (a felette lévő API-kat azonban továbbra is a legfelső szint fogja érinteni). A hierarchia a következő. Az azonos szintű attribútumok egyenrangúak.

Programozási Védettségi Szint

A ProtectionLevel hierarchia bármely pontjának programozásához egyszerűen állítsa be a tulajdonságot egy megfelelő értékre az attribútum alkalmazásakor. Példák: Útmutató: A Védelmi szint tulajdonság beállítása.

Megjegyzés:

A tulajdonság hibákra és üzenetszerződésekre való beállításához ismerni kell a funkciók működését. További információért lásd: Hogyan: Állítsa be a Védelmi szint Tulajdonságot és az Üzenetszerződések használata.

WS-Addressing függőség

A legtöbb esetben a ServiceModel Metadata Utility Tool (Svcutil.exe) használatával hozzon létre egy ügyfelet, hogy az ügyfél- és szolgáltatásszerződések azonosak legyenek. A látszólag azonos szerződések azonban kivételt okozhatnak az ügyfél számára. Ez akkor fordul elő, ha egy kötés nem támogatja a WS-Addressing specifikációt, és a szerződés több védelmi szintet határoz meg. Például a BasicHttpBinding osztály nem támogatja a specifikációt, vagy ha olyan egyéni kötést hoz létre, amely nem támogatja a WS-Addressinget. A ProtectionLevel funkció a WS-Addressing specifikációra támaszkodik, hogy egyetlen szerződés különböző védelmi szintjeit engedélyezze. Ha a kötés nem támogatja a WS-Addressing specifikációt, minden szint ugyanarra a védelmi szintre lesz beállítva. A szerződés összes hatókörének hatályos védelmi szintje a szerződésben használt legerősebb védelmi szintre lesz beállítva.

Ez olyan problémát okozhat, amelyet első pillantásra nehéz hibakeresésre használni. Létrehozhat egy ügyfélszerződést (egy interfészt), amely több szolgáltatáshoz is tartalmaz metódusokat. Ez azt jelzi, hogy ugyanazt a felületet használják egy olyan ügyfél létrehozásához, amely számos szolgáltatással kommunikál, és az egyetlen felület minden szolgáltatáshoz tartalmaz metódusokat. Ebben a ritka helyzetben a fejlesztőnek gondoskodnia kell arról, hogy csak az egyes szolgáltatásokra alkalmazható metódusokat hívja meg. Ha a kötés az BasicHttpBinding osztály, több védelmi szint nem támogatott. Az ügyfélnek válaszoló szolgáltatás azonban a szükségesnél alacsonyabb védelmi szintű ügyfélre is válaszolhat. Ebben az esetben az ügyfél kivételt fog kivenni, mert magasabb védelmi szintet vár.

A kód egy példája szemlélteti ezt a problémát. Az alábbi példa egy szolgáltatást és egy ügyfélszerződést mutat be. Tegyük fel, hogy a kötés az <alapvetőHttpBinding> elem. Ezért a szerződés összes művelete ugyanolyan védelmi szinttel rendelkezik. Ez az egységes védelmi szint az összes művelet maximális védelmi szintjeként van meghatározva.

A szolgáltatási szerződés a következő:

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

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

Az alábbi kód az ügyfélszerződés felületét mutatja. Vegye figyelembe, hogy egy másik szolgáltatással való használatra szánt metódust tartalmaz Tax :

[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

Amikor az ügyfél meghívja a Price metódust, kivételt jelez, amikor választ kap a szolgáltatástól. Ez azért fordul elő, mert az ügyfél nem ad meg egy ProtectionLevel beállítást a ServiceContractAttributekiszolgálón, ezért az ügyfél az alapértelmezett (EncryptAndSign) értéket használja az összes metódushoz, beleértve a metódust Price is. A szolgáltatás azonban a Sign szint használatával adja vissza az értéket, mivel a szolgáltatási szerződés egyetlen metódust határoz meg, amelynek védelmi szintje Sign-re van állítva. Ebben az esetben az ügyfél hibát jelez a szolgáltatás válaszának ellenőrzésekor.

Lásd még

  • Last updated on