Migration des services Web WSE 3.0 vers WCF
Les avantages liés à la migration des services Web WSE 3.0 vers Windows Communication Foundation (WCF) incluent l'amélioration des performances et la prise en charge de transports supplémentaires, de scénarios de sécurité supplémentaires et des spécifications WS-*. Un service Web migré à partir de WSE 3.0 vers WCF peut présenter une amélioration des performances comprise entre 200 % et 400 %. Pour plus d'informations sur les transports pris en charge par le WCF, consultez Choix d'un transport. Pour obtenir une liste des scénarios pris en charge par WCF, consultez Scénarios de sécurité courants. Pour obtenir une liste des spécifications prises en charge par WCF, consultez Guide de l'interopérabilité des protocoles de services Web.
Les sections suivantes fournissent une aide sur la manière de migrer une fonctionnalité spécifique d'un service Web WSE 3.0 vers WCF.
Généralités
Les applications WSE 3.0 et WCF incluent une interopérabilité au niveau du câble et un ensemble commun de terminologie. Les applications WSE 3.0 et WCF sont interopérables au niveau du câble en fonction de l'ensemble de spécifications WS-* qu'elles prennent en charge. Lorsqu'une application WSE 3.0 ou WCF est développée, il existe un ensemble commun de terminologie, telle que les noms des assertions de sécurité clé en main dans WSE et les modes d'authentification.
Bien qu'il y ait de nombreux aspects semblables entre les modèles de programmation WCF et ASP.NET ou WSE 3.0, ils sont différents. Pour plus d'informations sur le modèle de programmation WCF, consultez Cycle de vie de la programmation de base.
.gif "ms732008.note(fr-fr,VS.100).gif") Remarque : |
|---|
Pour migrer un service Web WSE vers WCF, l'Outil Service Model Metadata Tool (Svcutil.exe) peut être utilisé pour générer un client. Ce client contient des interfaces et des classes qui peuvent être utilisées également comme point de départ pour un service WCF. Les interfaces générées ont l'attribut OperationContractAttribute appliqué aux membres du contrat avec la propriété ReplyAction définie à *. Lorsqu'un client WSE appelle un service Web avec ce paramètre, l'exception suivante est levée : Web.Services3.ResponseProcessingException: WSE910 : Une erreur s'est produite lors du traitement d'un message de réponse ; pour plus d'informations, consultez l'exception interne. À des fins d'atténuation, affectez à la propriété ReplyAction de l'attribut OperationContractAttribute une valeur non Null, telle que http://Microsoft.WCF.Documentation/ResponseToOCAMethod.
|
Sécurité
Services Web WSE 3.0 sécurisés à l'aide d'un fichier de stratégie
Les services WCF peuvent utiliser un fichier de configuration pour sécuriser un service ; ce mécanisme s'apparente à un fichier de stratégie WSE 3.0. Dans WSE 3.0, lorsque vous sécurisez un service Web à l'aide d'un fichier de stratégie, vous utilisez une assertion de sécurité clé en main ou une assertion de stratégie personnalisée. Les assertions de sécurité clé en main sont mappées étroitement au mode d'authentification d'un élément de liaison de sécurité WCF. Les modes d'authentification WCF et les assertions de sécurité clé en main WSE 3.0 sont non seulement nommés de manière identique ou similaire, mais ils sécurisent les messages à l'aide des mêmes types d'informations d'identification. Par exemple, l'assertion de sécurité clé en main usernameForCertificate dans WSE 3.0 mappe au mode d'authentification UsernameForCertificate dans WCF. Les exemples de code suivants montrent comment une stratégie minimale qui utilise l'assertion de sécurité clé en main usernameForCertificate dans WSE 3.0 mappe à un mode d'authentification UsernameForCertificate dans WCF dans une liaison personnalisée.
WSE 3.0
<policies>
<policy name="MyPolicy">
<usernameForCertificate messageProtectionOrder="SignBeforeEncrypt"
requireDeriveKeys="true"/>
</policy>
</policies>
WCF
<customBinding>
<binding name="MyBinding">
<security authenticationMode="UserNameForCertificate"
messageProtectionOrder="SignBeforeEncrypt"
requireDerivedKeys="true"/>
</binding>
</customBinding>
Pour migrer les paramètres de sécurité d'un service Web WSE 3.0 spécifiés dans un fichier de stratégie vers WCF, une liaison personnalisée doit être créée dans un fichier de configuration et l'assertion de sécurité clé en main doit avoir pour valeur son mode d'authentification équivalent. En outre, la liaison personnalisée doit être configurée de façon à utiliser la spécification WS-Addressing d'août 2004 lorsque des clients WSE 3.0 communiquent avec le service. Lorsque le service WCF migré ne nécessite pas de communication avec des clients WSE 3.0 et doit uniquement maintenir la parité de sécurité, envisagez d'utiliser les liaisons définies par le système WCF avec les paramètres de sécurité appropriés au lieu de créer une liaison personnalisée.
Le tableau suivant répertorie le mappage entre un fichier de stratégie WSE 3.0 et la liaison personnalisée équivalente dans WCF.
| Assertion de sécurité clé en main WSE 3.0 | Configuration de liaison personnalisée WCF |
|---|---|
<usernameOverTransportSecurity /> |
|
<mutualCertificate10Security /> |
|
<usernameForCertificateSecurity /> |
|
<anonymousForCertificateSecurity /> |
|
<kerberosSecurity /> |
|
<mutualCertificate11Security /> |
|
Pour plus d'informations sur la création de liaisons personnalisées dans WCF, consultez Liaisons personnalisées.
Services Web WSE 3.0 sécurisés à l'aide du code d'application
Que WSE 3.0 ou WCF soit utilisé, les conditions de sécurité peuvent être spécifiées dans le code d'application plutôt que dans la configuration. Dans WSE 3.0, cette tâche est accomplie en créant une classe qui dérive de la classe Policy, puis en ajoutant les spécifications en appelant la méthode Add. Pour plus d'informations sur la spécification des conditions de sécurité dans le code, consultez Comment : sécuriser un service Web sans utiliser de fichier de stratégie (page pouvant être en anglais). Dans WCF, pour spécifier des conditions de sécurité dans le code, créez une instance de la classe BindingElementCollection et ajoutez une instance d'un SecurityBindingElement au BindingElementCollection. Les spécifications de l'assertion de sécurité sont définies à l'aide des méthodes d'assistance de mode d'authentification statiques de la classe SecurityBindingElement. Pour plus d'informations sur la spécification des conditions de sécurité dans le code à l'aide de WCF, consultez Comment : créer une liaison personnalisée à l'aide de SecurityBindingElement et Comment : créer un SecurityBindingElement pour un mode d'authentification spécifié.
Assertion de stratégie personnalisée WSE 3.0
Dans WSE 3.0, il existe deux types d'assertions de stratégie personnalisées : celles qui sécurisent un message SOAP et celles qui ne le font pas. Les assertions de stratégie qui sécurisent les messages SOAP dérivent de la classe SecurityPolicyAssertion WSE 3.0 et l'équivalent conceptuel dans WCF est la classe SecurityBindingElement.
Il convient de noter que les assertions de sécurité clé en main WSE 3.0 sont un sous-ensemble des modes d'authentification WCF. Si vous avez créé une assertion de stratégie personnalisée dans WSE 3.0, il peut exister un mode d'authentification WCF équivalent. Par exemple, WSE 3.0 ne fournit pas d'assertion de sécurité CertificateOverTransport qui équivaut à l'assertion de sécurité clé en main UsernameOverTransport, mais il utilise un certificat X.509 à des fins d'authentification du client. Si vous avez défini votre propre assertion de stratégie personnalisée pour ce scénario, WCF facilite grandement la migration. WCF définit un mode d'authentification pour ce scénario, ce qui vous permet de tirer parti des méthodes d'assistance de mode d'authentification statiques pour configurer un WCF SecurityBindingElement.
Lorsqu'il n'existe pas de mode d'authentification WCF équivalent à une assertion de stratégie personnalisée qui sécurise les messages SOAP, dérivez une classe des classes TransportSecurityBindingElement, SymmetricSecurityBindingElement ou AsymmetricSecurityBindingElementWCF et spécifiez l'élément de liaison équivalent. Pour plus d'informations, consultez Comment : créer une liaison personnalisée à l'aide de SecurityBindingElement.
Pour convertir une assertion de stratégie personnalisée qui ne sécurise pas de message SOAP, consultez Filtrage et l'exemple Custom Message Interceptor.
Jeton de sécurité personnalisé WSE 3.0
Le modèle de programmation WCF permettant de créer un jeton personnalisé diffère de WSE 3.0. Pour plus d'informations sur la création d'un jeton personnalisé dans WSE, consultez Création de jetons de sécurité personnalisés (page éventuellement en anglais). Pour plus d'informations sur la création d'un jeton personnalisé dans WCF, consultez Comment : créer un jeton personnalisé.
Gestionnaire de jetons personnalisés WSE 3.0
Le modèle de programmation permettant de créer un gestionnaire de jetons personnalisés diffère entre WCF et WSE 3.0. Pour plus d'informations sur la création d'un gestionnaire de jetons personnalisés et les autres composants qui sont obligatoires pour un jeton de sécurité personnalisé, consultez Comment : créer un jeton personnalisé.
| Remarque : |
|---|
| Si vous avez créé un gestionnaire de jetons de sécurité UsernameToken personnalisés, WCF fournit un mécanisme plus simple pour spécifier la logique d'authentification que la création d'un gestionnaire de jetons de sécurité personnalisés. Pour plus d'informations, consultez Comment : utiliser un validateur de nom d'utilisateur et de mot de passe personnalisé. |
Services Web WSE 3.0 qui utilisent des messages SOAP encodés MTOM
Comme une application WSE 3, une application WCF peut spécifier l'encodage de message MTOM dans la configuration. Pour migrer ce paramètre, ajoutez le mtomMessageEncoding element à la liaison pour le service. L'exemple de code suivant montre comment l'encodage MTOM est spécifié dans WSE 3.0 pour un service qui est équivalent dans WCF.
WSE 3.0
<messaging>
<mtom clientMode="On"/>
</messaging>
WCF
<customBinding>
<binding name="MyBinding">
<mtomMessageEncoding/>
</binding>
</customBinding>
Messagerie
Applications WSE 3.0 qui utilisent l'API de messagerie WSE
Lorsque l'API de messagerie WSE est utilisée pour obtenir un accès direct au XML communiqué entre le client et le service Web, l'application peut être convertie de façon à utiliser le « Plain Old XML » (POX). Pour plus d'informations sur POX, consultez Interopérabilité avec les applications POX. Pour plus d'informations sur l'API de messagerie WSE, consultez Envoi et réception de messages SOAP à l'aide de l'API de messagerie WSE (page éventuellement en anglais).
Transports
TCP
Par défaut, les services Web et les clients WSE 3.0 qui envoient des messages SOAP à l'aide du transport TCP n'interagissent pas avec les services Web et les clients WCF. Cette incompatibilité est due aux différences de tramage utilisé dans le protocole TCP et aux performances. Toutefois, un exemple WCF décrit comment implémenter une session TCP personnalisée qui interagit avec WSE 3.0. Pour plus d'informations sur cet exemple, consultez Transport: WSE 3.0 TCP Interoperability.
Pour spécifier qu'une application WCF utilise le transport TCP, utilisez le netTcpBinding Element.
Transport personnalisé
L'équivalent d'un transport personnalisé WSE 3.0 dans WCF est une extension de canal. Pour plus d'informations sur la création d'une extension de canal, consultez Extension de la couche du canal.
Voir aussi
Tâches
Comment : créer un SecurityBindingElement pour un mode d'authentification spécifié
Concepts
Cycle de vie de la programmation de base
Liaisons personnalisées
Comment : créer une liaison personnalisée à l'aide de SecurityBindingElement