--- schema_version: "1" id: dff4d59d4bdca2ad8ea0183deb2b4fe1d973dc9c2146b187e8f5e89bc51192fa title: Configuration requise pour utiliser OpenID Connect collection: tableau version: next locale: fr-ca portal_url: https://docs.salesforce.com/tableau/next/fr-ca/server/openid_auth_requirements.md canonical_url: https://help.tableau.com/v0.0/server/fr-ca/openid_auth_requirements.htm source_site: help.tableau.com content_type: documentation content_hash: e4f426c38dd6c9ade3eeab0968af7e85e6a16befcfdf3be70b65a3d110056b83 description: Understand the requirements for using OpenID Connect with Tableau Server. --- [Passer au contenu principal](#main-content) # Configuration requise pour utiliser OpenID Connect Cette rubrique décrit les éléments requis pour utiliser OpenID Connect avec Tableau Server. **Remarque :** Les commandes de configuration de l’authentification TSM s’appliquent uniquement à l’authentification OIDC configurée dans TSM lors de la configuration de Tableau Server. Pour modifier la configuration de l’authentification OIDC pour les pools d’identités, vous pouvez utiliser le point de terminaison [Mettre à jour la configuration de l’authentification](https://help.tableau.com/current/api/rest_api/fr-ca/REST/TAG/index.html#operation/AuthnService_UpdateAuthConfiguration) à l’aide de l’OpenAPI REST de Tableau. **Résumé des exigences** - Compte IdP - Magasin d’identités local - Revendications du fournisseur d’identité – mappage des utilisateurs - Contexte d’authentification ## Compte IdP Vous devez avoir accès à un fournisseur d’identité (IdP) prenant en charge le protocole OpenID Connect (OIDC). Vous devez également avoir un compte avec l’IdP. OpenID Connect est pris en charge par de nombreux fournisseurs d’identité. Le protocole OIDC est un norme ouverte et flexible, et de ce fait, les implémentations de la norme ne sont pas toutes identiques. Lorsque vous configurez Tableau Server pour OIDC, adressez-vous à votre fournisseur d’identité. L’implémentation d’IdP Google a été testée de manière complète avec Tableau Server et représente le modèle d’IdP pour la configuration décrite dans ces rubriques. ## Magasin d’identités local Pour utiliser OpenID Connect dans Tableau Server, l’une des conditions suivantes doit être remplie : - **Si vous devez configurer l’authentification OIDC dans TSM pendant la configuration de Tableau Server**, Tableau Server doit être configuré pour utiliser un magasin d’identités local. Le serveur doit être configuré de manière à ce que vous puissiez créer explicitement des utilisateurs sur Tableau Server, plutôt que de les importer depuis un répertoire externe, par exemple Active Directory. La gestion des utilisateurs avec un magasin d’identités externe n’est pas prise en charge par OpenID. - **Si vous devez configurer l’authentification OIDC à l’aide de** [pools d’identités](https://help.tableau.com/v0.0/server/fr-ca/identity_pools.htm), OIDC peut être configuré avec 1) un magasin d’identités local ou 2) AD ou LDAP est le magasin d’identités configuré dans TSM lors de la configuration de Tableau Server. ## Revendications du fournisseur d’identité – mappage des utilisateurs Pour réussir à se connecter à Tableau Server, un utilisateur donné doit être provisionné dans OpenID puis mappé à un compte utilisateur sur Tableau Server. OpenID utilise une méthode basée sur les _revendications_ pour partager les attributs de compte utilisateur avec d’autres applications. Les revendications incluent les attributs de compte utilisateur tels que l’adresse de courriel, le numéro de téléphone, le prénom, etc. Pour comprendre comment Tableau Server mappe les revendications de fournisseur d’identité à des comptes utilisateur, consultez [OpenID Connect](https://help.tableau.com/v0.0/server/fr-ca/openid_auth.htm#Authenti). Tableau Server s’appuie sur les revendications IdP pour mapper des comptes utilisateur depuis l’IdP vers les comptes hébergés sur Tableau Server. Par défaut, Tableau Server attend du fournisseur d’identité qu’il transmette la revendication courriel. Selon votre IdP, il se peut que vous deviez configurer Tableau Server pour qu’il utilise une revendication de fournisseur d’identité différente. Si vous utilisez Google comme IdP, utilisez la revendication par défaut `email` pour mapper les identités IdP aux comptes utilisateur de Tableau Server. Si vous n’utilisez pas Google comme IdP, adressez-vous à votre IdP pour déterminer la revendication pour laquelle vous devriez configurer Tableau Server. ### Par défaut : utilisation d’une revendication email pour mapper les utilisateurs Par défaut, le nom d’utilisateur de l’utilisateur dans Tableau Server doit correspondre à la revendication `email` dans le jeton d’ID du fournisseur d’identité. Par conséquent, dans la configuration par défaut, vous devez utiliser les adresses de courriel (également appelées UPN) comme nom d’utilisateur dans Tableau Server. Si vous utilisez Google comme IdP, le nom d’utilisateur dans Tableau Server doit être l’adresse Gmail de l’utilisateur (`alice@gmail.com`). Utiliser une adresse de courriel complète de cette manière aide à garantir le caractère unique du nom d’utilisateur dans Tableau Server, même quand deux utilisateurs ont la même adresse de courriel, mais sur des hôtes de messagerie différents. **Remarque :** lorsque vous créez une identité de l’utilisateur dans Tableau Server, vous spécifiez un nom d’utilisateur, un mot de passe, et de manière facultative, une adresse de courriel. Pour utiliser OpenID Connect dans la configuration par défaut, le nom d’utilisateur (exprimé sous la forme d’une adresse de courriel) est la valeur qui doit correspondre au nom d’utilisateur dans le fournisseur d’identités. L’adresse de courriel facultative dans l’identité de l’utilisateur de Tableau Server n’est pas utilisée pour l’authentification OpenID. #### Ignorer le nom de domaine Vous pouvez configurer Tableau de manière à ce qu’il ignore la partie domaine d’une adresse de courriel lors de la mise en correspondance de la revendication `email` du fournisseur d’identité avec un compte utilisateur sur Tableau Server. Dans ce scénario, la revendication `email` dans l’IdP peut être `alice@example.com`, mais elle correspondra à un utilisateur appelé `alice` dans Tableau Server. Il peut être utile d’ignorer le nom de domaine si des utilisateurs déjà définis dans Tableau Server ont des noms correspondant à la partie nom d’utilisateur de la revendication `email`, mais non aux parties domaine. **Important :** nous vous déconseillons d’ignorer nom de domaine de l’utilisateur sans prendre de précautions. Plus spécifiquement, vérifiez que les noms d’utilisateur sont uniques dans les domaines configurés que vous avez créés dans votre IdP. Si vous configurez Tableau Server de manière à ce qu’il ignore le nom de domaine de l’utilisateur, il peut arriver qu’un utilisateur non attendu se connecte. Considérez le cas où votre IdP a été configuré pour plusieurs domaines (`example.com` et `tableau.com`). Si deux utilisateurs ayant le même prénom, mais des comptes utilisateur différents (`alice@tableau.com` et `alice@example.com`) font partie de votre organisation, le premier à terminer la séquence de provisionnement OpenID revendiquera le mappage `sub` dans l’IdP. Si l’utilisateur incorrect est mappé, l’autre utilisateur ne pourra pas se connecter tant que la valeur `sub` associée n’a pas été réinitialisée. Pour configurer Tableau Server de manière à ce qu’il ignore les noms de domaine dans les noms d’utilisateur depuis l’IdP, définissez `tsm authentication openid configure --ignore-domain` sur `true`. Pour plus d’informations, consultez [tsm authentication openid ](https://help.tableau.com/v0.0/server/fr-ca/cli_authentication_tsm.htm#TSMOIDC). Lorsque vous modifiez l’option tsm authentication openid configure `--ignore-domain` de manière à ignorer le domaine dans les noms d’utilisateur, tous les noms d’utilisateur dans Tableau Server doivent avoir un nom de domaine. ### Utilisation de revendications personnalisées pour mapper les utilisateurs Comme indiqué dans [OpenID Connect](https://help.tableau.com/v0.0/server/fr-ca/openid_auth.htm#Authenti), la revendication `sub` est souvent incluse dans les revendications du fournisseur d’identités. En règle générale, la revendication `sub` est une chaîne unique qui identifie un compte utilisateur donné. L’avantage d’utiliser une revendication `sub` est qu’elle ne changera pas, même si vous-même ou un administrateur mettez à jour d’autres attributs utilisateur ou revendications du fournisseur d’identités (courriel, numéro de téléphone, etc) associés à ce compte. Par défaut, Tableau Server identifie et vérifie les utilisateurs OpenID selon la revendication `sub` dans le jeton d’ID du fournisseur d’identité. La valeur de revendication `sub` d’OpenID doit être mappée à l’utilisateur correspondant dans Tableau Server. Étant donné que la revendication `sub` est une chaîne arbitraire, une revendication différente est utilisée pour associer les comptes pendant la première session de connexion. La première fois qu’un utilisateur se connecte à Tableau Server avec OpenID, Tableau associe le compte utilisateur OpenID à un compte utilisateur correspondant dans Tableau Server. Par défaut, Tableau utilise la revendication IdP, `email`, pour identifier l’utilisateur Tableau. Tableau mettra ensuite à jour l’enregistrement de l’utilisateur avec la revendication `sub` d’OpenID. Étant donné que le jeton d’ID inclut toujours la revendication `sub` en même temps que d’autres revendications, sur les sessions suivantes, Tableau identifiera cet utilisateur avec la revendication `sub` uniquement. Dans certaines organisations, le mappage de noms d’utilisateurs avec l’adresse de courriel n’est pas fiable ou n’est pas prise en charge par le fournisseur d’identités. Depuis Tableau Server 10.2, vous pouvez mapper les comptes utilisateur depuis toute revendication d’IdP arbitraire vers le nom d’utilisateur Tableau Server. La revendication d’IdP que vous utilisez doit être mappée exactement à un nom d’utilisateur Tableau Server existant. Dans l’exemple ci-dessous, le nom d’utilisateur est `kwilliams`. ![Un formulaire pour ajouter un nouvel utilisateur sur Tableau Server.](/tableau/next/fr-ca/server/fr-ca/Img/users_add_srvruser.png) Pour modifier la revendication IdP utilisée pour mapper l’identité sur Tableau Server, utilisez la commande `tsm authentication openid map-claims --user-name`. Pour plus d’informations, consultez [tsm authentication openid ](https://help.tableau.com/v0.0/server/fr-ca/cli_authentication_tsm.htm#TSMOIDC). ### Modification de la revendication `sub` Comme décrit ci-dessus, la revendication `sub` est l’identifiant utilisé par Tableau Server pour identifier les utilisateurs après la session de mappage initiale. La revendication `sub` est rédigée sur le compte utilisateur correspondant dans Tableau Server. Si votre IdP ne fournit pas de revendication `sub`, vous pouvez spécifier une revendication arbitraire à utiliser à la place. De même que pour `sub`, la valeur de revendication que vous spécifiez doit être unique et ne devrait pas changer lors de la mise à jour d’autres revendications utilisateur. Pour spécifier une revendication d’IdP différente pour la revendication secondaire par défaut, utilisez la commande `tsm authentication openid map-claims --id`. Pour plus d’informations, consultez [tsm authentication openid ](https://help.tableau.com/v0.0/server/fr-ca/cli_authentication_tsm.htm#TSMOIDC). Où `arbitraryClaim` est le nom de la revendication IdP que vous souhaitez utiliser en remplacement de la revendication `sub`. ## Contexte d’authentification Si votre IdP OpenID Connect nécessite un contexte d’authentification spécifique, vous pouvez spécifier une liste de valeurs ACR essentielles et volontaires à l’aide des clés de configuration `vizportal.openid.essential_acr_values` et `vizportal.openid.voluntary_acr_values`. Consultez [Options tsm configuration set](https://help.tableau.com/v0.0/server/fr-ca/cli_configuration-set_tsm.htm) pour plus d’informations.