Partie 5 - Configuration du niveau Web

Le niveau Web de l’architecture de référence doit inclure les composants suivants :

  • Un équilibreur de charge d’application Web qui accepte les requêtes HTTPS des clients Tableau et communique avec les serveurs proxy inverses.
  • Serveur proxy inverse : 
    • Nous vous recommandons de déployer la passerelle indépendante de Tableau Server.
    • Nous recommandons un minimum de deux serveurs proxy pour la redondance et pour gérer la charge client.
    • Reçoit le trafic HTTPS de l’équilibreur de charge.
    • Prend en charge la session persistante vers l’hôte Tableau.
    • Configurez le proxy pour l’équilibrage de charge à tour de rôle sur chaque Tableau Server exécutant le processus de passerelle.
    • Gère les demandes d’authentification du fournisseur d’identités externe.
  • Proxy de transfert : Tableau Server a besoin d’un accès à Internet pour les licences et les fonctionnalités de carte. Vous devez configurer des listes d’autorisations de proxy de transfert pour les URL de service Tableau. Voir Communication avec Internet (Linux(Le lien s’ouvre dans une nouvelle fenêtre)).
  • Tout le trafic lié au client peut être chiffré via https:
    • Équilibreur de charge de client vers application
    • Équilibreur de charge d’application vers serveurs proxy inverses
    • Serveur proxy vers Tableau Server
    • Gestionnaire d’authentification s’exécutant sur le proxy inverse vers le fournisseur d’identités
    • Tableau Server vers le fournisseur d’identités

Passerelle indépendante Tableau Server

Tableau Server version 2022.1 a introduit la passerelle indépendante Tableau Server. La passerelle indépendante est une instance autonome du processus du serveur Tableau Gateway qui agit comme un serveur proxy inverse compatible avec Tableau.

La passerelle indépendante prend en charge l’équilibrage de charge circulaire simple vers les serveurs Tableau Server principaux. Cependant, la passerelle indépendante n’est pas destiné à servir d’équilibreur de charge d’application d’entreprise. Nous vous recommandons d’exécuter la passerelle indépendante derrière un équilibreur de charge d’application d’entreprise.

La passerelle indépendante nécessite une licence de Advanced Management.

Authentification et autorisation

L’architecture de référence par défaut spécifie l’installation de Tableau Server en configurant l’authentification au niveau local. Dans ce modèle, les clients doivent se connecter à Tableau Server de manière à être authentifiés par le processus d’authentification local natif de Tableau Server. Nous vous déconseillons d’utiliser cette méthode d’authentification dans l’architecture de référence, car le scénario exige que des clients non authentifiés communiquent avec le niveau Application, ce qui constitue un risque pour la sécurité.

Nous vous recommandons plutôt de configurer un fournisseur d’identités externe de niveau entreprise couplé à un module AuthN de manière à pré-authentifier tout le trafic vers le niveau Application. Lorsqu’il est configuré avec un fournisseur d’identités externe, le processus d’authentification local natif de Tableau Server n’est pas utilisé. Tableau Server autorise l’accès aux ressources du déploiement une fois que le fournisseur d’identités a authentifié les utilisateurs.

Pré-authentification avec un module AuthN

Dans l’exemple documenté dans ce guide, l’authentification unique SAML est configurée, mais le processus de pré-authentification peut être configuré avec la plupart des fournisseurs d’identités externes et un module AuthN.

Dans l’architecture de référence, le serveur proxy inverse est configuré de manière à créer une session d’authentification client avec le fournisseur d’identités avant de transmettre ces demandes par proxy à Tableau Server. Nous appelons ce processus la phase de pré-authentification. Le proxy inverse redirige vers Tableau Server uniquement les sessions cliente authentifiées. Tableau Server crée ensuite une session, vérifie l’authentification de la session avec le fournisseur d’identités, puis renvoie la demande du client.

Le schéma suivant montre la procédure étape par étape du processus de pré-authentification et d’authentification avec un module AuthN. Le proxy inverse peut être une solution tierce générique ou la passerelle indépendante de Tableau Server :

Étapes indiquées dans le schéma ci-dessus. Étape 1 : le client Tableau demande une ressource sur Tableau Server. Étape 2 : le serveur proxy inverse crée une demande d’authentification en redirigeant l’URL vers le fournisseur d’identités. Étape 3 : le fournisseur d’identités envoie un formulaire de connexion à l’utilisateur. Étape 4 : l’utilisateur est invité et saisit les identifiants. Étape 5 : le fournisseur d’identités vérifie les identifiants soumis par l’utilisateur. Étape 6 : le fournisseur d’identités répond au client avec l’assertion SAML intégrée qui est envoyée au fournisseur de services du serveur proxy inverse. Étape 7 : le fournisseur de services sur le serveur proxy valide l’assertion, crée une session, puis redirige vers le fournisseur de services sur Tableau Server. Étape 8 : le fournisseur de services sur Tableau Server crée la demande d’authentification auprès du fournisseur d’identités. Étape 9 : le fournisseur d’identités valide la session en cours. Étape 10 : le fournisseur de service sur Tableau Server valide et crée sa propre session et envoie la réponse à l’utilisateur. Étape 11 : l’utilisateur se connecte à Tableau Server pour obtenir l’autorisation à la ressource spécifiée.

Présentation de la configuration

Cette section présente le processus de configuration du niveau Web. Vérifiez la connectivité après chaque étape :

  1. Configurez deux serveurs proxy inverses pour fournir un accès HTTP à Tableau Server.
  2. Configurez la logique d’équilibrage de charge avec des sessions persistantes sur les serveurs proxy pour vous connecter à chaque instance de Tableau Server exécutant le processus de passerelle.
  3. Configurez l’équilibrage de charge des applications avec des sessions persistantes au niveau de la passerelle Internet pour transférer les demandes aux serveurs proxy inverses.
  4. Configurez l’authentification avec un fournisseur d’identités externe. Vous pouvez configurer l’authentification SSO ou SAML en installant un gestionnaire d’authentification sur les serveurs proxy inverses. Le module AuthN gère la négociation d’authentification entre le fournisseur d’identités externe et votre déploiement Tableau. Tableau agira également en tant que fournisseur de services IdP et authentifiera les utilisateurs avec le fournisseur d’identités.
  5. Pour s’authentifier avec Tableau Desktop dans ce déploiement, vos clients doivent exécuter Tableau Desktop 2021.2.1 ou une version ultérieure.

