SSO Power BI pour Snowflake

Ce chapitre décrit l’utilisation de Microsoft Power BI pour instancier une session Snowflake et accéder à Snowflake à l’aide de l’authentification unique (SSO).

Dans ce chapitre :

Vue d’ensemble

Snowflake permet aux utilisateurs de Microsoft Power BI de se connecter à Snowflake à l’aide d’informations d’identification d’un fournisseur d’identité et d’une mise en œuvre de OAuth 2.0 pour fournir une expérience SSO afin d’accéder aux données Snowflake.

Cette fonctionnalité élimine le besoin de mises en œuvre de passerelles Power BI locales, car le service Power BI utilise un pilote Snowflake intégré pour se connecter à Snowflake.

Workflow général

Le diagramme suivant résume le flux d’autorisation pour instancier une session Snowflake à partir de Power BI :

pbi sso workflow overview
  1. L’utilisateur se connecte au service Power BI à l’aide de Microsoft Azure Active Directory (Azure AD).

  2. (Facultatif) Si le fournisseur d’identité n’est pas Azure AD, Azure AD vérifie l’utilisateur via l’authentification SAML avant de connecter l’utilisateur au service Power BI.

  3. Lorsque l’utilisateur se connecte à Snowflake, le service Power BI demande à Azure AD de lui donner un jeton pour Snowflake.

  4. Le service Power BI utilise le pilote Snowflake intégré pour envoyer le jeton Azure AD à Snowflake dans le cadre de la chaîne de connexion.

  5. Snowflake valide le jeton, extrait le nom d’utilisateur du jeton, le mappe à l’utilisateur Snowflake et crée une session Snowflake pour le service Power BI en utilisant le rôle par défaut de l’utilisateur.

Conditions préalables

Pour votre compte Snowflake, veuillez vérifier les points suivants avant d’utiliser la fonction Power BI SSO :

  • Dans Snowflake, si vous utilisez Politiques réseau, vous pouvez autoriser la plage IP Microsoft Azure qui inclut la région Azure où votre compte Snowflake est hébergé et toutes les régions Azure supplémentaires si nécessaire.

    Important

    Pour créer une politique réseau spécifique à Power BI pour la région Azure où se trouve votre compte Snowflake sur Azure, recherchez le téléchargement JSON auprès de Microsoft pour votre région.

    Par exemple, si votre compte Snowflake sur Azure est situé dans la région Centre du Canada, recherchez le téléchargement JSON pour PowerBI.CanadaCentral. Sélectionnez les plages d’adresses IP dans la liste addressPrefixes. Utilisez ces plages d’adresses IP pour créer ou mettre à jour une politique réseau dans Snowflake.

    Si la liste addressPrefixes est vide, veuillez contacter Microsoft pour demander une mise à jour.

    Si vous utilisez plusieurs services Microsoft Azure (par exemple, Power BI, SCIM), contactez votre administrateur Azure pour vérifier les plages d’adresses IP correctes afin de vous assurer que la politique réseau Snowflake contient les plages d’adresses IP appropriées pour permettre aux utilisateurs d’accéder à Snowflake.

  • S’il est nécessaire d’utiliser le rôle Snowflake ACCOUNTADMIN ou SECURITYADMIN pour un utilisateur, contactez le support Snowflake.

    Note

    Par défaut, les rôles d’administrateur de compte (c’est-à-dire les utilisateurs avec le rôle système ACCOUNTADMIN) et d’administrateur de sécurité (c’est-à-dire les utilisateurs avec le rôle système SECURITYADMIN) sont bloqués pour empêcher l’utilisation de Microsoft Power BI pour instancier une session Snowflake. Si votre entreprise a besoin d’autoriser ces rôles et que votre équipe de sécurité est à l’aise pour le permettre, contactez l’assistance Snowflake pour demander que ces rôles soient autorisés pour votre compte.

  • L’attribut login_name, name, ou email de l’utilisateur dans Snowflake doit correspondre à l’attribut Azure AD upn. Si l’attribut login_name n’est pas défini, le processus prend par défaut l’attribut name.

Considérations

Avec la passerelle Power BI

AWS PrivateLink et Azure Private Link sont pris en charge. S’il est nécessaire d’utiliser l’un de ces deux services pour vous connecter à Snowflake, utilisez la passerelle locale.

Sans la passerelle Power BI

AWS PrivateLink and Azure Private Link are not supported. For the Power BI Service and Power BI Desktop, create a network policy to allow the Azure Active Directory public IP address ranges. Note that network policies have a 100,000 character limit for the allowed IP addresses.

