--- schema_version: "1" id: 3f1bfbd67ec47a63bb294699c7cd778bcdcea5924505bf2eb4e6c23376d85686 title: Configurer l’authentification IAM sur Amazon Redshift collection: tableau version: current locale: fr-ca portal_url: https://docs.salesforce.com/tableau/current/fr-ca/server-linux/config_oauth_redshift_iam.md canonical_url: https://help.tableau.com/current/server-linux/fr-ca/config_oauth_redshift_iam.htm source_site: help.tableau.com content_type: documentation content_hash: f7035eb34f71d7ff8a9bfb8f99a86e713d3e36fc919cd9168a3ae60a82e32c92 description: Set up Amazon Redshift IAM OAuth identity federation from an external IdP for Tableau. --- [Passer au contenu principal](#main-content) # Configurer l’authentification IAM sur Amazon Redshift 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 service AWS IAM désormais obsolète. Pour l’intégration IAM IDC, consultez [Configurer l’OAuth pour Amazon Redshift et IAM Identity Center](https://help.tableau.com/current/server-linux/fr-ca/config_oauth_redshift_iam_idc.htm). 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 contient pas des instructions détaillées sur la configuration d’AWS ou du fournisseur d’identités, mais la méthode générale est décrite ci-dessous. ## Étape 1 : Configurer le jeton IDP 1. Créez des clients OAuth sur le fournisseur d’identités pour Tableau Desktop, Tableau Server ou Tableau Cloud. Le client Desktop doit activer `PKCE` et utiliser les redirections `http://localhost`. 2. Ajoutez des revendications personnalisées afin de les utiliser à des fins d’autorisation des rôles. Plus particulièrement, si vous utilisez un IAM d’origine, vous voudrez peut-être ajouter des revendications pour `DbUser` et `DbGroups`. Ces revendications pourront être utilisées ultérieurement dans vos stratégies IAM. 3. Créez les fichiers de configuration Tableau OAuth. Consultez la documentation sur [github](https://tableau.github.io/connector-plugin-sdk/docs/oauth "Documentation OAuth sur GitHub") et des exemples [ici](https://github.com/tableau/connector-plugin-sdk/tree/master/samples/components/oauth "Exemples OAuth sur GitHub."). 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_` ». **Remarque :** Les identifiants de configuration Oauth sont limités à un maximum de 36 caractères. Les ID plus longs peuvent ne pas générer d’erreur, mais ils ne fonctionneront pas. 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 votre fournisseur d’identité ne prend pas en charge ce port, assurez-vous d’ajouter plusieurs URL de rappel localhost à la liste d’autorisations du fichier de configuration et du fournisseur 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. ## Configurer le fournisseur d’identité sur AWS 1\. Créez le modèle de fournisseur d’identité sur AWS. Consultez la documentation Amazon [Fédération d’identité Web](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_oidc.html "Documentation AWS sur la fédération d’identité Web") et [Créer un fournisseur d’identité OIDC](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc.html "Documentation AWS sur la création d’un fournisseur d’identité OIDC"). 2\. Créez des rôles et des stratégies spécifiquement pour le fournisseur d’identité. Consultez [Créer un rôle pour OIDC](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-idp_oidc.html "Documentation AWS sur la création de rôles pour OIDC") dans la documentation AWS. ## Configurer des rôles pour les utilisateurs de Redshift Joignez les stratégies nécessaires pour Redshift. Vous pouvez utiliser des revendications personnalisées du jeton pour autoriser des rôles. La [documentation AWS](https://docs.aws.amazon.com/redshift/latest/mgmt/options-for-providing-iam-credentials.html "Documentation AWS sur l’octroi des identifiants IAM") contient de nombreux exemples avec SAML. Ces exemples peuvent être facilement adaptés à OAuth. Dans le cas d’OAuth, les seules revendications sont « `DbUser` », « `DbGroups` », etc. Voici un exemple de stratégie décrite dans la documentation AWS : { "Version": "2012-10-17", "Statement": \[ { "Effect": "Allow", "Action": "redshift:GetClusterCredentials", "Resource": \[ "arn:aws:redshift:us-west-1:123456789012:dbname:cluster-identifier/dev", "arn:aws:redshift:us-west-1:123456789012:dbuser:cluster-identifier/${redshift:DbUser}", "arn:aws:redshift:us-west-1:123456789012:cluster:cluster-identifier" \], "Condition": { "StringEquals": { "aws:userid": "AROAJ2UCCR6DPCEXAMPLE:${redshift:DbUser}@example.com" } } }, { "Effect": "Allow" "Action": "redshift:CreateClusterUser", "Resource": "arn:aws:redshift:us-west-1:12345:dbuser:cluster-identifier/${redshift:DbUser}" }, { "Effect": "Allow", "Action": "redshift:JoinGroup", "Resource": "arn:aws:redshift:us-west-1:12345:dbgroup:cluster-identifier/my\_dbgroup" }, { "Effect": "Allow", "Action": \[ "redshift:DescribeClusters", "iam:ListRoles" \], "Resource": "\*" } \] } ## Se connecter à Redshift L’utilisateur doit préciser le rôle ARN à assumer, puis sélectionner la configuration OAuth installée précédemment. ![](/tableau/current/fr-ca/server-linux/fr-ca/Img/redshift_oauth__iam_connect.png) Lorsque l’utilisateur est correctement configuré, il est redirigé vers le fournisseur d’identité pour s’authentifier et autoriser les jetons pour Tableau. Tableau reçoit les jetons openid et les actualise. AWS peut valider le jeton et la signature reçus du fournisseur d’identité, extraire les revendications du jeton, vérifier si les revendications sont associées au rôle IAM, et autoriser ou empêcher Tableau d’assumer le rôle au nom de l’utilisateur. (En d’autres termes, [AssumeRoleWithWebIdentity](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html "Documentation AWS pour AssumeRoleWithWebIdentity")). ## Jetons Par défaut, Redshift OAuth IAM 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. Pour plus d’informations sur la configuration et l’installation des fichiers .tdc, consultez [Personnalisation et optimisation d’une connexion](https://help.tableau.com/current/pro/desktop/fr-ca/connect_customize.htm) et [Utilisation d’un fichier .tdc avec Tableau Server](https://help.salesforce.com/s/articleView?id=001458291&type=1). ## À propos de la fédération de groupes Lorsque vous utilisez l’authentification OAuth avec un rôle IAM, vous pouvez indiquer si vous utilisez ou non la fédération de groupes. Cela modifiera la manière dont le connecteur interagit avec l’API d’authentification pour s’interfacer avec Redshift. - Au moment de la connexion, lorsque la case « Fédération de groupe » (disponible dans les versions 2025.1 et ultérieures) est cochée, le pilote Redshift utilise l’API [`getClusterCredentialsWithIAM`](https://docs.aws.amazon.com/redshift/latest/APIReference/API_GetClusterCredentialsWithIAM.html) pour obtenir les informations d’identification dans les groupements mis en service. - Lorsque la case « Fédération de groupe » n’est pas cochée, l’API [`getClusterCredentials`](https://docs.aws.amazon.com/redshift/latest/APIReference/API_GetClusterCredentials.html) est utilisée à la place. Ces deux API renverront des jetons IAM avec des propriétés légèrement différentes. Pour plus d’informations, consultez la documentation de l’API AWS dont le lien se trouve ci-dessus, et les [options du lecteur d’interface universelle de connexion aux bases de données](Https://docs.aws.amazon.com/redshift/latest/mgmt/odbc20-configuration-options.html "Informations sur la configuration d’ODBC 2.0 avec AWS"). #### Notes d’utilisation - Pour Tableau Desktop et Tableau Prep Builder avant la version 2024.3, cela peut être défini dans le champ de configuration avancée du pilote à l’aide de « group\_federation=1 ». La configuration peut également être effectuée l’aide du fichier TDC pour définir des propriétés de connexion personnalisées. Pour plus d’informations sur l’utilisation d’un TDC, consultez [Personnalisation et optimisation d’une connexion](https://help.tableau.com/current/pro/desktop/fr-ca/connect_customize.htm). - La version 2024.3 contient un champ group\_federation dans la boîte de dialogue de connexion pour les environnements locaux (Tableau Desktop, Tableau Prep Builder et Tableau Server). Cette fonctionnalité sera disponible dans Tableau Cloud à partir de la version 2025.1 (disponible en février 2025). - Pour utiliser la fédération de groupe avec Tableau Server, group\_federation doit être ajouté à la liste d’autorisations supplémentaires ODBC. Pour plus d’informations, consultez [Personnaliser la chaîne de connexion pour un connecteur natif](https://help.tableau.com/current/pro/desktop/fr-ca/connect_string_custom.htm). ## 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é, appelé « default », est créé par défaut. L’URL d’autorisation devrait se présenter comme suit : https://${yourOktaDomain}/oauth2/{authServerName}/v1/authorize ![](/tableau/current/fr-ca/server-linux/fr-ca/Img/redshift_oauth_iam_okta_800x332.png) ## Mettre à jour le lecteur Pour l’authentification Redshift utilisant le service IAM d’origine, vous pouvez utiliser l’un des deux lecteurs ci-après : - Lecteur d’interface universelle de connexion aux bases de données Redshift v1 à compter de la version 1.59, téléchargeable sur [https://docs.aws.amazon.com/redshift/latest/mgmt/configure-odbc-connection.html](https://docs.aws.amazon.com/redshift/latest/mgmt/configure-odbc-connection.html "Télécharger le lecteur d’interface universelle de connexion aux bases de données Redshift v1 sur Amazon"). - Lecteur d’interface universelle de connexion aux bases de données Redshift v2 à compter de la version 2.0.1.0, téléchargeable sur [https://github.com/aws/amazon-redshift-odbc-driver/tags](https://github.com/aws/amazon-redshift-odbc-driver/tags "Télécharger le lecteur d’interface universelle de connexion aux bases de données Redshift v2 sur Amazon"). Notez qu’il n’existe pas de pilote v2 pour OSX. ## Résolution des problèmes 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. **Remarque :** Omettez DbUser ou DbGroups dans la chaîne de connexion du DSN lors du test, car Tableau n’y a pas accès et ne peut pas les intégrer dans la chaîne de connexion. Vous pouvez l’inclure dans les revendications du jeton. 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 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. Les modules d’extension utilisant un profil AWS fixe ne fonctionneront que si vous souhaitez utiliser le même profil pour tous les utilisateurs de cette connexion. Les autres modules d’extension OAuth nécessitent un accès direct au navigateur système, qui ne fonctionne pas côté serveur. Voici un exemple de l’utilisation du gestionnaire de pilotes ODBC sous Windows. ![](/tableau/current/fr-ca/server-linux/fr-ca/Img/redshift_oauth_iam_troubleshoot.jpg)