Exemple de configuration de niveau Web avec passerelle indépendante de Tableau Server

Le reste de cette rubrique présente une procédure de bout en bout qui décrit comment implémenter un niveau Web dans l’exemple d’architecture AWS de référence à l’aide de la passerelle indépendante de Tableau Server. Pour un exemple de configuration utilisant Apache comme proxy inverse, consultez Annexe - Niveau Web avec exemple de déploiement Apache.

L’exemple de configuration est composé des composants suivants :

  • Équilibreur de charge d’application AWS
  • Passerelle indépendante Tableau Server
  • Module d’authentification Mellon
  • Fournisseur d’identités Okta
  • Authentification SAML

Remarque : l’exemple de configuration de niveau Web présenté dans cette section comprend des procédures détaillées pour le déploiement de logiciels et de services tiers. Nous avons tout mis en œuvre pour vérifier et documenter les procédures permettant d’activer le scénario de niveau Web. Il peut toutefois arriver que le logiciel tiers change ou que votre scénario diffère de l’architecture de référence décrite ici. Veuillez vous référer à la documentation du fournisseur tiers pour les détails de configuration et l’assistance.

Les exemples Linux tout au long de cette section montrent des commandes pour les distributions de type RHEL. Plus précisément, les commandes présentées ici ont été développées avec la distribution Amazon Linux 2. Si vous exécutez une distribution Ubuntu, modifiez les commandes en conséquence.

Le déploiement du niveau Web dans cet exemple suit une procédure de configuration et de vérification par étapes. La configuration du niveau Web principal comprend les étapes suivantes pour activer HTTP entre Tableau et Internet. La passerelle indépendante est exécutée et configurée pour un proxy inverse/équilibrage de charge derrière l’équilibrage de charge d’application AWS :

  1. Préparer l’environnement
  2. Installer la passerelle indépendante
  3. Configurer le serveur de passerelle indépendante
  4. Configurez l’équilibreur de charge d’application AWS

Une fois que vous avez configuré le niveau Web et vérifié la connectivité avec Tableau, configurez l’authentification avec un fournisseur externe.

Préparer l’environnement

Effectuez les tâches suivantes avant de déployer la passerelle indépendante.

  1. Modifications du groupe de sécurité AWS. Configurez le groupe de sécurité public pour autoriser le trafic entrant de gestion interne de la passerelle indépendante (TCP 21319) à partir du groupe de sécurité privé.

  2. Installez la version 22.1.1 (ou ultérieure) sur un cluster Tableau Server à quatre nœuds comme documenté dans Partie 4 - Installer et configurer Tableau Server.

  3. Configurez les deux instances EC2 du mandataire dans le groupe de sécurité publique comme indiqué dans Configurer les ordinateurs hôtes.

Installer la passerelle indépendante

La passerelle indépendante de Tableau Server nécessite une licence de Advanced Management.

Le déploiement de la passerelle indépendante de Tableau Server consiste à installer et à exécuter le package .rpm, puis à configurer l’état initial. La procédure incluse dans ce guide fournit des conseils prescriptifs pour le déploiement dans l’architecture de référence.

Si votre déploiement diffère de l’architecture de référence, consultez la documentation principale de Tableau Server, Installer Tableau Server avec une passerelle indépendante (Linux(Le lien s’ouvre dans une nouvelle fenêtre)).

Important : La configuration de la passerelle indépendante peut être un processus propice aux erreurs. Il est très difficile de résoudre les problèmes de configuration sur deux instances de serveurs de passerelle indépendante. Pour cette raison, nous vous recommandons de configurer un serveur de passerelle indépendante à la fois. Après avoir configuré le premier serveur et vérifié la fonctionnalité, vous devez ensuite configurer le deuxième serveur de passerelle indépendante.

Même si vous allez configurer chaque serveur de passerelle indépendante séparément, exécutez cette procédure d’installation sur les deux instances EC2 que vous avez installées dans le groupe de sécurité public : 

  1. Exécutez la mise à jour pour appliquer les derniers correctifs au système d’exploitation Linux :

    sudo yum update

  2. Si Apache a été installé, supprimez-le :

     sudo yum remove httpd
  3. Copiez le package d’installation de la passerelle indépendante version 2022.1.1 (ou version ultérieure) depuis la page Téléchargement Tableau(Le lien s’ouvre dans une nouvelle fenêtre) sur l’ordinateur hôte qui exécutera Tableau Server.

    Par exemple, sur un ordinateur fonctionnant sur un système d’exploitation Linux de type RHEL, exécutez

    wget https://downloads.tableau.com/esdalt/2022<version>/tableau-server-tsig-<version>.x86_64.rpm

  4. Exécutez le programme d’installation. Par exemple, sur un système d’exploitation Linux de type RHEL, exécutez :

    sudo yum install <tableau-tsig-version>.x86_64.rpm

  5. Passez au répertoire /opt/tableau/tableau_tsig/packages/scripts.<version_code>/ et exécutez le script initialize-tsig qui s’y trouve. En plus de l’indicateur --accepteula, vous devez inclure la plage d’adresses IP des sous-réseaux sur lesquels le déploiement de Tableau Server est en cours d’exécution. Utilisez l’option -c pour spécifier la plage IP. L’exemple ci-dessous montre la commande avec les exemples de sous-réseaux AWS spécifiés :

    sudo ./initialize-tsig --accepteula -c "ip 10.0.30.0/24 10.0.31.0/24"

  6. Une fois l’initialisation terminée, ouvrez le fichier tsighk-auth.conf et copiez le secret d’authentification dans le fichier. Vous devrez soumettre ce code pour chaque instance de passerelle indépendante dans le cadre de la configuration principale de Tableau Server :

    sudo less /var/opt/tableau/tableau_tsig/config/tsighk-auth.conf

  7. Après avoir exécuté les étapes précédentes sur les deux instances de la passerelle indépendante, préparez le fichier de configuration tsig.json. Le fichier de configuration consiste en un tableau « independentGateways ». Le tableau contient des objets de configuration qui définissent chacun les détails de connexion pour une instance de passerelle indépendante.

    Copiez le JSON suivant et personnalisez-le en fonction de votre environnement de déploiement. L’exemple ici montre un fichier comme exemple d’architecture de référence AWS.

    L'exemple de fichier JSON ci-dessous inclut uniquement l’information de connexion d’une seule passerelle indépendante. Plus tard dans le processus, vous inclurez l’information de connexion du deuxième serveur de passerelle indépendante.

    Enregistrez le fichier sous tsig.json pour les procédures qui suivent.

    {
    "independentGateways": [
     {
     	"id": "ip-10-0-1-169.ec2.internal",
     	"host": "ip-10-0-1-169.ec2.internal",
     	"port": "21319",
     	"protocol" : "http",
     	"authsecret": "13660-27118-29070-25482-9518-22453"
     	}]
     }

    • "id" - Le nom DNS privé de l’instance AWS EC2 exécutant la passerelle indépendante.
    • "host"- identique à "id" .
    • "port"- Le port de maintenance, par défaut, "21319".
    • "protocol"- Le protocole pour le trafic client. Conservez http pour la configuration initiale.
    • "authsecret"- Le secret que vous avez copié à l’étape précédente.

