Configurer Amazon Redshift IAM OAuth

À compter de Tableau 2023.3.2 pour une installation sur site (Tableau Desktop, Tableau Server et Tableau Prep) et fin mars 2024 pour Tableau Cloud, vous pouvez utiliser OAuth 2.0/OIDC pour fédérer l’identité depuis un fournisseur d’identité externe vers Amazon Redshift. Tableau Bridge peut être utilisé comme solution de contournement sur Tableau Cloud jusqu’à ce que cette fonctionnalité soit disponible. Pour plus d’informations sur Bridge, consultez Utiliser Tableau Bridge pour garder les données à jour.

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.

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 fichiers de configuration OAuth sur des ordinateurs de bureau et des sites Tableau Server ou Tableau Cloud.

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

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

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 nous avons 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 est également hors de notre contrôle.

La meilleure façon de diagnostiquer ces erreurs est de supprimer Tableau de l’image. Vous devez d’abord obtenir un jeton d’identification (par défaut) ou un jeton d’accès (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. Vous trouverez ci-dessous un exemple d’utilisation du gestionnaire de pilotes ODBC sous Windows. 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.

Retour en haut

Merci de vos commentaires !

Avis correctement envoyé. Merci

Aide de Tableau Cloud