--- schema_version: "1" id: bde66b943f025efb0e9eb7e73bdf096c7bd278cc3ab180fd46821b5a4079af8a title: Configurer Amazon Athena IAM OAuth collection: tableau version: current locale: fr-fr portal_url: https://docs.salesforce.com/tableau/current/fr-fr/pro/desktop/amazon_athena_idp.md canonical_url: https://help.tableau.com/current/pro/desktop/fr-fr/amazon_athena_idp.htm source_site: help.tableau.com content_type: documentation content_hash: a57b6601bd0f9c51f1da9cd858ffb5d624b5b6366221bb484ade002a849d9319 description: Set up OAuth 2.0/OIDC identity federation from an external IdP to Amazon Athena for Tableau. --- [Passer au contenu principal](#main-content) # Configurer Amazon Athena IAM OAuth Depuis Tableau 2023.2, vous pouvez utiliser OAuth 2.0/OIDC pour fédérer l’identité depuis un fournisseur d’identité (IdP) externe vers Amazon Athena. Selon le fournisseur d’identité, plusieurs étapes différentes sont nécessaires pour configurer l’intégration. Tableau ne fournit des instructions détaillées que sur la manière de configurer les produits Tableau. Pour des instructions sur la configuration de votre fournisseur d’identité (Okta, par exemple), reportez-vous à l’aide et aux didacticiels de ce produit. Ce document fournit une vue d’ensemble générale du processus de configuration. **Remarque** : les jetons d’actualisation à usage unique (parfois appelés jetons d’actualisation continus ou rotation des jetons d’actualisation) ne sont pas pris en charge actuellement pour les connexions OAuth à Tableau Cloud à l’aide de Tableau Bridge. La prise en charge de ces jetons est prévue pour une version future. **Remarque :** les étapes et les liens qui sont extérieurs au contenu Tableau et Salesforce ne sont pas nécessairement mis à jour ou exacts. ## Configurer le fournisseur d’identité (IdP) 1. Créez des clients OAuth sur l’IdP pour Tableau Desktop et Tableau Server. Le client Desktop active [PKCE](https://auth0.com/docs/get-started/authentication-and-authorization-flow/authorization-code-flow-with-pkce) et utilise les redirections [http://localhost](http://localhost/). 2. Ajoutez les revendications personnalisées nécessaires pour l’autorisation concernant des rôles. Pour plus de détails sur les revendications et les portées, consultez [Portées et revendications](https://curity.io/resources/learn/scopes-vs-claims/). 3. Créez le fichier de configuration Tableau OAuth. Pour plus de détails sur la façon de procéder, voir [Configuration et utilisation d’OAuth](https://tableau.github.io/connector-plugin-sdk/docs/oauth) sur [GitHub](https://tableau.github.io/connector-plugin-sdk/docs/oauth), et des exemples [ici](https://github.com/tableau/connector-plugin-sdk/tree/master/samples/components/oauth). Veillez à ajouter le préfixe « custom\_ » aux ID de configuration Tableau OAuth. 4. Installez les fichiers de configuration Tableau OAuth sur les ordinateurs Tableau Desktop, Tableau Server et les sites Tableau Cloud comme expliqué dans la rubrique de configuration OAuth ci-dessus. ## Configurer l’IdP sur AWS 1. Créez l’entité de l’IdP. Consultez la documentation Amazon [À propos de la fédération d’identité web](https://docs.aws.amazon.com/fr_fr/IAM/latest/UserGuide/id_roles_providers_oidc.html), [Création de fournisseurs d’identité OpenID Connect (OIDC)](https://docs.aws.amazon.com/fr_fr/IAM/latest/UserGuide/id_roles_providers_create_oidc.html). 2. L’IdP doit être configuré pour la fédération avec Athena d’une manière compatible avec le plug-in du pilote de Tableau. Les informations de fournisseur suivantes sont utilisées pour les flux Tableau Server et Tableau Desktop : AwsCredentialsProviderClass=com.simba.athena.iamsupport.plugin.JwtCredentialsProvider role\_session\_name=AthenaJWT 3. Créez des rôles et des stratégies pour l’IdP spécifiquement. Consultez [Création d’un rôle pour OpenID Connect](https://docs.aws.amazon.com/fr_fr/IAM/latest/UserGuide/id_roles_create_for-idp_oidc.html) dans la documentation AWS. ## Configurer des rôles pour Athena Joignez les stratégies nécessaires pour Athena. Vous pouvez procéder de plusieurs manières, par exemple en utilisant des revendications personnalisées. dans le jeton openID pour ajouter des autorisations à des rôles. Ces rôles peuvent alors accéder à d’autres ressources. Pour plus d’informations, consultez : - [Tutoriel’ configuration de l’accès fédéré des utilisateurs d’Okta à Athena en utilisant Lake Formation et JDBC](https://docs.aws.amazon.com/fr_fr/athena/latest/ug/security-athena-lake-formation-jdbc-okta-tutorial.html). - [Accès détaillé aux bases de données et tables dans le AWS Glue Data Catalog.](https://docs.aws.amazon.com/fr_fr/athena/latest/ug/fine-grained-access-to-glue-resources.html) ## Se connecter à Athena L’utilisateur doit spécifier l’ARN (Amazon Resource Name) du rôle AWS à présupposer, puis, sous Fournisseur OAuth, sélectionner la configuration OAuth installée précédemment. Notez que le menu déroulant permettant de sélectionner une configuration n’apparaît que s’il existe plusieurs configurations parmi lesquelles choisir. Une fois la configuration correctement effectuée, l’utilisateur est redirigé vers l’IdP pour authentifier et autoriser des jetons pour Tableau. Tableau reçoit des jetons openid et refresh. AWS est capable de valider le jeton et la signature depuis l’IdP, d’extraire les revendications du jeton, de rechercher le mappage de l’utilisateur au rôle IAM et d’autoriser Tableau ou non à présupposer le rôle pour le compte de l’utilisateur. [Exemple : AssumeRoleWithWebIdentity](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html) ![Connexion à la fenêtre Athena](/tableau/current/fr-fr/pro/desktop/fr-fr/Img/athenaidp_signin.png) ## Jetons Par défaut, Athena OAuth IAM transmet le jeton d’identification au pilote. Pour les clients sur site, y compris ceux qui utilisent Tableau Bridge, vous pouvez 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-fr/connect_customize.htm). ## Configuration d’Okta Dans le cas d’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 sont plus flexibles. Un serveur d’autorisation personnalisé est créé par défaut et porte le nom « default ». L’URL d’autorisation peut se présenter comme suit. `https://${yourOktaDomain}/oauth2/{authServerName}/v1/authorize` ![Tableau de bord Okta](/tableau/current/fr-fr/pro/desktop/fr-fr/Img/athena_okta.png)