Passerelle indépendante : connexion directe contre par relais

Avant de continuer, vous devez décider du schéma de connexion à configurer dans votre déploiement : connexion directe ou par relais. Chaque option est brièvement décrite ici, ainsi que les points de données de décision pertinents.

Connexion par relais : vous pouvez configurer la passerelle indépendante de manière à relayer la communication du client sur un seul port vers le processus de passerelle sur Tableau Server. Dans ce document, nous parlons de connexion par relais :

  • Le processus par relais entraîne un saut supplémentaire de la passerelle indépendante vers le processus principal de la passerelle Tableau Server. Le saut supplémentaire dégrade les performances par rapport à la configuration de connexion directe.
  • TLS est pris en charge pour le mode relais. Toutes les communications en mode relais sont limitées à un seul protocole (HTTP ou HTTPS) et peuvent donc être chiffrées et authentifiées avec TLS.

Connexion directe : la passerelle indépendante peut communiquer directement avec les processus principaux de Tableau Server sur plusieurs ports. Dans ce document, nous parlons de connexion directe :

  • Étant donné que la connexion est directe à l’instance principale de Tableau Server, les performances du client sont nettement améliorées par rapport à l’option de connexion par relais.
  • Nécessite l’ouverture de plus de 16 ports des sous-réseaux publics aux sous-réseaux privés pour une communication de processus directe de la passerelle indépendante aux ordinateurs Tableau Server.
  • TLS n’est pas encore pris en charge sur les processus de la passerelle indépendante vers Tableau Server.

Pour exécuter TSL entre Tableau Server et la passerelle indépendante, vous devez configurer une connexion par relais. Les exemples de scénarios décrits dans le guide EDG sont configurés grâce à une connexion par relais.

  1. Copiez tsig.json sur le nœud 1 de votre déploiement Tableau Server.

  2. Sur le nœud 1, exécutez les commandes suivantes pour activer la passerelle indépendante.

    tsm stop
    tsm configuration set -k gateway.tsig.proxy_tls_optional -v none
    tsm pending-changes apply
    tsm topology external-services gateway enable -c tsig.json
    tsm start

La connexion en direct ne prenant pas en charge TLS, nous vous recommandons de configurer la connexion en direct uniquement si vous pouvez sécuriser tout le trafic réseau par d’autres moyens. Pour exécuter TSL entre Tableau Server et la passerelle indépendante, vous devez configurer une connexion par relais. Les exemples de scénarios décrits dans le guide EDG sont configurés grâce à une connexion par relais.

Si vous configurez la passerelle indépendante pour une connexion directe à Tableau Server, vous devez activer la configuration pour déclencher la communication. Une fois que Tableau Server communique avec la passerelle indépendante, les cibles de protocole sont établies. Vous devez ensuite récupérer le fichier proxy_targets.csv sur l’ordinateur de la passerelle indépendante et ouvrir les ports correspondants des groupes de sécurité Public vers Privé dans AWS.

  1. Copiez tsig.json sur le nœud 1 de votre déploiement Tableau Server.

  2. Sur le nœud 1, exécutez les commandes suivantes pour activer la passerelle indépendante.

    tsm stop
    tsm topology external-services gateway enable -c tsig.json
    tsm start
  3. Sur l’ordinateur de la passerelle indépendante, exécutez la commande suivante pour afficher les ports utilisés par le cluster Tableau Server :

    less /var/opt/tableau/tableau_tsig/config/httpd/proxy_targets.csv
  4. Configurez les groupes de sécurité AWS. Ajoutez les ports TCP répertoriés dans proxy_targets.csv pour autoriser la communication entre le groupe de sécurité Public et le groupe de sécurité Privé.

    Nous recommandons d’automatiser la configuration des entrées de ports car les ports peuvent changer si le déploiement de Tableau Server change. L’ajout de nœuds ou la reconfiguration des processus lors du déploiement de Tableau Server déclenchera des modifications de l’accès aux ports requis par la passerelle indépendante.

Vérification : configuration de la topologie de base

Vous devriez pouvoir accéder à la page d’administration de Tableau Server en accédant à http://<gateway-public-IP-address>.

Si la page de connexion à Tableau Server ne se charge pas, ou si Tableau Server ne démarre pas, suivez les étapes de dépannage ci-après :

