Configurer l’authentification IAM sur Amazon Redshift

Depuis Tableau 2023.3.2, vous pouvez utiliser Oauth 2.0/OIDC pour fédérer l’identité d’un fournisseur d’identité externe dans 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.

Étape 1 : Configurer le jeton 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é ne prend pas en charge ce port, assurez-vous d’ajouter plusieurs URL de rappel localhost à la liste d’autorisations du fichier de configuration et du fournisseur d’identité.
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 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)).

Jetons

Par défaut, Redshift OAuth IAM transmet le jeton d’identification au pilote. Pour les clients locaux, notamment ceux qui utilisent Tableau Bridge, vous pouvez plutôt 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

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

La meilleure façon de diagnostiquer des erreurs est de supprimer Tableau. Par contre, vous pouvez effectuer un test en utilisant le gestionnaire de pilotes ou un outil similaire. Ceci sert uniquement à la résolution des problèmes : vous ne devez pas utiliser un DSN ou le connecteur « Autres bases de données ODBC » dans le cadre d’une utilisation régulière de cette fonctionnalité. Pour garantir la validité d’un test, les paramètres doivent être identiques, comme indiqué ci-dessous, à l’exception des informations relatives au groupement, à la base de données, au jeton et à l’espace de noms.

Lors de la première connexion, si vous recevez un message d’erreur du pilote concernant un jeton invalide ou expiré (il aura un code d’erreur SQLState [28000] ou [08001] dans le message d’erreur), alors Tableau a terminé le flux OAuth avec succès et a échoué avec le pilote. Cela veut dire que la configuration n’a pas été correctement effectuée sur AWS ou sur le fournisseur d’identité. Le pilote peut également retourner des autorisations ou des erreurs d’autorisation peuvent, ce qui échappe également au contrôle de Tableau.

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

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. 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 et qui se trouve dans le dossier customer-bin.

Tableau vous recommande de ne pas utiliser d’autres modules d’extension pour effectuer le test, car ils risquent de ne pas fonctionner dans un environnement serveur. Ils utilisent un profil AWS fixe ou ils requièrent un accès direct à un navigateur.

Voici un exemple de l’utilisation du gestionnaire de pilotes ODBC sous Windows.

Retour en haut

Merci de vos commentaires!

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

Aide de Tableau Server sur Windows