Utiliser votre propre fournisseur d’identité avec Amazon Athena
Depuis Tableau 2023.2, vous pouvez utiliser OAuth 2.0/OIDC pour fédérer l’identité depuis un fournisseur d’identité 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 é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)
Créez des clients OAuth sur l’IdP pour Tableau Desktop et Tableau Server. Le client Desktop active PKCE(Le lien s’ouvre dans une nouvelle fenêtre) et utilise les redirections http://localhost.
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(Le lien s’ouvre dans une nouvelle fenêtre).
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(Le lien s’ouvre dans une nouvelle fenêtre) sur GitHub, et des exemples ici. Veillez à ajouter le préfixe « custom_ » aux ID de configuration Tableau OAuth.
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
- Créez l’entité de l’IdP. Consultez la documentation Amazon À propos de la fédération d’identité web, Création de fournisseurs d’identité OpenID Connect (OIDC).
- 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 :
AwsCredentialsProviderClas=com.simba.athena.iamsupport.plugin.JwtCredentialsProvider
role_session_name=AthenaJWT - Créez des rôles et des stratégies pour l’IdP spécifiquement. Consultez Création d’un rôle pour OpenID Connect 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 :
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
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.
<connection-customization class='athena' enabled='true' version='10.0'> <vendor name='athena' /> <driver name='athena' /> <customizations> <customization name='CAP_OAUTH_FEDERATE_ACCCESS_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).
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