Aide de Tableau Server sur Linux

L’authentification vérifie l’identité d’un utilisateur. Tous ceux qui doivent disposer d’un accès à Tableau Server, que ce soit pour gérer le serveur, publier, explorer ou administrer du contenu, doivent être ajoutés en tant qu’utilisateurs dans le référentiel Tableau Server. La méthode d’authentification peut être effectuée par Tableau Server (« authentification locale »), ou l’authentification peut être effectuée par un processus externe. Dans ce dernier cas, vous devez configurer Tableau Server pour des technologies d’authentification externe telles que Kerberos, SAML ou OpenID. Dans tous les cas, que l’authentification se fasse de manière locale ou externe, chaque identité d’utilisateur doit être représentée dans le référentiel Tableau Server. Le référentiel gère les métadonnées d’autorisation pour les identités d’utilisateurs.

Vous recherchez Tableau Server sur Windows ? Consultez Authentification(Le lien s’ouvre dans une nouvelle fenêtre).

Bien que toutes les identités d’utilisateurs soient au bout du compte représentées et stockées dans le référentiel Tableau Server, vous devez gérer les comptes utilisateur pour Tableau Server dans un magasin d’identités. On distingue deux options de magasins d’identités mutuellement exclusives : LDAP et local. Tableau Server prend en charge les répertoires LDAP arbitraires, mais a été optimisé pour l’implémentation Active Directory LDAP. Alternativement, si vous n’exécutez pas un répertoire LDAP, vous pouvez utiliser le magasin d’identités local Tableau Server. Pour plus d’informations, consultez Magasin d’identités.

Comme montré sur la table suivante, le type de magasin d’identités que vous implémentez déterminera en partie vos options d’authentification.

Les autorisations d’accès et de gestion sont implémentées via des rôles sur le site. Les rôles sur le site définissent quels utilisateurs sont des administrateurs, et quels utilisateurs sont des consommateurs de contenu et effectuent des publications sur le serveur. Pour plus d’informations sur les administrateurs, rôles sur le site, groupes, utilisateur invité et tâches administratives liées aux utilisateurs, voir Utilisateurs et Rôles sur le site pour les utilisateurs.

Remarque : dans le contexte d’authentification, il est important de comprendre que les utilisateurs ne sont pas autorisés à accéder aux sources de données externes via Tableau Server du fait qu’ils possèdent un compte sur le serveur. En d’autres termes, dans la configuration par défaut, Tableau Server ne joue pas le rôle de proxy pour les sources de données externes. Un accès de ce type nécessite une configuration supplémentaire de la source de données sur Tableau Server ou l’authentification au niveau de la source de données lorsque l’utilisateur se connecte depuis Tableau Desktop.

Certaines méthodes d’authentification peuvent être utilisées ensemble. Le tableau suivant présente les méthodes d’authentification qui peuvent être combinées. Les cellules marquées d’un « X » indiquent un ensemble d’authentification compatible. Les cellules vides indiquent des ensembles d’authentification incompatibles.

* Les PAT, du fait de leur conception, ne fonctionnent pas directement avec le mécanisme d’authentification répertorié dans ces colonnes pour l’authentifier auprès de l’API REST. Au lieu de cela, les PAT utilisent les informations d’identification du compte utilisateur Tableau Server pour s’authentifier auprès de l’API REST.

* Kerberos SSO n’est pas pris en charge pour Android, mais un recours au nom d’utilisateur et au mot de passe est possible. Pour plus d’informations, consultez Remarque 5 : plate-forme Android.

** SSPI n’est pas compatible avec la version Workspace ONE de l’application Tableau Mobile.

*** Dans les workflows d’intégration uniquement.

Si le serveur est configuré pour utiliser l’authentification locale, Tableau Server authentifie les utilisateurs. Lorsque les utilisateurs se connectent et saisissent leurs informations d’identification, via Tableau Desktop, tabcmd, l’API ou un client Web, Tableau Server vérifie les informations d’identification.

Pour activer ce scénario, vous devez d’abord créer une identité pour chaque utilisateur. Pour créer une identité, vous spécifiez un nom d’utilisateur et un mot de passe. Pour accéder à un contenu sur le serveur ou interagir avec ce contenu, les utilisateurs doivent également se voir attribuer un rôle sur le site. Les identités de l’utilisateur peuvent être ajoutées à Tableau Server dans l’interface du serveur à l’aide de Commandes tabcmd ou de l’API REST(Le lien s’ouvre dans une nouvelle fenêtre).

Vous pouvez également créer des groupes dans Tableau Server pour vous aider à gérer et à attribuer des rôles à des ensembles importants de groupes d’utilisateurs connexes (par exemple "Marketing").

Lorsque vous configurez Tableau Server pour l’authentification locale, vous pouvez définir des stratégies de mot de passe et configurer le verrouillage des comptes en cas de tentatives de mot de passe infructueuses. Consultez Authentification locale.

Remarque : Tableau avec authentification multifacteur (MFA) est disponible uniquement pour Tableau Cloud.

Tableau Server peut être configuré pour utiliser diverses solutions d’authentification externe.

Vous pouvez configurer Tableau Server en vue de l’utilisation de Kerberos pour Active Directory. Consultez Kerberos.

Vous pouvez configurer Tableau Server de manière à utiliser l’authentification SAML (Security Assertion Markup Language). Avec SAML, un fournisseur d’identité externe (IdP) authentifie les informations d’authentification de l’utilisateur et envoie une assertion de sécurité à Tableau Server qui fournit des informations sur l’identité de l’utilisateur.

