Aide de Tableau Cloud

À partir de Tableau 2023.3.2 pour les installations sur site (Tableau Desktop, Tableau Server et Tableau Prep) et dès fin mars 2024 pour Tableau Cloud, vous pouvez utiliser l’OAuth 2.0/OIDC pour fédérer l’identité d’un fournisseur d’identité externe vers Amazon Redshift. Tableau Bridge peut être utilisé comme une solution temporaire sur Tableau Cloud, jusqu’à ce que cette fonctionnalité soit disponible. Pour plus d’informations au sujet de Bridge, consultez Utiliser Tableau Bridge pour garder les données à jour.

Remarque : Cette fonctionnalité n’est pas disponible pour OSX en raison des contraintes du pilote.

Ces instructions concernent le nouveau service AWS IAM IDC. Pour l’intégration IAM originale, voir Configurer l’authentification IAM sur Amazon Redshift.

Selon le fournisseur d’identité, plusieurs étapes sont nécessaires pour configurer l’intégration. Voici une présentation générale du processus. Tableau ne peut pas fournir d’instructions détaillées sur la façon de configurer AWS ou l’IDP, mais il s’agit de l’approche générale.

Configurer l’IDP

1. Créez des clients OAuth sur le fournisseur d’identité pour Tableau Desktop et Tableau Server ou Tableau Cloud. Le client Desktop doit activer PKCE et utiliser les redirections http://localhost.

2. Ajoutez les revendications personnalisées requises pour l’autorisation des rôles.

3. Créez les fichiers de configuration Tableau OAuth. Consultez la documentation sur github(Le lien s’ouvre dans une nouvelle fenêtre), ainsi que desexemples(Le lien s’ouvre dans une nouvelle fenêtre). Nous vous invitons à nous faire part d’exemples concernant d’autres fournisseurs d’identité.

   1. N’oubliez pas de préfixer les identifiants de configuration Tableau OAuth avec « custom_ ».

   2. Si votre fournisseur d’identité prend en charge le port dynamique de l’hôte local, désactivez OAUTH_CAP_FIXED_PORT_IN_CALLBACK_URL. Si ce n’est pas le cas, assurez-vous d’ajouter plusieurs URL de rappel de l’hôte local à la liste verte dans le fichier de configuration et sur le founisseur d’identité.

4. Installez les fichiers de configuration Tableau OAuth sur les ordinateurs de bureau et sur les sites Tableau Server ou Tableau Cloud.

Étape 2 : Configurer l’IDP et les rôles sur AWS

Consultez votre documentation AWS pour plus d’informations sur cette opération.

Étape 3 : Connexion à Redshift

1. Connectez-vous à Redshift.

2. Sélectionnez OAuth comme Authentification.

3. Sélectionnez ldentity Center comme Type de fédération.

4. (Facultatif) Spécifiez l’Espace de nom Identity Center si nécessaire.

Une fois la connexion correctement configurée, vous serez redirigé vers l’IdP pour vous authentifier et autoriser les jetons pour Tableau. Tableau recevra un jeton d’accès et des jetons d’actualisation. Il enverra le jeton d’accès au pilote pour authentification.

Okta

Si vous utilisez Okta, il est préférable d’utiliser un « serveur d’autorisation personnalisé » plutôt que le « serveur d’autorisation de l’organisation. » Les serveurs d’autorisation personnalisés offrent plus de souplesse. Un serveur d’autorisation personnalisé est créé par défaut et est nommé « défaut ». L’URL d’autorisation devrait se présenter comme suit :

https://${yourOktaDomain}/oauth2/{authServerName}/v1/authorize

Mettre à jour le pilote

Pour Redshift OAuth utilisant le service IAM IDC, vous devez utiliser le pilote Redshift ODBC, version 2.0.1.0 et ultérieure, qui peut être téléchargé à partir de https://github.com/aws/amazon-redshift-odbc-driver/tags(Le lien s’ouvre dans une nouvelle fenêtre). Notez qu’il n’existe pas de pilote v2 pour OSX.

Dépannage de l’OAuth Redshift IAM IDC

Lors de la première connexion, si vous recevez un message d’erreur du pilote concernant un jeton invalide ou expiré (il aura un code d’erreur SQLState [28000] ou [08001] dans le message d’erreur), alors Tableau a terminé le flux OAuth avec succès et a échoué avec le pilote. Cela veut dire que la configuration n’a pas été correctement effectuée sur AWS ou sur le fournisseur d’identité. Le pilote peut également retourner des autorisations ou des erreurs d’autorisation peuvent, ce qui échappe également au contrôle de Tableau.

La meilleure façon de diagnostiquer ces erreurs est de supprimer Tableau. Vous devez d’abord obtenir un jeton d’accès (par défaut pour IAM IDC) ou un jeton d’accès (si personnalisé) à envoyer au pilote.

Voici un exemple avec Okta. Les fournisseurs d’identité procèdent presque tous de manière assez semblable. Notez que pour utiliser ce flux, vous devez avoir activé le type d’attribution de mot de passe du propriétaire de la ressource. Remplacez l’URL du fournisseur d’identité, le secret client, l’ID client, le nom d’utilisateur et le mot de passe.

curl -X POST "https://OKTA_URL/v1/token" \
-H 'accept: application/json' \
-H "Authorization: Basic $(echo -n 'CLIENTID:CLIENTSECRET' | base64)" \
-H "Content-Type: application/x-www-form-urlencoded" \
-d "grant_type=password&username=USER&password=PASSWORD&scope=openid"

Une fois le jeton obtenu, vous pouvez utiliser une DSN en mode test. Voici un exemple de l’utilisation du gestionnaire de pilotes ODBC sous Windows. Sur Mac, vous pouvez utiliser l’interface utilisateur du gestionnaire de pilotes iODBC. Sous Linux, vous pouvez utiliser l’outil de ligne de commande isql inclus avec Tableau Server et qui se trouve dans le dossier customer-bin.