--- schema_version: "1" id: 9b023263f610acf43f2cd2b34cbe294baebe196ff39ab7baf6a838f2d4afbec8 title: Configuration requise pour utiliser OpenID Connect collection: tableau version: current locale: fr-fr portal_url: https://docs.salesforce.com/tableau/current/fr-fr/server-linux/openid_auth_requirements.md canonical_url: https://help.tableau.com/current/server-linux/fr-fr/openid_auth_requirements.htm source_site: help.tableau.com content_type: documentation content_hash: dcf3b85261dc64bac1d807e9d3d651b9e6c5565c65e427748f1d2376c750a84c 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 apporter des modifications à 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-fr/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 de l’IdP - 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 IdP. 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 sur Tableau Server, l’une des conditions suivantes doit être vraie : - **Si vous configurez OIDC dans TSM pendant l’installation de Tableau Server**, Tableau Server doit être configuré pour utiliser le 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 configurez OIDC à l’aide de** [pools d’identités](https://help.tableau.com/current/server-linux/fr-fr/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 de l’IdP - Mappage des utilisateurs Pour se connecter avec succès à 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’e-mail, le numéro de téléphone, le nom de famille, etc. Pour comprendre comment Tableau Server mappe des revendications de l’IdP à des comptes utilisateur, consultez [OpenID Connect](https://help.tableau.com/current/server-linux/fr-fr/openid_auth.htm#Authenti). Tableau Server s’appuie sur les revendications de l’IdP pour mapper des comptes utilisateur depuis l’IdP vers les comptes hébergés sur Tableau Server. Par défaut, Tableau Server attend de l’IdP qu’il transmette la revendication email. Selon votre IdP, il se peut que vous deviez configurer Tableau Server pour qu’il utilise une revendication d’IdP différente. Si vous utilisez Google comme IdP, utilisez la revendication `email` par défaut pour mapper les identités IdP aux comptes utilisateur 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 de l’IdP. Par conséquent, dans la configuration par défaut, vous devez utiliser les adresses de messagerie (également appelées UPN) comme nom d’utilisateur dans Tableau Server. Si vous utilisez Google comme IdP, le nom d’utilisateur dans Tableau Serverr doit être l’adresse Gmail de l’utilisateur (`alice@gmail.com`). Utiliser une adresse de messagerie complète de cette manière aide à garantir le caractère unique du nom d’utilisateur dans Tableau Server, même dans le cas où deux utilisateurs ont la même adresse de messagerie, mais sur des hôtes de messagerie différents. **Remarque** : lorsque vous créez une identité d’utilisateur dans Tableau Server, vous spécifiez un nom d’utilisateur, un mot de passe, et de manière facultative, une adresse e-mail. Pour utiliser OpenID Connect dans la configuration par défaut, le nom d’utilisateur (exprimé sous la forme d’une adresse de messagerie) est la valeur qui doit correspondre au nom d’utilisateur dans l’IdP. L’adresse e-mail facultative dans l’identité d’utilisateur 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 e-mail lors de la mise en correspondance de la revendication `email` de l’IdP 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/current/server-linux/fr-fr/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/current/server-linux/fr-fr/openid_auth.htm#Authenti), la revendication `sub` est souvent incluse dans les revendications de l’IdP. 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 d’IdP (email, 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 de l’IdP. 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 messagerie n’est pas fiable ou n’est pas prise en charge par l’IdP. 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 correspondant. Dans l’exemple ci-dessous, le nom d’utilisateur est `kwilliams`. ![Un formulaire permettant d’ajouter un nouvel utilisateur sur Tableau Server.](/tableau/current/fr-fr/server-linux/fr-fr/Img/users_add_srvruser.png) Pour modifier la revendication de l’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/current/server-linux/fr-fr/cli_authentication_tsm.htm#TSMOIDC). ### Modification de la revendication `sub` Comme décrit ci-dessous, 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 écrite 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/current/server-linux/fr-fr/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/current/server-linux/fr-fr/cli_configuration-set_tsm.htm) pour plus d’informations.