Partager via

Présentation du niveau de protection

La ProtectionLevel propriété se trouve sur de nombreuses classes différentes, telles que les ServiceContractAttribute classes et les OperationContractAttribute classes. La propriété contrôle la façon dont une partie (ou un ensemble) d’un message est protégée. Cette rubrique explique la fonctionnalité Windows Communication Foundation (WCF) et son fonctionnement.

Pour obtenir des instructions sur la définition du niveau de protection, consultez Guide pratique pour définir la propriété ProtectionLevel.

Remarque

Les niveaux de protection ne peuvent être définis que dans le code, et non dans la configuration.

Notions de base

Pour comprendre la fonctionnalité de niveau de protection, les instructions de base suivantes s’appliquent :

  • Trois niveaux de protection de base existent pour toute partie d’un message. La propriété (où qu’elle se produise) est définie sur l’une des valeurs d’énumération ProtectionLevel . Dans l’ordre croissant de protection, ils incluent :

    • None.

    • Sign. La partie protégée est signée numériquement. Cela garantit la détection de toute altération de la partie de message protégée.

    • EncryptAndSign. La partie de message est chiffrée pour garantir la confidentialité avant sa signature.

  • Vous pouvez définir les exigences de protection uniquement pour les données d’application avec cette fonctionnalité. Par exemple, les en-têtes WS-Addressing sont des données d'infrastructure et ne sont donc pas affectés par le ProtectionLevel.

  • Lorsque le mode de sécurité est défini Transportsur , le message entier est protégé par le mécanisme de transport. Par conséquent, la définition d’un niveau de protection distinct pour différentes parties d’un message n’a aucun effet.

  • La propriété ProtectionLevel permet aux développeurs de définir le niveau minimum de protection à respecter par les liaisons. Lorsqu’un service est déployé, la liaison réelle spécifiée dans la configuration peut ou non prendre en charge le niveau minimal. Par exemple, par défaut, la BasicHttpBinding classe ne fournit pas de sécurité (bien qu’elle puisse être activée). Par conséquent, l’utilisation de celui-ci avec un contrat qui a n’importe quel paramètre autre que None provoquera la levée d’une exception.

  • Si le service exige que le minimum ProtectionLevel pour tous les messages soit Sign, un client (peut-être créé par une technologie non WCF) peut chiffrer et signer tous les messages (ce qui est supérieur au minimum requis). Dans ce cas, WCF ne lève pas d’exception, car le client a effectué plus que le minimum. Notez toutefois que les applications WCF (services ou clients) éviteront de sur-sécuriser une partie de message si possible, mais respecteront le niveau minimal requis. Notez également que lors de l’utilisation Transport comme mode de sécurité, le transport peut sur-sécuriser le flux de messages, car il est intrinsèquement incapable de sécuriser à un niveau plus précis.

  • Si vous affectez explicitement ProtectionLevel ou Sign à la propriété EncryptAndSign, vous devrez alors utiliser une liaison dont la sécurité est activée, faute de quoi une exception sera levée.

  • Si vous sélectionnez une liaison qui active la sécurité et que vous ne définissez pas la ProtectionLevel propriété n’importe où sur le contrat, toutes les données d’application sont chiffrées et signées.

  • Si vous sélectionnez une liaison qui n’a pas de sécurité activée (par exemple, la BasicHttpBinding classe a la sécurité désactivée par défaut) et que celle-ci ProtectionLevel n’est pas définie explicitement, aucune donnée de l’application n’est protégée.

  • Si vous utilisez une liaison qui applique la sécurité au niveau du transport, toutes les données d’application sont sécurisées en fonction des fonctionnalités du transport.

  • Si vous utilisez une liaison qui applique la sécurité au niveau du message, les données d’application sont sécurisées en fonction des niveaux de protection définis sur le contrat. Si vous ne spécifiez pas de niveau de protection, toutes les données d’application dans les messages sont chiffrées et signées.

  • Des niveaux de portée différents peuvent être affectés à la propriété ProtectionLevel. Il existe en effet une hiérarchie dans les niveaux de portée. Cette hiérarchie est abordée en détail dans la section suivante.

