Authentification de confiance
Lorsque vous intégrez des vues Tableau Server dans des pages Web, toutes les personnes qui consultent la page doivent être des utilisateurs sous licence sur Tableau Server. Lorsque des utilisateurs visitent la page, ils sont invités à se connecter à Tableau Server avant de pouvoir afficher la vue. Si vous possédez déjà un moyen d’authentifier les utilisateurs sur la page Web ou dans votre application Web, vous pouvez ignorer cette invite et éviter à vos utilisateurs de se connecter deux fois en configurant l’authentification de confiance.
L’authentification de confiance signifie simplement que vous avez établi une relation de confiance entre Tableau Server et un ou plusieurs serveurs Web. Lorsque Tableau Server reçoit des demandes de ces serveurs Web de confiance, il suppose que votre serveur Web a vérifié toutes les authentifications nécessaires.
Si votre serveur Web utilise SSPI (Security Support Provider Interface), vous n’avez pas besoin de configurer une authentification de confiance. Vous pouvez intégrer des vues et vos utilisateurs y auront accès sécurisé, car ils possèdent une licence Tableau Server et sont membres de votre Active Directory.
Remarque : les navigateurs des clients doivent être configurés pour autoriser les cookies de tiers si vous souhaitez utiliser l’authentification de confiance avec des vues intégrées.
Fonctionnement de l’authentification de confiance
La figure ci-dessous décrit le fonctionnement de l’authentification de confiance entre le navigateur Web du client, vos serveurs Web et Tableau Server.
L’utilisateur visite la page Web : lorsqu’un utilisateur visite la page Web avec la vue Tableau Server intégrée, il envoie une requête GET à votre serveur Web pour obtenir le contenu HTML de cette page.
Le serveur Web envoie des requêtes POST à Tableau Server : Le serveur Web envoie une requête POST au serveur de confiance de Tableau Server (par exemple, https://<server_name>/trusted et non https://<server_name>). Cette requête POST doit posséder un paramètre username. La valeur username doit correspondre au nom d’un utilisateur détenant une licence Tableau Server. Si Tableau Server exécute plusieurs sites et que la vue est publiée sur un site autre que le site Par défaut, la requête POST doit également contenir un paramètre target_site.
Tableau Server crée un ticket : Tableau Server vérifie l’adresse IP ou le nom d’hôte du serveur Web (192.168.1.XXX dans la figure ci-dessus) qui a envoyé la requête POST. Si le serveur Web est répertorié comme hôte de confiance, Tableau Server crée alors un ticket sous forme d’une chaîne unique à neuf chiffres. Les tickets doivent être échangés dans les trois minutes suivant leur émission. Tableau Server répond à la requête POST avec ce ticket. S’il y a une erreur et que le ticket ne peut être créé, Tableau Server répond avec la valeur -1. Le serveur doit avoir une adresse IPv4. Les adresses IPv6 ne sont pas prises en charge. Pour plus d’informations, consultez Renvoi de la valeur de ticket -1 depuis Tableau Server.
Le serveur Web transmet l’URL au navigateur : le serveur Web construit l’URL pour la vue et l’insère dans le code HTML de la page. Le ticket est inclus (par exemple https://<server_name>/trusted/<unique_ticket>/views/<view_name>). Le serveur Web transmet le code HTML de la page au navigateur Web du client.
Le navigateur demande la vue à Tableau Server : Le navigateur Web du client envoie une requête GET à Tableau Server, en incluant l’URL avec le ticket.
Tableau Server échange le ticket : Tableau Server échange le ticket, crée une session, connecte l’utilisateur, supprime le ticket de l’URL et envoie au client l’URL finale pour la vue intégrée.
La session permet à l’utilisateur d’accéder à l’une des vues dont il disposerait s’il avait ouvert une session sur le serveur. Dans la configuration par défaut, les utilisateurs authentifiés par des tickets de confiance disposent d’un accès restreint de sorte que seules les vues sont disponibles. Ils ne peuvent pas accéder aux classeurs, pages de projet ou autres contenus hébergés sur le serveur.
Pour modifier ce comportement, consultez l’option wgserver.unrestricted_ticket dans Options tsm configuration set.
Comment un ticket de confiance est-il stocké ?
Tableau Server stocke les tickets approuvés dans le référentiel Tableau Server au moyen du processus suivant :
- Tableau Server génère un ticket en deux parties : la première partie est un identificateur unique codé en Base64 (UUID) et la deuxième une chaîne secrète aléatoire de 24 caractères.
- Tableau Server hache la chaîne secrète et la stocke avec l’ID unique dans le référentiel. Le hachage se sert de la chaîne secrète comme entrée et utilise un algorithme pour calculer une chaîne unique. Cette chaîne unique protège la sécurité de la chaîne secrète des utilisateurs non autorisés.
- Tableau Server envoie l’UUID en Base64 et la chaîne aléatoire de 24 caractères au client.
- Le client renvoie l’UUID en Base64 et la chaîne secrète de 24 caractères d’origine à Tableau Server pour répondre à la demande de vue.
- Tableau Server localise la paire de chaînes avec l’UUID en Base64, puis hache la chaîne secrète pour vérifier qu’elle correspond au hachage stocké dans le référentiel.
Ce processus garantit que tout contenu de ticket sécurisé stocké sur Tableau Server ne peut pas être utilisé pour emprunter l’identité d’utilisateurs ou accéder au contenu protégé par l’authentification. Toutefois, étant donné que le ticket de confiance complet est envoyé par HTTP entre Tableau Server et le client, le processus repose sur une transmission sécurisée et cryptée de données HTTP. Par conséquent, nous vous recommandons de ne déployer que des tickets de confiance via SSL / TLS ou une autre couche de chiffrement réseau.