Réseau : 

  • Vérifiez la connectivité entre le déploiement Tableau et l’instance de la passerelle indépendante en exécutant la commande wget à partir du nœud1 Tableau Server : wget http://<internal IP address of Independent Gateway>:21319, par exemple :

     wget http://ip-10-0-1-38:21319

    Si la connexion n’est pas établie ou si elle échoue, vérifiez que le groupe de sécurité Public est configuré pour autoriser le trafic de maintenance de la passerelle indépendante (TCP 21319) provenant du groupe de sécurité Privé.

    Si le groupe de sécurité est configuré correctement, vérifiez alors que vous avez indiqué les adresses IP ou les plages d’adresses IP correctes lors du lancement de la passerelle indépendante. Vous pouvez afficher et modifier cette configuration dans le fichier environment.bash situé dans /etc/opt/tableau/tableau_tsig/environment.bash. Si vous apportez une modification à ce fichier, redémarrez le service tsig-http en suivant les étapes décrites ci-dessous.

Sur l’hôte Proxy 1 :

  1. Remplacez le fichier httpd.conf par le fichier de remplacement de la passerelle indépendante :

    cp /var/opt/tableau/tableau_tsig/config/httpd.conf.stub /var/opt/tableau/tableau_tsig/config/httpd.conf
  2. Redémarrez tsig-httpd comme première étape de dépannage :
    sudo su - tableau-tsig
    systemctl --user restart tsig-httpd
    exit

Sur le nœud 1 Tableau

  • Revérifiez le fichier tsig.json. Si vous trouvez des erreurs, corrigez-les, puis exécutez tsm topology external-services gateway update -c tsig.json .
  • Si vous exécutez une connexion directe, vérifiez que les ports TCP répertoriés dans proxy_targets.csv sont configurés en tant que ports d’entrée des groupes de sécurité Public vers Privé.

Configurer l’équilibreur de charge d’application AWS

Configurez l’équilibreur de charge en tant qu’écouteur HTTP. La procédure ici décrit comment ajouter un équilibreur de charge dans AWS.

Étape 1 : Créer un groupe cible

Un groupe cible est une configuration AWS qui définit les instances EC2 exécutant vos serveurs proxy. Ce sont les cibles pour le trafic provenant du LBS.

  1. EC2>Groupes cibles > Créer un groupe cible

  2. Sur la page Créer :

    • Entrez un nom de groupe cible, par exemple TG-internal-HTTP
    • Type de cible : Instances
    • Protocole : HTTP
    • Port : 80
    • VPC : Sélectionnez votre VPC
    • Sous Contrôles d’intégrité > Paramètres avancés des contrôles d’intégrité > Codes de réussite, ajoutez la liste des codes pour lire : 200,303.
    • Cliquez sur Créer
  3. Sélectionnez le groupe cible que vous venez de créer, puis cliquez sur l’onglet Cibles

    • Cliquez sur Modifier.
    • Sélectionnez les instances d’EC2 (ou une seule instance si vous en configurez une à la fois) qui exécutent l’application proxy, puis cliquez sur Ajouter à l’enregistrement.
    • Cliquez sur Enregistrer.

Étape 2 : Lancer l’assistant d’équilibrage de charge

  1. EC2 > Équilibreurs de charge > Créer un équilibreur de charge

  2. Sur la page « Sélectionner le type d’équilibreur de charge », créez un équilibreur de charge d’application.

Remarque : l’interface utilisateur qui s’affiche pour configurer l’équilibreur de charge peut présenter des différences selon les centres de données AWS. La procédure ci-dessous, « Configuration de l’assistant », correspond à l’assistant de configuration AWS qui commence par l’Étape 1 Configurer l’équilibreur de charge

Si votre centre de données affiche toutes les configurations sur une seule page qui inclut un bouton Créer un équilibreur de charge en bas de la page, suivez la procédure « Configuration d’une seule page » ci-dessous.

  1. Page Configurer l’équilibreur de charge :

    • Précisez le nom
    • Schéma : face à Internet (par défaut)
    • Type d’adresse IP : ipv4 (par défaut)
    • Écouteurs (écouteurs et routage) :
      1. Laissez l’écouteur HTTP par défaut
      2. Cliquez sur Ajouter un écouteur et ajoutez HTTPS:443
    • VPC : sélectionnez le VPC où vous avez tout installé
    • Zones de disponibilité :
      • Sélectionnez a et b comme vos régions de centre de données
      • Dans chaque liste de sélection déroulante correspondante, sélectionnez le sous-réseau Public (où résident vos serveurs proxy).
    • Cliquez sur : Configurer les paramètres de sécurité
  2. Page Configurer les paramètres de sécurité

    • Téléversez votre certificat SSL public.
    • Cliquez sur Suivant : Configurer des groupes de sécurité.
  3. Page Configurer les groupes de sécurité :

    • Sélectionnez le groupe de sécurité Public. Si le groupe de sécurité par défaut est sélectionné, effacez cette sélection.
    • Cliquez sur Suivant : Configurer le routage.
  4. Page Configurer le routage

    • Groupe cible : Groupe cible existant.
    • Nom : sélectionnez le groupe cible que vous avez créé précédemment
    • Cliquez sur Suivant : Enregistrer les cibles.
  5. Page Enregistrer les cibles

    • Les deux instances de serveur proxy que vous avez configurées précédemment doivent s’afficher.
    • Cliquez sur Suivant : Vérifier.
  6. Page Révision

    Cliquez sur Créer.

Configuration de base

  • Précisez le nom
  • Schéma : face à Internet (par défaut)
  • Type d’adresse IP : ipv4 (par défaut)

Mappages réseau

  • VPC : sélectionnez le VPC où vous avez tout installé
  • Mappages :
    • Sélectionnez les zones de disponibilité a et b (ou comparables) comme vos régions de centres de données
    • Dans chaque liste de sélection déroulante correspondante, sélectionnez le sous-réseau Public (où résident vos serveurs proxy).

