Share via

Scénarios non pris en charge

  • Article

Pour diverses raisons, Windows Communication Foundation (WCF) ne prend pas en charge certains scénarios de sécurité spécifiques. Par exemple, Windows XP Édition familiale n’implémentant pas les protocoles d’authentification SSPI ou Kerberos, WCF ne prend pas en charge, sur ce type de plateforme, l’exécution des services utilisant l’authentification Windows. En revanche, d’autres mécanismes d’authentification, tels que l’association nom d’utilisateur/mot de passe et l’authentification intégrée HTTP/HTTPS, sont pris en charge lorsque WCF s’exécute sous Windows XP Édition familiale.

Scénarios d’emprunt d’identité

Il se peut que l’identité empruntée ne fonctionne pas correctement lorsque des clients passent des appels asynchrones

Lorsqu'un client WCF passe des appels asynchrones à un service WCF à l'aide de l'authentification Windows sous un emprunt d'identité, l'authentification peut se produire avec l'identité du processus client au lieu de l'identité empruntée.

WCF ne prend pas en charge l’emprunt d’identité et une exception InvalidOperationException est levée dans les cas suivants :

  • Le système d’exploitation est Windows XP.

  • Le mode d'authentification aboutit à un identité Windows.

  • La propriété Impersonation du OperationBehaviorAttribute a la valeur Required.

  • Un jeton de contexte de sécurité basé sur l'état est créé (cette création est désactivée par défaut).

Ce jeton peut uniquement être crée à l’aide d’une liaison personnalisée. Pour plus d’informations, consultez Procédure : créer un jeton de contexte de sécurité pour une session sécurisée.) Dans le code, ce jeton est activé en créant un élément de liaison de sécurité (SymmetricSecurityBindingElement ou AsymmetricSecurityBindingElement) à l’aide de la méthode SecurityBindingElement.CreateSspiNegotiationBindingElement(Boolean) ou SecurityBindingElement.CreateSecureConversationBindingElement(SecurityBindingElement, Boolean) et en affectant au paramètre requireCancellation la valeur false. Ce paramètre concerne la mise en cache du jeton. L'affectation de la valeur false à ce paramètre permet d'activer la fonctionnalité de jeton basé sur l'état.

Ou bien, dans la configuration, le jeton est activé en créant une liaison <customBinding>, en ajoutant un élément <security>, puis en affectant à l’attribut authenticationMode la valeur SecureConversation et à l’attribut requireSecurityContextCancellation la valeur true.

Notes

Les spécifications précédentes sont spécifiques. Par exemple, l’élément CreateKerberosBindingElement crée un élément de liaison qui aboutit à une identité Windows, mais cet élément ne définit pas de jeton de contexte de sécurité avec état. Vous pouvez donc utiliser cet élément avec l’option Required de Windows XP.

Éventuel conflit avec ASP.NET

WCF et ASP.NET permettent l’activation ou la désactivation de l’emprunt d’identité. Lorsque ASP.NET héberge une application WCF, un conflit peut exister entre les paramètres de configuration WCF et ASP.NET. En cas de conflit, le paramètre WCF est prioritaire, sauf si la propriété Impersonation a la valeur NotAllowed, auquel cas c’est le paramètre d’emprunt d’identité d’ASP.NET qui est prioritaire.

Les chargements d’assembly risquent d’échouer lorsque l’emprunt d’identité est activé

Si le contexte emprunté ne dispose de droits d'accès permettant le chargement d'un assembly et que l'objet CLR tente pour la première fois de le charger pour AppDomain, AppDomain met l'échec en mémoire cache. Les tentatives suivantes pour charger cet assembly échoueront également, même après restauration de l'emprunt d'identité et même si le contexte restauré dispose cette fois de droits d'accès permettant de charger cet assembly. Ces échecs successifs se produisent car l’objet CLR ne tente pas une nouvelle fois de charger l’assembly après la modification du contexte utilisateur. Vous devez redémarrer le domaine d'application pour résoudre ce problème.

Notes

La valeur par défaut de la propriété AllowedImpersonationLevel de la classe WindowsClientCredential est Identification. Dans la plupart des cas, les contextes d'emprunt d'identité de niveau identification ne disposent pas de droits leur permettant de charger d'autres assemblys. Il s'agit de la valeur par défaut. Il est donc important de garder à l'esprit ce cas très fréquent. L'emprunt d'identité de niveau identification se produit lorsque le processus d'emprunt ne dispose pas du droit SeImpersonate. Pour plus d’informations, consultez Délégation et emprunt d’identité.

La délégation nécessite la négociation des informations d’identification

Pour pouvoir utiliser le protocole d'authentification Kerberos avec la délégation, vous devez implémenter le protocole Kerberos en utilisant la négociation des informations d'identification (parfois appelé Kerberos multi-segment ou multi-étape). Si vous implémentez l'authentification Kerberos sans négociation d'informations d'identification (parfois appelée Kerberos « one-shot » ou Kerberos « single-leg »), une exception est levée. Pour plus d’informations sur l’implémentation de la négociation des informations d’identification, consultez Débogage des erreurs d’authentification Windows.

Chiffrement

SHA-256 uniquement pris en charge lorsque des clés symétriques sont utilisées