Jetons et clés

Snowflake tente une vérification Azure Active Directory par la valeur URL de la propriété external_oauth_jws_keys_url (illustrée ci-dessous) ou par les adresses IP autorisées dans la politique réseau, si celle-ci existe. Microsoft met à jour ses jetons et ses clés toutes les 24 heures. Pour plus d’informations sur les mises à jour de Microsoft, voir Vue d’ensemble des jetons dans Azure Active Directory B2C.

Prise en main

Cette section explique comment créer une intégration de sécurité Power BI dans Snowflake et comment accéder à Snowflake via Power BI.

Création d’une intégration de sécurité Power BI

Note

Cette étape n’est pas requise si vous utilisez la passerelle Power BI pour le service Power BI afin de vous connecter à Snowflake ou si vous utilisez votre nom d’utilisateur et votre mot de passe Snowflake pour l’authentification.

Pour utiliser Power BI afin d’accéder aux données Snowflake via SSO, il est nécessaire de créer une intégration de sécurité pour Power BI à l’aide de CREATE SECURITY INTEGRATION comme illustré ci-dessous.

L’intégration de sécurité doit avoir la valeur correcte pour le paramètre external_oauth_issuer. Une partie de cette valeur correspond à votre client Azure AD. Vous pouvez trouver cette valeur dans la section About de votre client Power BI.

Si votre organisation dispose d’un déploiement avancé du service Power BI, contactez votre administrateur Azure AD pour obtenir la valeur correcte du client Azure AD à utiliser lors de la conception de l’URL de l’émetteur.

Par exemple, si l’ID de votre client Azure AD est a828b821-f44f-4698-85b2-3c6749302698, créez la valeur AZURE_AD_ISSUER similaire à https://sts.windows.net/a828b821-f44f-4698-85b2-3c6749302698/. Il est important d’inclure la barre oblique (c’est-à-dire /) à la fin de la valeur.

Après avoir construit la valeur de AZURE_AD_ISSUER, exécutez la commande CREATE SECURITY INTEGRATION. Veillez à définir correctement la valeur du paramètre d’intégration de sécurité external_oauth_audience_list selon que votre compte Snowflake se trouve ou non dans la région du cloud Microsoft Azure Government.

Ces exemples utilisent également le rôle ANY, qui permet de changer de rôle. Pour plus d’informations, voir Utilisation du rôle ANY avec SSO de Power BI pour Snowflake.

Intégration de la sécurité pour Microsoft Power BI

create security integration powerbi
    type = external_oauth
    enabled = true
    external_oauth_type = azure
    external_oauth_issuer = '<AZURE_AD_ISSUER>'
    external_oauth_jws_keys_url = 'https://login.windows.net/common/discovery/keys'
    external_oauth_audience_list = ('https://analysis.windows.net/powerbi/connector/Snowflake')
    external_oauth_token_user_mapping_claim = 'upn'
    external_oauth_snowflake_user_mapping_attribute = 'login_name'
    external_oauth_any_role_mode = 'ENABLE';

Intégration de la sécurité Microsoft Azure Government pour Microsoft Power BI

create security integration powerbi_mag
    type = external_oauth
    enabled = true
    external_oauth_type = azure
    external_oauth_issuer = '<AZURE_AD_ISSUER>'
    external_oauth_jws_keys_url = 'https://login.windows.net/common/discovery/keys'
    external_oauth_audience_list = ('https://analysis.usgovcloudapi.net/powerbi/connector/snowflake')
    external_oauth_token_user_mapping_claim = 'upn'
    external_oauth_snowflake_user_mapping_attribute = 'login_name'
    external_oauth_any_role_mode = 'ENABLE';

Important

Seuls les administrateurs de compte (c’est-à-dire les utilisateurs dotés du rôle ACCOUNTADMIN) ou un rôle disposant du privilège global CREATE INTEGRATION peuvent exécuter cette commande SQL.

Les valeurs des paramètres d’intégration de sécurité sont sensibles à la casse et les valeurs que vous insérez dans l’intégration de sécurité doivent correspondre à ces valeurs dans votre environnement. Si la casse ne correspond pas, il est possible que le jeton d’accès ne soit pas validé, ce qui entraînera l’échec d’une tentative d’authentification.

Vérifiez que toutes les valeurs des paramètres correspondent exactement. Par exemple, si la valeur de l’URL <AZURE_AD_ISSUER> ne se termine pas par une barre oblique inverse et que l’intégration de sécurité est créée avec un caractère barre oblique inverse à la fin de l’URL, un message d’erreur se produit. Il serait alors nécessaire de supprimer l’objet d’intégration de sécurité (en utilisant DROP INTEGRATION), puis de recréer l’objet avec la valeur d’URL correcte (en utilisant CREATE SECURITY INTEGRATION).

