Lire en anglais

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 (username@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 Exemple d’identité du service. 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 le WSDL. Si le service s’exécute sous le compte LocalSystem, LocalService, ou NetworkService, un nom de principal du 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 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 plus d’informations sur l’outil, consultez Setspn Overview (Vue d’ensemble de Setspn).

Notes

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 ce faire, 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.

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’information d’identification du client dans la liaison présentée précédemment par Certificate, alors le fichier WSDL généré contient un certificat X.509 sérialisé en base 64 pour la valeur d’identité, tel qu’indiqué 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.

C# 
ServiceEndpoint ep = myServiceHost.AddServiceEndpoint(
                typeof(ICalculator),
                new WSHttpBinding(),
                String.Empty);
EndpointAddress myEndpointAdd = new EndpointAddress(new Uri("http://localhost:8088/calc"),
     EndpointIdentity.CreateDnsIdentity("contoso.com"));
ep.Address = myEndpointAdd;

Voir aussi