WCF prend en charge différents algorithmes Digest de création de chiffrement et de signature que vous pouvez spécifier à l’aide de la suite algorithmique figurant dans les liaisons fournies par le système. Afin d’améliorer la sécurité, WCF prend en charge les algorithmes Secure Hash Algorithm (SHA) 2 et plus particulièrement les algorithmes SHA-256, lesquels permettent la création de hachages de condensat de signature. Cette mise en production prend uniquement en charge SHA-256 lorsque des clés symétriques, telles que les clés Kerberos sont utilisées et lorsque les messages ne sont pas signés par les certificats X.509. WCF ne prend pas en charge les signatures RSA (utilisées dans les certificats X.509) à l’aide du hachage SHA-256 en raison de l’absence de prise en charge de RSA-SHA256 dans WinFX.

Hachage SHA-256 conforme FIPS non pris en charge

WCF ne prenant pas en charge les hachages SHA-256 conformes FIPS, les suites algorithmiques qui utilisent SHA-256 ne sont pas prises en charge par WCF sur les systèmes nécessitant l’utilisation d’algorithmes conformes FIPS.

Les algorithmes conformes FIPS risquent d’échouer si le registre est modifié

Vous pouvez activer ou désactiver les algorithmes conformes FIPS en utilisant les paramètres de sécurité locale de l'outil enfichable MMC. Ces paramètres sont également accessibles à partir du registre. Remarque : WCF ne prend pas en charge l’utilisation du registre pour modifier ces paramètres. Si vous affectez à ces paramètres une valeur autre que 1 ou 0, cela risque de générer des résultats incohérents entre CLR et le système d'exploitation.

Limites d’utilisation concernant le chiffrement AES conforme FIPS

Le chiffrement AES conforme FIPS n’est pas compatible avec les rappels duplex dans le cadre des emprunts d’identité de niveau identification.

Certificats CNG/KSP

Cryptography API: Next Generation (CNG) se substitue à CryptoAPI. Cette API est disponible dans du code non managé sur Windows Vista, Windows Server 2008 et versions ultérieures de Windows.

Les versions .NET Framework 4.6.1 et antérieures ne prennent pas en charge ces certificats, car elles utilisent la CryptoAPI héritée pour gérer les certificats CNG/KSP. L’utilisation de ces certificats avec .NET Framework 4.6.1 et versions antérieures entraîne une exception.

Pour indiquer si un certificat utilise KSP, deux méthodes sont possibles :

  • Exécutez p/invoke de CertGetCertificateContextProperty et inspectez dwProvType sur la CertGetCertificateContextProperty retournée.

  • Utilisez la commande certutil à partir de la ligne de commande pour interroger des certificats. Pour plus d’informations, consultez la page Tâches CertUtil pour la résolution des problèmes de certificat.

La sécurité de message échouera si l’emprunt d’identité ASP.NET est utilisé et si la compatibilité ASP.NET est requise

WCF ne prend pas en charge l’utilisation combinée des paramètres suivants, une telle utilisation pouvant empêcher l’authentification client :

  • L’emprunt d’identité ASP.NET est activé. Cette activation s’effectue dans le fichier Web.config en affectant à l’attribut impersonate de l’élément <identity> la valeur true.

  • Le mode de compatibilité ASP.NET est activé en définissant l’attribut aspNetCompatibilityEnabled de <serviceHostingEnvironment> sur true.

  • Le mode de sécurité de niveau message est utilisé.

Pour contourner cette difficulté, il suffit de désactiver le mode de compatibilité ASP.NET. Si le mode de compatibilité ASP.NET est requis, désactivez la fonctionnalité d’emprunt d’identité ASP.NET et utilisez la fonctionnalité d’emprunt d’identité fournie par WCF à la place. Pour plus d’informations, consultez Délégation et emprunt d’identité.

Échec d’adresse littérale IPv6

Les demandes de sécurité échouent si le client et le service s'exécutent sur le même ordinateur et les adresses littérales IPv6 sont utilisées pour le service.

L'utilisation d'adresses littérales IPv6 est possible à condition que le client et le service ne s'exécutent pas sur le même ordinateur.

Échecs de récupération WSDL avec approbation fédérée

WCF requiert exactement un document WSDL pour chaque nœud dans la chaîne d’approbation fédérée. Veillez à ne pas définir de boucle lors de la spécification des points de terminaison. Des boucles peuvent résulter de l'utilisation d'un téléchargement WSDL de chaînes d'approbation fédérée avec au moins deux liens dans le même document WSDL. Un scénario courant pouvant induire ce problème est un service fédéré où le serveur de jeton de sécurité et le service sont contenus dans le même ServiceHost.

Un service comportant les trois adresses de point de terminaison suivantes est un exemple illustrant cette situation :

  • http://localhost/CalculatorService/service (le service)

  • http://localhost/CalculatorService/issue_ticket (the STS)

  • http://localhost/CalculatorService/mex (le point de terminaison de métadonnées)

Ce scénario lève une exception.

Pour qu'il fonctionne, vous pouvez placer le point de terminaison issue_ticket ailleurs.

Risques de perte des attributs d’importation WSDL

WCF perd la trace des attributs sur un élément <wst:Claims> dans un modèle RST lors de l'exécution d'une importation WSDL. Cela se produit pendant une importation WSDL si vous spécifiez directement <Claims> dans WSFederationHttpBinding.Security.Message.TokenRequestParameters ou IssuedSecurityTokenRequestParameters.AdditionalRequestParameters au lieu d’utiliser directement les collections de types de revendication. Puisque l’importation perd les attributs, la liaison ne fait pas l’aller-retour correctement dans WSDL et est donc incorrecte du côté client.

pour corriger cette situation, il convient de modifier directement la liaison sur le client après l’importation.

Voir aussi