Dans votre environnement, si la valeur d’attribut UPN de l’utilisateur correspond au champ de messagerie de l’utilisateur au lieu de login_name dans Snowflake, remplacez login_name par email_address. Par exemple :

create security integration powerbi
    type = external_oauth
    ...
    external_oauth_snowflake_user_mapping_attribute = 'email_address';

Utilisation de SSO de Power BI avec des utilisateurs invités B2B

Pour permettre aux utilisateurs invités business to business (c’est-à-dire B2B) d’Azure AD d’accéder à Snowflake en utilisant SSO depuis Microsoft Power BI, définissez la valeur de la propriété EXTERNAL_OAUTH_TOKEN_USER_MAPPING_CLAIM sur 'unique_name'. Par exemple :

create security integration powerbi
  type = external_oauth
  enabled = true
  external_oauth_type = azure
  external_oauth_issuer = '<AZURE_AD_ISSUER>'
  external_oauth_jws_keys_url = 'https://login.windows.net/common/discovery/keys'
  external_oauth_audience_list = ('https://analysis.windows.net/powerbi/connector/Snowflake')
  external_oauth_token_user_mapping_claim = 'unique_name'
  external_oauth_snowflake_user_mapping_attribute = 'login_name';

Pour plus d’informations, voir Comprendre l’utilisateur B2B.

Modification de votre intégration de sécurité externe OAuth

Vous pouvez mettre à jour votre intégration de sécurité externe OAuth en exécutant une instruction ALTER sur l’intégration de sécurité.

Pour plus d’informations, voir ALTER SECURITY INTEGRATION.

Utilisation du rôle ANY avec SSO de Power BI pour Snowflake

Dans l’étape de configuration visant à créer une intégration de sécurité dans Snowflake, le jeton d’accès OAuth inclut la définition du champ d’application. Par conséquent, au moment de l’exécution, l’utilisation de l’intégration de sécurité externe OAuth ne permet ni au client OAuth ni à l’utilisateur d’utiliser un rôle non défini dans le jeton d’accès OAuth.

Après avoir validé le jeton d’accès et créé une session, le rôle ANY peut permettre au client et à l’utilisateur OAuth de décider de son rôle. Si nécessaire, le client ou l’utilisateur peut basculer vers un rôle différent de celui défini dans le jeton d’accès OAuth.

Pour configurer le rôle ANY, définissez le champ d’application en tant que SESSION:ROLE-ANY et configurez l’intégration de la sécurité avec le paramètre external_oauth_any_role_mode. Ce paramètre peut avoir trois valeurs de chaîne possibles :

  • DISABLE n’autorise pas le client ou l’utilisateur OAuth à changer de rôle (c’est-à-dire use role <rôle>;). Par défaut.

  • ENABLE permet au client ou à l’utilisateur OAuth de changer de rôle.

  • ENABLE_FOR_PRIVILEGE permet au client ou à l’utilisateur OAuth de changer de rôle uniquement pour un client ou un utilisateur avec le privilège USE_ANY_ROLE. Ce privilège peut être accordé et révoqué à un ou plusieurs rôles disponibles pour l’utilisateur. Par exemple :

    grant USE_ANY_ROLE on integration external_oauth_1 to role1;
    
    revoke USE_ANY_ROLE on integration external_oauth_1 from role1;
    

Définissez l’intégration de la sécurité comme suit :

create security integration external_oauth_1
    type = external_oauth
    enabled = true
    external_oauth_any_role_mode = 'ENABLE'
    ...

Connexion à Snowflake depuis Power BI

Pour plus de détails sur la connexion à Snowflake depuis Power BI, reportez-vous à la documentation Power BI.

Utilisation de politiques réseau avec OAuth externe

Actuellement, les politiques réseau ne peuvent pas être ajoutées à votre intégration de sécurité OAuth externe.

Si votre cas d’utilisation nécessite OAuth et une politique réseau Snowflake, utilisez Snowflake OAuth.

Pour plus d’informations, voir OAuth et politiques réseau.

