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(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 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(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 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 Présentation de l’authentification.

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 <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 Présentation de l’authentification, 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.

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

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 <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 !Avis correctement envoyé. Merci