Groupes de sécurité

  • Sélectionnez le groupe de sécurité Public. Si le groupe de sécurité par défaut est sélectionné, effacez cette sélection.
  • Écouteurs et routage

    • Laissez l’écouteur HTTP par défaut. Dans Action par défaut, spécifiez le groupe cible que vous avez précédemment configuré.
    • Cliquez sur Ajouter un écouteur et ajoutez HTTPS:443. Dans Action par défaut, spécifiez le groupe cible que vous avez précédemment configuré.

    Paramètres d’écoute sécurisés

    • Téléversez votre certificat SSL public.

    Cliquez sur Créer un équilibreur de charge.

    Étape 3 : Activer la persistance

    1. Une fois l’équilibreur de charge créé, vous devez activer la persistance sur le groupe cible.

      • Ouvrez la page Groupe cible AWS (EC2> Équilibreurs de charge> Groupes cibles), sélectionnez l’instance d’équilibreur de charge cible que vous venez de configurer. Dans le menu Actions, sélectionnez Modifier les attributs.
      • Sur la page Modifier les attributs, sélectionnez Persistance, spécifiez une durée 1 day, puis Enregistrer les modifications.
    2. Dans l’équilibreur de charge, activez la persistance sur l’écouteur HTTP. Sélectionnez l’équilibreur de charge que vous venez de configurer, puis cliquez sur l’onglet Écouteurs.

      • Pour http:80, cliquez sur Afficher/modifier les règles. Dans la page Règles résultante, cliquez sur l’icône de modification (une fois en haut de la page, puis à nouveau près de la règle) pour modifier la règle. Supprimez la règle THEN existante et remplacez-la en cliquant sur Ajouter une action > Transférer vers.... Dans la configuration THEN résultante, spécifiez le même groupe cible que vous avez créé. Sous Persistance au niveau du groupe, activez la persistance et définissez la durée sur 1 jour. Enregistrez le paramètre, puis cliquez sur Mettre à jour.

    Étape 4 : Définir le délai d’inactivité sur l’équilibreur de charge

    Sur l’équilibreur de charge, mettez à jour le délai d’inactivité à 400 secondes.

    Sélectionnez l’équilibreur de charge que vous avez configuré pour ce déploiement, puis cliquez sur Actions > Modifier les attributs. Définissez le délai d’inactivité sur 400 secondes, puis cliquez sur Enregistrer.

    Étape 5 : Vérifier la connectivité LBS

    Ouvrez la page de l’équilibreur de charge AWS (EC2> Équilibreurs de charge), puis sélectionnez l’instance d’équilibreur de charge que vous venez de configurer.

    Sous Description, copiez le nom DNS et collez-le dans un navigateur pour accéder à la page de connexion Tableau Server.

    Si vous obtenez une erreur de niveau 500, vous devrez probablement redémarrer vos serveurs proxy.

    Mettre à jour le DNS avec l’URL publique de Tableau

    Utilisez le nom de zone DNS de votre domaine dans la description de l’équilibreur de charge AWS pour créer une valeur CNAME dans votre DNS. Le trafic vers votre URL (tableau.example.com) doit être envoyé au nom DNS public AWS.

    Vérifier la connectivité

    Une fois vos mises à jour DNS terminées, vous devriez pouvoir accéder à la page de connexion Tableau Server en saisissant votre URL publique, par exemple https://tableau.example.com.

    Exemple de configuration d’authentification : SAML avec fournisseur d’identités externe

    L’exemple suivant décrit comment installer et configurer SAML avec un fournisseur d’identités Okta et un module d’authentification Mellon pour un déploiement Tableau exécuté dans l’architecture de référence AWS.

    Cet exemple s’inspire de la section précédente et suppose que vous configurez une passerelle indépendante à la fois.

    L’exemple décrit comment configurer Tableau Server et la passerelle indépendante sur HTTP. Okta enverra la demande à l’équilibreur de charge AWS via HTTPS, mais tout le trafic interne transitera via HTTP. Lors de la configuration de ce scénario, tenez compte des protocoles HTTP et HTTPS lors de la définition des chaînes d’URL.

    Cet exemple utilise Mellon comme module de fournisseur de services de pré-authentification sur les serveurs de la passerelle indépendante. Cette configuration garantit que seul le trafic authentifié se connecte à Tableau Server, qui fait également office de fournisseur de services avec le fournisseur d’identités Okta. Par conséquent, vous devez configurer deux applications de fournisseur d’identités : une pour le fournisseur de services Mellon et une pour le fournisseur de services Tableau.

    Créer un compte d’administrateur Tableau

    Une erreur courante lors de la configuration de SAML est d’oublier de créer un compte administrateur sur Tableau Server avant d’activer l’authentification unique.

    La première étape consiste à créer un compte sur Tableau Server avec un rôle d’administrateur de serveur. Pour le scénario de l’exemple Okta, le nom d’utilisateur doit utiliser le format d’une adresse de courriel valide, par exemple user@example.com. Vous devez définir un mot de passe pour cet utilisateur, mais le mot de passe ne sera pas utilisé une fois SAML configuré.

    Configurer l’application de pré-authentification Okta

    Le scénario de bout en bout décrit dans cette section nécessite deux applications Okta :

    • Demande de pré-autorisation Okta
    • Application Okta Tableau Server

    Chacune de ces applications est associée à différentes métadonnées que vous devrez configurer sur le serveur proxy inverse et Tableau Server, respectivement.

    Cette procédure décrit comment créer et configurer l’application de pré-authentification Okta. Plus loin dans cette rubrique, vous créerez l’application Okta Tableau Server. Pour un test gratuit de compte Okta avec un nombre limité d’utilisateurs, consultez la page Web Okta Developer(Le lien s’ouvre dans une nouvelle fenêtre).

    Créez une intégration d’application SAML pour le fournisseur de services de pré-authentification Mellon.

    1. Ouvrez le tableau de bord d’administration d’Okta > Applications > Créer une intégration d’application.

    2. Dans la page Créer une nouvelle intégration d’application, sélectionnez SAML 2.0, puis cliquez sur Suivant.

    3. Dans l’onglet Paramètres généraux, saisissez un nom d’application, par exemple Tableau Pre-Auth, puis cliquez sur Suivant.

    4. Dans l’onglet Configurer SAML :

      • URL d’authentification unique (SSO). Le dernier élément du chemin dans l’URL d’authentification unique est appelé MellonEndpointPath dans le fichier de configuration mellon.conf présenté plus loin dans cette procédure. Vous pouvez spécifier le point de terminaison de votre choix. Dans cet exemple, sso est le point de terminaison. Le dernier élément, postResponse, est requis : https://tableau.example.com/sso/postResponse.
      • Décochez la case : Use this for Recipient URL and Destination URL (À utiliser comme URL du destinataire et URL de destination).
      • URL du destinataire : identique à l’URL SSO, mais avec HTTP. Par exemple, http://tableau.example.com/sso/postResponse.
      • URL de destination : identique à l’URL SSO, mais avec HTTP. Par exemple, http://tableau.example.com/sso/postResponse.
      • URI d’audience (ID d’entité SP). Par exemple, https://tableau.example.com.
      • Format d’identification du nom : EmailAddress
      • Nom d’utilisateur de l’application : Email
      • Déclarations d’attributs : Nom =mail; Format du nom = Unspecified; Valeur = user.email.

      Cliquez sur Suivant.

    5. Dans l’onglet Commentaires, sélectionnez :

      • Je suis un client Okta ajoutant une application interne
      • Il s’agit d’une application interne que nous avons créée
      • Cliquez sur Terminer.
    6. Créez le fichier de métadonnées IdP de pré-autorisation :

      • Dans Okta : Applications > Applications > Votre nouvelle application (par exemple Tableau Pre-Auth ) > Connexion
      • À côté de Certificats de signature SAML, cliquez sur Afficher les instructions de configuration SAML.
      • Sura page Comment configurer SAML 2.0 pour l’application <pré-autorisée>, faites défiler jusqu’à la section Facultatif, fournissez les métadonnées IdP suivantes à votre fournisseur de SP.
      • Copiez le contenu du champ XML et enregistrez-le dans un fichier appelé pre-auth_idp_metadata.xml.
    7. (Facultatif) Configurez l’authentification multifacteur :

      • Dans Okta : Applications > Applications > Votre nouvelle application (par exemple Tableau Pre-Auth ) > Connexion
      • Sous Stratégie de connexion, cliquez sur Ajouter une règle.
      • Dans Règle de connexion aux applications, spécifiez un nom et les différentes options MFA. Pour tester la fonctionnalité, vous pouvez laisser toutes les options par défaut. Par contre, sous Actions, vous devez sélectionner Demander le facteur, puis spécifier la fréquence à laquelle les utilisateurs doivent se connecter. Cliquez sur Enregistrer.

    Créer et affecter un utilisateur Okta

    1. Dans Okta, créez un utilisateur avec le même nom d’utilisateur que vous avez créé dans Tableau (user@example.com)  : Répertoire > Personnes > Ajouter une personne.
    2. Une fois l’utilisateur créé, attribuez la nouvelle application Okta à cette personne : cliquez sur le nom d’utilisateur, puis attribuez l’application dans Attribuer une application.

    Installer Mellon pour la pré-authentification

    Cet exemple utilise mod_auth_mellon, module open source largement répandu. Certaines distributions Linux contiennent des versions obsolètes de mod_auth_mellon provenant d’un référentiel plus ancien. Ces versions obsolètes peuvent contenir des vulnérabilités de sécurité inconnues ou des problèmes fonctionnels. Si vous choisissez d’utiliser mod_auth_mellon, vérifiez que vous utilisez une version à jour.

    Le module mod_auth_mellon est un logiciel tiers. Nous avons tout mis en œuvre pour vérifier et documenter les procédures permettant d’activer ce scénario. Il peut toutefois arriver que le logiciel tiers change ou que votre scénario diffère de l’architecture de référence décrite ici. Veuillez vous référer à la documentation du fournisseur tiers pour les détails de configuration et l’assistance.

    1. Sur l’instance EC2 active qui exécute le serveur de la passerelle indépendante, installez une version courante du module d’authentification Mellon.

    2. Créez le répertoire /etc/mellon :

      sudo mkdir /etc/mellon

    Configurer Mellon comme module de pré-authentification

    Exécutez cette procédure sur la première instance de la passerelle indépendante.

    Vous devez avoir une copie du fichier pre-auth_idp_metadata.xml que vous avez créé à partir de la configuration Okta.

    1. Changez de répertoire :

      cd /etc/mellon

    2. Créez les métadonnées du fournisseur de services. Exécutez le script mellon_create_metadata.sh. Vous devez inclure l’ID d’entité et l’URL de retour de votre entreprise dans la commande.

      L’URL de retour est appelée URL d’authentification unique dans Okta. Le dernier élément du chemin dans l’URL de retour est appelé MellonEndpointPath dans le fichier de configuration mellon.conf présenté plus loin dans cette procédure. Dans cet exemple, nous spécifions sso comme chemin de point de terminaison.

      Par exemple :

      sudo /usr/libexec/mod_auth_mellon/mellon_create_metadata.sh https://tableau.example.com "https://tableau.example.com/sso"

      Le script renvoie le certificat du fournisseur de services, la clé et les fichiers de métadonnées.

    3. Renommez les fichiers du fournisseur de services dans le répertoire mellon pour une meilleure lisibilité. Nous désignerons ces fichiers par les noms suivants dans la documentation :

      sudo mv *.key mellon.key
      sudo mv *.cert mellon.cert
      sudo mv *.xml sp_metadata.xml

    4. Copiez le fichier pre-auth_idp_metadata.xml dans le même répertoire.

    5. Modifiez la propriété et les autorisations sur tous les fichiers dans l’annuaire /etc/mellon :

      sudo chown tableau-tsig mellon.key
      sudo chown tableau-tsig mellon.cert
      sudo chown tableau-tsig sp_metadata.xml
      sudo chown tableau-tsig pre-auth_idp_metadata.xml 
      sudo chmod +r * mellon.key
      sudo chmod +r * mellon.cert
      sudo chmod +r * sp_metadata.xml
      sudo chmod +r * pre-auth_idp_metadata.xml 

    6. Créez le répertoire /etc/mellon/conf.d :

      sudo mkdir /etc/mellon/conf.d
    7. Créez le fichier global.conf dans le répertoire /etc/mellon/conf.d.

      Copiez le contenu du fichier comme indiqué ci-dessous, mais mettez à jourMellonCookieDomain avec votre nom de domaine racine. Par exemple, si le nom de domaine de Tableau est tableau.example.com, entrez example.com pour le domaine racine.

      <Location "/">
      AuthType Mellon
      MellonEnable auth
      Require valid-user
      MellonCookieDomain <root domain>
      MellonSPPrivateKeyFile /etc/mellon/mellon.key
      MellonSPCertFile /etc/mellon/mellon.cert
      MellonSPMetadataFile /etc/mellon/sp_metadata.xml
      MellonIdPMetadataFile /etc/mellon/pre-auth_idp_metadata.xml
      MellonEndpointPath /sso
      </Location>
      
      <Location "/tsighk">
      MellonEnable Off
      </Location>
    8. Créez le fichier mellonmod.conf dans le répertoire /etc/mellon/conf.d.

      Ce fichier contient une seule directive qui spécifie l’emplacement du fichier mod_auth_mellon.so. L’emplacement dans l’exemple ici est l’emplacement par défaut du fichier. Vérifiez que le fichier se trouve à cet emplacement ou modifiez le chemin dans cette directive pour qu’il corresponde à l’emplacement réel de mod_auth_mellon.so :

      LoadModule auth_mellon_module /usr/lib64/httpd/modules/mod_auth_mellon.so

    Créer une application Tableau Server dans Okta

    1. Dans le tableau de bord Okta : Applications > Applications > Parcourir le catalogue d’applications
    2. Dans Parcourir le catalogue d’intégration d’applications, recherchez Tableau, sélectionnez la section Tableau Server, puis cliquez sur Ajouter.
    3. Sur Ajouter Tableau Server > Paramètres généraux, saisissez une étiquette, puis cliquez sur Suivant.
    4. Dans Options de connexion, sélectionnez SAML 2.0, puis faites défiler jusqu’à Paramètres de connexion avancés :
      • ID d’entité SAML : saisissez l’URL publique, par exemple https://tableau.example.com.
      • Format du nom d’utilisateur de l’application : Courriel
    5. Cliquez sur le lien Métadonnées du fournisseur d’identité pour lancer un navigateur. Copiez le lien du navigateur. C’est le lien que vous utiliserez lorsque vous configurerez Tableau dans la procédure qui suit.
    6. Cliquez sur Terminé.
    7. Attribuez la nouvelle application Tableau Server Okta à votre utilisateur (user@example.com) : cliquez sur le nom d’utilisateur, puis attribuez l’application dans Attribuer une application.

    Définir la configuration du module d’authentification sur Tableau Server

    Exécutez les commandes suivantes sur le nœud 1 Tableau Server. Ces commandes indiquent les emplacements des fichiers de configuration Mellon sur l’ordinateur distant de la passerelle indépendante. Vérifiez que les chemins d’accès du fichier indiqués dans ces commandes correspondent aux chemins d’accès et à l’emplacement des fichiers sur l’ordinateur distant de la passerelle indépendante.

    tsm configuration set -k gateway.tsig.authn_module_block -v "/etc/mellon/conf.d/mellonmod.conf" --force-keys
    tsm configuration set -k gateway.tsig.authn_global_block -v "/etc/mellon/conf.d/global.conf" --force-keys

    Pour réduire les temps d’arrêt, n’appliquez pas les modifications tant que vous n’avez pas activé SAML comme décrit dans la section suivante.

    Activer SAML sur Tableau Server pour fournisseur d’identités

    Exécutez cette procédure sur le Nœud 1 de Tableau Server.

    1. Téléchargez les métadonnées de l’application Tableau Server depuis Okta. Utilisez le lien que vous avez enregistré de la procédure précédente :

      wget https://dev-66144217.okta.com/app/exk1egxgt1fhjkSeS5d7/sso/saml/metadata -O idp_metadata.xml

    2. Copiez un certificat TLS et le fichier de clé associé sur Tableau Server. Le fichier de clé doit être une clé RSA. Pour plus d’informations sur la certificat et les exigences du fournisseur d’identités, consultez Exigences en matière d’authentification SAML (Linux(Le lien s’ouvre dans une nouvelle fenêtre)).

      Pour simplifier la gestion et le déploiement des certificats, et comme meilleure pratique de sécurité, nous vous recommandons d’utiliser des certificats générés par une autorité de certification (CA) tierce de confiance majeure. Vous pouvez aussi générer des certificats auto-signés ou utiliser des certificats d’une PKI pour TLS.

      Si vous n’avez pas de certificat TLS, vous pouvez générer un certificat auto-signé en appliquant la procédure intégrée ci-dessous.

      Générer un certificat auto-signé

      Exécutez cette procédure sur le Nœud 1 de Tableau Server.

      1. Générez la clé de l’autorité de certification racine (CA) de signature :

        openssl genrsa -out rootCAKey-saml.pem 2048

      2. Créez le certificat CA racine :

        openssl req -x509 -sha256 -new -nodes -key rootCAKey-saml.pem -days 3650 -out rootCACert-saml.pem

        Vous serez invité à saisir des valeurs pour les champs du certificat. Par exemple :

        Country Name (2 letter code) [XX]:US
        State or Province Name (full name) []:Washington
        Locality Name (eg, city) [Default City]:Seattle
        Organization Name (eg, company) [Default Company Ltd]:Tableau
        Organizational Unit Name (eg, section) []:Operations
        Common Name (eg, your name or your server's hostname) []:tableau.example.com
        Email Address []:example@tableau.com
      3. Créez le certificat et la clé associée (server-saml.csr et server-saml.key dans l’exemple ci-dessous). Le nom du sujet du certificat doit correspondre au nom de l’hôte public de l’hôte Tableau. Le nom du sujet est défini à l’aide de l’option -subj avec le format "/CN=<host-name>", par exemple :

        openssl req -new -nodes -text -out server-saml.csr -keyout server-saml.key -subj "/CN=tableau.example.com"

      4. Signez le nouveau certificat avec le certificat CA que vous avez créé ci-dessus. La commande suivante génère également le certificat au format crt :

        openssl x509 -req -in server-saml.csr -days 3650 -CA rootCACert-saml.pem -CAkey rootCAKey-saml.pem -CAcreateserial -out server-saml.crt

      5. Convertissez le fichier de clé en RSA. Tableau requiert un fichier de clé RSA pour SAML. Pour convertir la clé, exécutez la commande suivante :

        openssl rsa -in server-saml.key -out server-saml-rsa.key

    3. Configurez SAML. Exécutez la commande suivante, en spécifiant votre ID d’entité et votre URL de retour, ainsi que les chemins d’accès au fichier de métadonnées, au fichier de certificat et au fichier de clé :

      tsm authentication saml configure --idp-entity-id "https://tableau.example.com" --idp-return-url "https://tableau.example.com" --idp-metadata idp_metadata.xml --cert-file "server-saml.crt" --key-file "server-saml-rsa.key"

      tsm authentication saml enable

    4. Si votre entreprise exécute Tableau Desktop 2021.4 ou une version ultérieure, vous devez exécuter la commande suivante pour activer l’authentification via les serveurs proxy inverses.

      Les versions de Tableau Desktop 2021.2.1 - 2021.3 fonctionneront sans que cette commande soit exécutée, à condition que votre module de pré-authentification (par exemple Mellon) soit configuré pour autoriser la conservation des cookies de domaine de niveau supérieur.

      tsm configuration set -k features.ExternalBrowserOAuth -v false

    5. Appliquez les changements de configuration :

      tsm pending-changes apply

    Redémarrez le service tsig-httpd

    Au fur et à mesure que votre déploiement Tableau Server applique les modifications, reconnectez-vous à l’ordinateur de la passerelle indépendante Tableau Server et exécutez les commandes suivantes pour redémarrer le service tsig-httpd :

    sudo su - tableau-tsig
    systemctl --user restart tsig-httpd
    exit

    Valider la fonctionnalité SAML

    Pour valider la fonctionnalité SAML de bout en bout, connectez-vous à Tableau Server avec l’URL publique (par exemple, https://tableau.example.com) en utilisant le compte administrateur Tableau que vous avez créé au début de cette procédure.

    Si TSM ne démarre pas (« erreur liée à la passerelle ») ou si vous obtenez des erreurs liées au navigateur lors d’une tentative de connexion, consultez Résoudre les problèmes de la passerelle indépendante Tableau Server.

    Configurer le module d’authentification sur la deuxième instance de la passerelle indépendante

    Lorsque vous avez correctement configuré la première instance de passerelle indépendante, déployez la deuxième instance. Dans le cas présent, il s’agit du processus final d’installation du scénario AWS/Mellon/Okta décrit dans cette rubrique. La procédure suppose que vous avez déjà installé la passerelle indépendante sur la deuxième instance, comme décrit précédemment dans cette rubrique ( Installer la passerelle indépendante).

    Le processus de déploiement de la deuxième passerelle indépendante nécessite de suivre les étapes ci-après :

    1. Sur la deuxième instance de la passerelle indépendante : installez le module d’authentification Mellon.

      Ne configurez pas le module d’authentification Mellon comme décrit précédemment dans cette rubrique. Au lieu de cela, vous devez cloner la configuration en suivant la description des étapes suivantes.

    2. Sur la (première) instance configurée de la passerelle indépendante :

      Prenez une copie du fichier tar de la configuration Mellon existante. La sauvegarde avec tar conservera toute la hiérarchie des répertoires et les autorisations. Exécutez les commandes suivantes :

      cd /etc
      sudo tar -cvf mellon.tar mellon

      Copiez le fichier mellon.tar dans la deuxième instance de la passerelle indépendante.

    3. Sur la deuxième instance de passerelle indépendante :

      Extrayez (« décompressez ») le fichier tar dans la deuxième instance du répertoire /etc. Exécutez les commandes suivantes :

      cd /etc
      sudo tar -xvf mellon.tar

    4. Sur le nœud 1 du déploiement de Tableau Server : mettez à jour le fichier de connexion (tsig.json) avec l’information de connexion de la deuxième passerelle indépendante. Vous devrez récupérer la clé d’authentification comme décrit précédemment dans cette rubrique ( Installer la passerelle indépendante).

      Un exemple de fichier de connexion (tsig.json) est illustré ici :

      {
      "independentGateways": [
       {
         "id": "ip-10-0-1-169.ec2.internal",
         "host": "ip-10-0-1-169.ec2.internal",
         "port": "21319",
         "protocol" : "http",
         "authsecret": "13660-27118-29070-25482-9518-22453"
       },
       {
         "id": "ip-10-0-2-230.ec2.internal",
         "host": "ip-10-0-2-230.ec2.internal",
         "port": "21319",
         "protocol" : "http",
         "authsecret": "9055-27834-16487-27455-30409-7292"
       }]
       }
    5. Sur le nœud 1 du déploiement de Tableau Server : exécutez les commandes suivantes pour mettre à jour la configuration :

      tsm stop
      tsm topology external-services gateway update -c tsig.json
      
      tsm start
    6. Sur les deux instances de la passerelle indépendante : pendant le démarrage de Tableau Server, redémarrez le processus tsig-httpd :

      sudo su - tableau-tsig
      systemctl --user restart tsig-httpd
      exit
    7. Dans AWS EC2>Groupes cibles : mettez à jour le groupe cible pour inclure l’instance EC2 exécutant la deuxième instance de la passerelle indépendante.

      Sélectionnez le groupe cible que vous venez de créer, puis cliquez sur l’onglet Cibles. 

      • Cliquez sur Modifier.
      • Sélectionnez l’instance EC2 de l’ordinateur personnel de la deuxième passerelle indépendante, puis cliquez sur Ajouter aux instances enregistrées. Cliquez sur Enregistrer.
    Merci de vos commentaires!