Pour plus d’informations, consultez SAML.

OpenID Connect (OIDC) est un protocole d’authentification standard qui permet aux utilisateurs de s’authentifier auprès d’un fournisseur d’identité (IdP) tel que Google. Après s’être correctement authentifiés auprès de leur IdP, ils sont automatiquement authentifiés auprès de Tableau Server. Pour utiliser OIDC sur Tableau Server, le serveur doit être configuré pour utiliser le magasin d’identités local. Les magasins d’identités Active Directory ou LDAP ne sont pas pris en charge avec OIDC. Pour plus d’informations, voir OpenID Connect.

À l’aide de SSL mutuel, vous pouvez fournir aux utilisateurs de Tableau Desktop, Tableau Mobile, et autres clients Tableau approuvés une expérience d’accès direct sécurisé à Tableau Server. Avec SSL mutuel, lorsqu’un client possédant un certificat SSL valide se connecte à Tableau Server, Tableau Server confirme l’existence du certificat client et authentifie l’utilisateur, d’après le nom d’utilisateur figurant sur le certificat client. Si le client ne possède pas un certificat SSL valide, Tableau Server peut refuser la connexion. Pour plus d’informations, consultez Configurer l’authentification SSL mutuel.

Approbation directe

Les applications connectées à Tableau permettent une expérience d’authentification transparente et sécurisée en facilitant une relation de confiance explicite entre votre site Tableau Server et les applications externes dans lesquelles le contenu Tableau est intégré. L’utilisation d’applications connectées permet également d’autoriser, par programmation, l’accès à l’API REST de Tableau à l’aide de jetons Web JSON (JWT). Pour plus d’informations, consultez Utiliser les applications connectées à Tableau pour l’intégration d’applications.

Approbation EAS ou OAuth 2.0

Vous pouvez enregistrer un serveur d’autorisation externe (EAS) avec Tableau Server pour établir une relation de confiance entre votre Tableau Server et EAS en utilisant le protocole de la norme OAuth 2.0. La relation de confiance offre à vos utilisateurs une expérience d’authentification unique, via votre IdP, pour accéder au contenu Tableau intégré. De plus, l’enregistrement d’un EAS permet d’autoriser, par programmation, l’accès à l’API REST de Tableau à l’aide de jetons Web JSON (JWT). Pour plus d’informations, consultez Configurer les applications connectées avec la confiance OAuth 2.0.

L’authentification de confiance (également appelée « Tickets de confiance ») vous permet de configurer une relation de confiance entre Tableau Server et un ou plusieurs serveurs Web. Lorsque Tableau Server reçoit des demandes d’un serveur Web de confiance, il suppose que le serveur Web a vérifié toutes les authentifications nécessaires. Tableau Server reçoit la demande avec un jeton ou ticket échangeable, et offre à l’utilisateur une vue personnalisée qui prend en compte son rôle et ses autorisations. Pour plus d’informations, consultez Authentification de confiance.

Vous pouvez également configurer Tableau Server de manière à ce qu’il utilise LDAP pour l’authentification utilisateur. Les utilisateurs sont authentifiés en soumettant leurs informations d’identification à Tableau Server, qui tente ensuite d’effectuer la liaison à l’instance LDAP à l’aide des informations d’identification de l’utilisateur. Si la liaison fonctionne, les informations d’identification sont valides et Tableau Server accorde une session à l’utilisateur.

Une « liaison » est l’étape de poignée de main/d’authentification qui a lieu lorsqu’un client tente d’accéder à un serveur LDAP. Tableau Server effectue cette opération pour lui-même lorsqu’il émet diverses requêtes de non-authentification associées (par exemple l’importation d’utilisateurs et de groupes).

Vous pouvez configurer le type de liaison que Tableau Server doit utiliser lorsque vous vérifiez les informations d’identification de l’utilisateur. Tableau Server prend en charge GSSAPI et la liaison simple. La liaison simple transmet les informations d’identification directement à l’instance LDAP. Nous vous recommandons de configurer SSL pour crypter la communication de liaison. L’authentification dans ce scénario peut être fournie par la solution LDAP native ou avec un processus externe, par exemple SAML.

Pour des informations sur la planification et la configuration de LDAP, consultez Magasin d’identités et Référence de configuration du magasin d’identités externe.

• API REST : Connexion et déconnexion (Authentification)(Le lien s’ouvre dans une nouvelle fenêtre)

  Remarque : l’API REST et tabcmd ne prennent pas en charge l’authentification unique (SSO) SAML.

• Authentification des appareils mobiles : Authentification unique pour Tableau Mobile(Le lien s’ouvre dans une nouvelle fenêtre)

• Certificat de confiance pour les clients TSM : Connexion des clients TSM

• Intégration PAM pour l’administration TSM : Authentification TSM

Vous pouvez configurer Tableau Server de manière à ce qu’il prenne en charge plusieurs protocoles d’authentification différents sur plusieurs sources de données différentes. L’authentification de la connexion de données peut être indépendante de l’authentification Tableau Server.

Par exemple, vous pouvez configurer l’authentification utilisateur pour Tableau Server avec l’authentification locale, tout en configurant l’authentification OAuth ou SAML pour des sources de données spécifiques. Consultez Authentification de la connexion de données.

Autres articles de cette section