Portée

La définition de la propriété ProtectionLevel à partir de l'API la plus élevée détermine le niveau de protection pour toutes les interfaces API figurant en dessous. Si la ProtectionLevel valeur est définie sur une valeur différente à un niveau inférieur, toutes les API inférieures à ce niveau de la hiérarchie seront désormais réinitialisées au nouveau niveau (les API au-dessus de celle-ci seront toutefois affectées par le niveau le plus élevé). La hiérarchie est la suivante. Les attributs au même niveau sont des homologues.

Programmation de la propriété ProtectionLevel

Pour programmer le ProtectionLevel à n'importe quel niveau de la hiérarchie, définissez simplement la propriété sur une valeur appropriée lors de l'application de l'attribut. Pour obtenir des exemples, consultez Guide pratique pour définir la propriété ProtectionLevel.

Remarque

La définition de la propriété sur les erreurs et les contrats de message nécessite de comprendre au préalable le fonctionnement de ces fonctionnalités. Pour plus d’informations, consultez Procédure : définir la propriété ProtectionLevel et Utiliser des contrats de message.

Dépendance WS-Addressing

Dans la plupart des cas, l’utilisation de l’outil utilitaire de métadonnées ServiceModel (Svcutil.exe) pour générer un client garantit que les contrats client et de service sont identiques. Toutefois, des contrats apparemment identiques peuvent provoquer la levée d'une exception de la part du client. Cela se produit lorsqu'une liaison ne prend pas en charge la spécification WS-Addressing et que plusieurs niveaux de protection sont spécifiés sur le contrat. Par exemple, la BasicHttpBinding classe ne prend pas en charge la spécification, ou si vous créez une liaison personnalisée qui ne prend pas en charge WS-Addressing. La ProtectionLevel fonctionnalité s’appuie sur la spécification WS-Addressing pour activer différents niveaux de protection sur un seul contrat. Si la liaison ne prend pas en charge la spécification WS-Addressing, tous les niveaux auront le même niveau de protection. Le niveau de protection effectif pour toutes les étendues du contrat sera défini sur le niveau de protection le plus fort utilisé sur le contrat.

Cela peut entraîner un problème difficile à déboguer à première vue. Il est possible de créer un contrat client (une interface) qui inclut des méthodes pour plusieurs services. Autrement dit, la même interface est utilisée pour créer un client qui communique avec de nombreux services, et l’interface unique contient des méthodes pour tous les services. Le développeur doit faire attention dans ce scénario rare à n'invoquer que les méthodes applicables à chaque service particulier. Si la liaison est la classe BasicHttpBinding, plusieurs niveaux de protection ne sont pas pris en charge. Toutefois, un service répondant au client peut répondre à un client avec un niveau de protection inférieur à celui requis. Dans ce cas, le client lève une exception, car il s’attend à un niveau de protection supérieur.

Un exemple de code illustre ce problème. L’exemple suivant montre un service et un contrat client. Supposons que la liaison est l’élément <basicHttpBinding> . Par conséquent, toutes les opérations sur un contrat ont le même niveau de protection. Ce niveau de protection uniforme est déterminé comme niveau de protection maximal dans toutes les opérations.

Le contrat de service est le suivant :

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

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

Le code suivant montre l’interface de contrat client. Notez qu’elle inclut une Tax méthode destinée à être utilisée avec un autre 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

Lorsque le client appelle la Price méthode, il lève une exception lorsqu’il reçoit une réponse du service. Cela se produit parce que le client ne spécifie pas de ProtectionLevel sur ServiceContractAttribute, et par conséquent, la valeur par défaut (EncryptAndSign) est utilisée pour toutes les méthodes, y compris la méthode Price. Toutefois, le service retourne la valeur en utilisant le niveau Sign, car le contrat de service définit une méthode unique dont le niveau de protection est défini sur Sign. Dans ce cas, le client génère une erreur lors de la validation de la réponse du service.

Voir aussi

  • Last updated on