Configurer l’OAuth pour Amazon Redshift et IAM Identity Center


Depuis Tableau 2023.3.2, vous pouvez utiliser Oauth 2.0/OIDC pour fédérer l’identité d’un fournisseur d’identité externe dans Amazon Redshift.

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.

Pour des exemples détaillés de mise en œuvre de l’authentification avec Redshift, consultez les articles de blogue « Intégrer Tableau et Okta à Amazon Redshift à l’aide d’AWS IAM Identity Center(Le lien s’ouvre dans une nouvelle fenêtre) » et « Intégrer Tableau et Microsoft Entra ID à Amazon Redshift à l’aide d’AWS IAM Identity Center(Le lien s’ouvre dans une nouvelle fenêtre) ».

Remarque : Les jetons d’actualisation à usage unique (parfois appelés jetons d’actualisation en continu ou rotation des jetons d’actualisation) ne sont pas pris en charge pour les connexions OAuth à Tableau pour le moment. La prise en charge de ces jetons est prévue pour une future version.

Étape 1 : Configurer le jeton 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 nouveaux fichiers de configuration Tableau OAuth dans le dossier OAuthConfigs associé à chaque application sur les hôtes de bureau (Tableau Desktop, Tableau Prep Builder, Tableau Bridge) et sur chaque site Tableau Server et Tableau Cloud qui utilisera OAuth.

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

Jetons

Par défaut, Redshift OAuth utilisant IAM IDC transmet le jeton d’identification au pilote.. Pour les clients locaux, notamment ceux qui utilisent Tableau Bridge, vous pouvez plutôt utiliser un fichier TDC pour transmettre le jeton d’accès.

<connection-customization class='redshift' enabled='true' version='10.0'>
	<vendor name='redshift' />
	<driver name='redshift' />
	<customizations>
		<customization name='CAP_OAUTH_FEDERATE_ID_TOKEN' value='yes'/>
	</customizations>
</connection-customization>

Pour plus d’informations sur la configuration et l’installation des fichiers .tdc, consultez Personnalisation et optimisation d’une connexion(Le lien s’ouvre dans une nouvelle fenêtre) et Utilisation d’un fichier .tdc avec Tableau Server(Le lien s’ouvre dans une nouvelle fenêtre).

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 au moins la version 2.x du lecteur d’interface universelle de connexion aux bases de données. Téléchargez la dernière version du lecteur d’interface universelle de connexion aux bases de données Redshift disponible sur https://github.com/aws/amazon-redshift-odbc-driver/tags(Le lien s’ouvre dans une nouvelle fenêtre). Notez qu’il n’existe pas encore de pilote v2 pour OSX.

Dépannage de l’OAuth Redshift IAM IDC

La meilleure façon de diagnostiquer des erreurs est de supprimer Tableau. Par contre, vous pouvez effectuer un test en utilisant le gestionnaire de pilotes ou un outil similaire. Ceci sert uniquement à la résolution des problèmes : vous ne devez pas utiliser un DSN ou le connecteur « Autres bases de données ODBC » dans le cadre d’une utilisation régulière de cette fonctionnalité. Pour garantir la validité d’un test, les paramètres doivent être identiques, comme indiqué ci-dessous, à l’exception des informations relatives au groupement, à la base de données, au jeton et à l’espace de noms.

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.

Avant de lancer le test, vous devez d’abord obtenir un jeton d’accès (par défaut pour IAM IDC) ou un jeton d’actualisation (si vous l’avez 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. Sous Windows, vous pouvez utiliser le gestionnaire de pilotes ODBC. 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.

Tableau vous recommande de ne pas utiliser d’autres modules d’extension pour effectuer le test, car ils risquent de ne pas fonctionner dans un environnement serveur. Ils utilisent un profil AWS fixe ou ils requièrent un accès direct à un navigateur.

Voici un exemple de l’utilisation du gestionnaire de pilotes ODBC sous Windows.

Retour en haut
Merci de vos commentaires!Votre commentaire s été envoyé avec succès. Merci!