Configurer l’authentification IAM sur Amazon Redshift

À partir de Tableau 2023.3.2 pour les installations sur site (Tableau Desktop, Tableau Server et Tableau Prep) et dès fin mars 2024 pour Tableau Cloud, vous pouvez utiliser l’OAuth 2.0/OIDC pour fédérer l’identité d’un fournisseur d’identité externe vers 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.

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.

Configurer l’IDP

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.
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.
Créez les 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). 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_ ».
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és ne prend pas en charge ce port, assurez-vous d’ajouter plusieurs URL de rappel localhost à la liste verte du fichier de configuration et du fournisseur d’identités.
Installez les fichiers de configuration Tableau OAuth sur les ordinateurs de bureau et sur les sites Tableau Server ou Tableau Cloud.

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(Le lien s’ouvre dans une nouvelle fenêtre) et Créer un fournisseur d’identité OIDC(Le lien s’ouvre dans une nouvelle fenêtre).

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

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

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

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(Le lien s’ouvre dans une nouvelle fenêtre).
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(Le lien s’ouvre dans une nouvelle fenêtre). Notez qu’il n’existe pas de pilote v2 pour OSX.

Résolution des problèmes

Lors de la première connexion, si le lecteur affiche un message d’erreur concernant un jeton non valide ou obsolète (le message d’erreur aura un code d’erreur SQLState tel que [28000] ou [08001]), le processus d’authentification a réussi, mais cette action a échoué dans le lecteur. Cela veut dire que la configuration n’a pas été correctement effectuée sur AWS ou sur le fournisseur d’identité. Le lecteur peut également avoir renvoyé des erreurs d’autorisation qui échappent à notre contrôle.

La meilleure façon de diagnostiquer ces erreurs est de supprimer Tableau. Vous devez d’abord obtenir un jeton d’identification (par défaut) ou un jeton d’accès (si vous l’avez personnalisé) qui sera envoyé au lecteur. 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. Voici un exemple de l’utilisation du gestionnaire de pilotes ODBC sous Windows. Sur 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.

Retour en haut

Merci de vos commentaires!

Votre commentaire s été envoyé avec succès. Merci!

Aide de Tableau Server sur Windows