Configurer Amazon Redshift IAM OAuth

Depuis Tableau 2023.3.2, vous pouvez utiliser OAuth 2.0/OIDC pour fédérer l’identité à partir d’un fournisseur d’identité externe auprès d’Amazon Redshift.

Ces instructions concernent l’ancien service AWS IAM. Pour l’intégration d’IAM IDC, voir Configurer Amazon Redshift IAM Identity Center OAuth.

Selon le fournisseur d’identité, plusieurs étapes différentes sont nécessaires pour configurer l’intégration. Nous vous présentons ici un aperçu général. Tableau ne peut pas fournir d’instructions détaillées de configuration d’AWS ou de l’IdP, seule l’approche générale est décrite ci-dessous.

Étape 1 : Configurer l’IDP

Créez des clients OAuth sur l’IdP pour Tableau Desktop et Tableau Server ou Tableau Cloud. Le client Desktop doit activer PKCE et utiliser les redirections http://localhost.
Ajoutez des revendications personnalisées pour l’autorisation concernant des rôles. En particulier, si vous utilisez IAM d’origine, vous souhaiterez peut-être ajouter des revendications pour DbUser et DbGroups. Vous pourrez les utiliser ultérieurement dans vos stratégies IAM.
Créez des fichiers de configuration Tableau OAuth. Consultez la documentation sur GitHub(Le lien s’ouvre dans une nouvelle fenêtre) et des exemples ici(Le lien s’ouvre dans une nouvelle fenêtre). N’hésitez pas à nous envoyer des exemples d’autres fournisseurs d’identité.
1. Veillez à ajouter le préfixe « custom_ » aux ID de configuration Tableau OAuth.
2. Si votre IdP prend en charge le port localhost dynamique, désactivez OAUTH_CAP_FIXED_PORT_IN_CALLBACK_URL. Dans le cas contraire, veillez à ajouter plusieurs URL de rappel localhost à la liste d’autorisations dans le fichier de configuration et sur l’IdP.
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 l’IdP sur AWS

1. Créez le modèle d’IdP sur AWS. Consultez la documentation Amazon À propos de la fédération d’identité web(Le lien s’ouvre dans une nouvelle fenêtre) et Création de fournisseurs d’identité OpenID Connect (OIDC)(Le lien s’ouvre dans une nouvelle fenêtre).

2. Créez des rôles et des stratégies spécifiquement conçus pour l’IdP. Consultez Création d’un rôle pour OIDC(Le lien s’ouvre dans une nouvelle fenêtre) dans la documentation AWS.

Configurer les rôles pour les utilisateurs de Redshift

Joignez les stratégies nécessaires pour Redshift. Vous pouvez utiliser des revendications personnalisées depuis le jeton pour les autorisations de rôles. La documentation AWS(Le lien s’ouvre dans une nouvelle fenêtre) présente plusieurs exemples utilisant SAML. Vous pouvez facilement les adapter à OAuth. Dans le cas d’OAuth, les revendications sont simplement « DbUser », « DbGroups », etc.

Voici un exemple de stratégie tirée de 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": "*"
    }
]
}

Connexion à Redshift

L’utilisateur doit spécifier l’ARN du rôle à présupposer, puis sélectionner la configuration OAuth installée précédemment.

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. (autrement dit, AssumeRoleWithWebIdentity(Le lien s’ouvre dans une nouvelle fenêtre)).

Jetons

Par défaut, Redshift 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='redshift' enabled='true' version='10.0'>
	<vendor name='redshift' />
	<driver name='redshift' />
	<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) et Utilisation d’un fichier .tdc avec Tableau Server(Le lien s’ouvre dans une nouvelle fenêtre).

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 devrait se présenter comme suit :

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

Mettre à jour le pilote

Pour Redshift OAuth utilisant le service IAM d’origine, vous pouvez utiliser au choix :

Pilote Redshift ODBC v1 à partir de la version 1.59, téléchargeable sur https://docs.aws.amazon.com/fr_fr/redshift/latest/mgmt/configure-odbc-connection.html(Le lien s’ouvre dans une nouvelle fenêtre).
Pilote Redshift ODBC v2 à partir de la version 2.0.1.0, téléchargeable sur https://github.com/aws/amazon-redshift-odbc-driver/tags(Le lien s’ouvre dans une nouvelle fenêtre). Notez qu’il n’y a pas de pilote v2 pour OSX.

Résolution des problèmes

La meilleure façon de diagnostiquer ces erreurs est de supprimer Tableau de l’image. Vous pouvez également faire un test en utilisant le gestionnaire de pilotes ou un outil similaire. Ceci est uniquement destiné au dépannage : vous ne devez pas utiliser un DSN ou le connecteur « Autre ODBC » pour une utilisation régulière de cette fonctionnalité. Pour que le test soit valide, les paramètres doivent être les mêmes que ceux indiqués ci-dessous, à l’exception des informations sur le cluster, la base de données, le jeton et l’espace de noms.

Si vous voyez un message d’erreur concernant un jeton non valide/expiré provenant du pilote lors de la première connexion (il aura un code d’erreur SQLState comme [28000] ou [08001] dans le message d’erreur), cela signifie que Tableau a terminé avec succès le flux OAuth et échoué au niveau du pilote, et qu’il y a donc une erreur de configuration du côté d’AWS ou de l’IdP. Le pilote peut également renvoyer des erreurs d’autorisations, ce qui échappe également au contrôle de Tableau.

Avant de lancer le test, vous devez obtenir un jeton d’accès (par défaut pour IAM IDC) ou un jeton d’actualisation (si personnalisé) à envoyer au pilote.

Voici un exemple avec Okta. Presque tous les IdP procèdent de manière très similaire. 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 de l’IdP, 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 que vous avez le jeton, vous pouvez utiliser un DSN à des fins de 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 dans le dossier customer-bin.

Tableau vous recommande de ne pas utiliser d’autres plug-ins pour le test, car ils risquent de ne pas fonctionner dans un environnement serveur. Soit ils utilisent un profil AWS fixe, soit ils nécessitent un accès direct à un navigateur.

Vous trouverez ci-dessous un exemple d’utilisation du gestionnaire de pilotes ODBC sous Windows.

Retour en haut

Merci de vos commentaires !

Avis correctement envoyé. Merci

Aide de Tableau Server sur Windows