Partager via

Substitution de l'identité d'un service pour l'authentification

  • Article

Généralement, vous n'avez pas besoin de définir l'identité sur un service car la sélection d'un type d'informations d'identification du client impose le type d'identité exposé dans les métadonnées du service. Par exemple, le code de configuration suivant utilise l'élément <wsHttpBinding> et affecte la valeur Windows à l'attribut clientCredentialType.

Le fragment WSDL (Web Services Description Language) suivant affiche l'identité du point de terminaison défini précédemment. Dans cet exemple, le service s'exécute comme un service auto-hébergé sous un compte d'utilisateur particulier (nom_utilisateur@contoso.com). Par conséquent, l'identité de nom d'utilisateur principal (UPN) contient le nom du compte. L'UPN est également appelé nom de connexion d'utilisateur dans un domaine Windows.

Pour un exemple d'application qui illustre le paramètre d'identité, consultez Service Identity Sample. Pour plus d'informations sur l'identité de service, consultez Identité du service et authentification.

Authentification et identité Kerberos

Par défaut, lorsqu'un service est configuré pour utiliser des informations d'identification Windows, un élément <identity> qui contient un élément <userPrincipalName> ou <servicePrincipalName> est généré dans WSDL. Si le service s'exécute sous le compte LocalSystem, LocalService ou NetworkService, un nom principal de service (SPN) est généré par défaut au format host/<nom_hôte> car ces comptes ont accès aux données SPN de l'ordinateur. Si le service s'exécute sous un compte différent, Windows Communication Foundation (WCF) génère un UPN au format <nom_utilisateur>@<nom_domaine>. Cela est dû au fait que l'authentification Kerberos requiert qu'un UPN ou SPN soit fourni au client pour authentifier le service.

Vous pouvez également utiliser l'outil Setspn.exe pour inscrire un SPN supplémentaire avec un compte de service dans un domaine. Vous pouvez ensuite utiliser le SPN comme identité du service. Pour télécharger l'outil, consultez Windows 2000 Resource Kit Tool : Setspn.exe. Pour plus d'informations sur cet outil, consultez Présentation de Setspn (page pouvant être en anglais).

Bb628618.note(fr-fr,VS.90).gifRemarque :
Pour utiliser le type d'informations d'identification Windows sans négociation, le compte d'utilisateur du service doit avoir accès au SPN inscrit avec le domaine Active Directory. Pour cela, vous pouvez procéder de différentes façons :

  • Utilisez le compte NetworkService ou LocalSystem pour exécuter votre service. Comme ces comptes ont accès au SPN de l'ordinateur établi lorsque l'ordinateur rejoint le domaine Active Directory, WCF génère automatiquement l'élément SPN approprié à l'intérieur du point de terminaison du service dans les métadonnées du service (WSDL).
  • Utilisez un compte de domaine Active Directory arbitraire pour exécuter votre service. Dans ce cas, établissez un SPN pour ce compte de domaine, pour cela vous pouvez vous servir de l'utilitaire Setspn.exe. Une fois que le SPN du compte du service a été créé, configurez WCF pour publier ce SPN sur les clients du service par le biais de ses métadonnées (WSDL). Pour cela, il suffit de définir l'identité du point de terminaison exposé, à l'aide d'un fichier de configuration d'application ou du code.

Pour plus d'informations sur les noms principaux de service, le protocole Kerberos et Active Directory, consultez Supplément technique relatif à Kerberos pour Windows (page pouvant être en anglais).

Lorsque SPN ou UPN équivaut à une chaîne vide

Si vous attribuez une valeur de chaîne vide à SPN ou UPN, plusieurs choses se produisent, en fonction du niveau de sécurité et du mode d'authentification utilisés :

  • Si vous utilisez la sécurité de niveau transport, l'authentification NTLM (NT LanMan) est choisie.
  • Si vous utilisez la sécurité de niveau message, l'authentification peut échouer, en fonction du mode d'authentification.
  • Si vous utilisez le mode spnego et que l'attribut AllowNtlm a la valeur false, l'authentification échoue.
  • Si vous utilisez le mode spnego et que l'attribut AllowNtlm a la valeur true, l'authentification échoue si l'UPN est vide, mais réussit si le SPN est vide.
  • Si vous utilisez Kerberos direct (également appelé « one-shot »), l'authentification échoue.

Utilisation de l'élément <identity> dans la configuration

Si vous remplacez le type d'informations d'identification du client dans la liaison présentée précédemment par Certificate, le fichier WSDL généré contient alors un certificat X.509 sérialisé pour la valeur d'identité, comme illustré dans le code suivant. Il s'agit de la valeur par défaut pour tous les types d'informations d'identification du client autres que Windows.

Vous pouvez modifier la valeur de l'identité de service par défaut ou le type de l'identité à l'aide de l'élément <identity> dans la configuration ou en définissant l'identité dans le code. Le code de configuration suivant affecte à une identité DNS (Domain Name System) la valeur contoso.com.

Définition de l'identité par programme

Votre service n'a pas besoin de spécifier une identité de manière explicite, car WCF la détermine automatiquement. Toutefois, WCF vous permet de spécifier une identité sur un point de terminaison, le cas échéant. Le code suivant ajoute un point de terminaison de service avec une identité DNS spécifique.

Voir aussi

Tâches

Comment : créer un vérificateur d'identité du client personnalisé

Concepts

Identité du service et authentification