Dépannage

  • Reprise de l’entrepôt. Si un utilisateur donné tente d’utiliser un entrepôt suspendu, Microsoft Power BI affiche un message d’erreur qui n’est pas décrit dans Messages d’erreur. Vérifiez et si nécessaire, configurez l’entrepôt pour qu’il reprenne automatiquement pour résoudre le message d’erreur. Pour plus d’informations, voir Démarrage/reprise d’un entrepôt.

  • Lors de la tentative de connexion de Power BI à Snowflake, des erreurs peuvent se produire. Selon le message d’erreur, il peut être nécessaire de procéder à un dépannage lié à Microsoft, Snowflake ou les deux.

    • Messages d’erreur décrit les messages d’erreur courants que Snowflake peut renvoyer et qui s’affichent dans Power BI.

    • Historique de connexion décrit comment utiliser Snowflake pour vérifier si ou quand un utilisateur a accédé à Snowflake pour la dernière fois.

Messages d’erreur

Le tableau suivant décrit les messages d’erreur renvoyés par Snowflake pendant qu’un utilisateur s’authentifie dans Power BI :

Comportement

Message d’erreur

Action de dépannage

Jeton d’accès ou valeur d’audience non valide.

Échec de la mise à jour des informations d’identification de la source de données : ODBC:ERROR [28000] Jeton d’accès OAuth non valide. [<number>].

Vérifiez que le paramètre external_oauth_issuer contient la valeur correcte. . Dans Azure AD, vérifiez que le jeton d’accès est à jour.

Utilisateur AAD introuvable dans le compte Snowflake.

Échec de la mise à jour des informations d’identification de la source de données : ODBC:ERROR [28000] Un nom d’utilisateur ou un mot de passe incorrect a été spécifié.

Vérifiez que l’utilisateur existe dans Snowflake (la valeur d’attribut name ou login_name correspond à la valeur UPN de l’utilisateur dans Azure AD).

Utilisateur Snowflake présent, mais désactivé.

Échec de la mise à jour des informations d’identification de la source de données : ODBC:ERROR [28000] Accès utilisateur désactivé. Contactez votre administrateur système local.

Dans Snowflake, exécutez desc user <nom_utilisateur> pour vérifier si l’attribut disabled est défini sur true. Si vous souhaitez que cet utilisateur soit autorisé, exécutez alter user <nom_utilisateur> set disabled = true;. Essayez à nouveau d’accéder à nouveau à Snowflake depuis Power BI.

Snowflake reçoit un jeton AAD expiré de Power BI.

Échec de la mise à jour des informations d’identification de la source de données : ODBC:ERROR [28000] Jeton d’accès OAuth expiré. [<number>].

Contactez le support Snowflake.

Intégration de sécurité non créée ou désactivée dans le compte Snowflake.

Échec de la mise à jour des informations d’identification de la source de données : ODBC:ERROR [28000] L’intégration du serveur Authz OAuth n’est pas activée.

Exécutez desc <nom_intégration_sécurité> pour vérifier ou recréer l’intégration de sécurité.

Le rôle par défaut n’est pas défini pour l’utilisateur.

Échec de la mise à jour des informations d’identification de la source de données : ODBC: ERROR [28000] Aucun rôle par défaut n’a été attribué à l’utilisateur, contactez un administrateur système local pour attribuer un rôle par défaut et réessayez.

Définissez le rôle par défaut de l’utilisateur.

Le rôle par défaut de l’utilisateur n’est pas accordé à l’utilisateur.

Le test a échoué en raison de 250001 (08001) : Impossible de se connecter à DB : <host>. Le rôle par défaut configuré de l’utilisateur “<ROLE>” n’est pas accordé à cet utilisateur. Contactez votre administrateur système local ou essayez de vous connecter à l’aide d’un client CLI avec une chaîne de connexion en sélectionnant un autre rôle, par exemple PUBLIC.

Vérifiez le rôle par défaut de l’utilisateur et accordez-le-lui.

Historique de connexion

Si un utilisateur est en mesure d’accéder à Power BI, mais pas d’instancier une session Snowflake, vous pouvez déterminer quand l’utilisateur a accédé à Snowflake pour la dernière fois en exécutant les commandes suivantes à l’aide de n’importe quel connecteur pris en charge ou de l’interface Web Snowflake. Notez que seules les authentifications réussies sont enregistrées.

use role accountadmin;
select *
from table(information_schema.login_history(dateadd('hours',-1,current_timestamp()),current_timestamp()))
order by event_timestamp;

Pour chaque résultat, testez les colonnes USER_NAME et FIRST_AUTHENTICATION_FACTOR.

  • La valeur USER_NAME doit s’aligner aux mappages d’attributs décrits dans la section Conditions préalables.

  • Le FIRST_AUTHENTICATION_FACTOR doit être défini sur OAUTH_ACCESS_TOKEN.