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(Le lien s’ouvre dans une nouvelle fenêtre) à 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(Le lien s’ouvre dans une nouvelle fenêtre), 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.

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 <commandes>.

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

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 <commandes>.

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 <commandes>.

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 pour plus d’informations.

Merci de vos commentaires!Votre commentaire s été envoyé avec succès. Merci!