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 :
L’utilisateur se connecte au service Power BI à l’aide de Microsoft Azure Active Directory (Azure AD).
En option, Azure AD peut vérifier l’utilisateur par l’intermédiaire d’un IdP via SAML. Actuellement, Microsoft ne prend en charge qu’Azure AD en tant que IdP pour Power BI SSO.
Lorsque l’utilisateur se connecte à Snowflake, le service Power BI demande à Azure AD de lui donner un jeton pour Snowflake.
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.
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 Contrôle du trafic réseau avec des politiques réseau, vous devez 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 listeaddressPrefixes
. 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.
L’attribut
login_name
,name
, ouemail
de l’utilisateur dans Snowflake doit correspondre à l’attribut Azure ADupn
. Si l’attributlogin_name
n’est pas défini, le processus prend par défaut l’attributname
.
Considérations¶
- Avec la passerelle Power BI:
La connectivité privée au service Snowflake est prise 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:
La connectivité privée au service Snowflake n’est pas prise en charge. Pour Power BI Service et Power BI Desktop, créez une politique réseau pour autoriser les plages d’adresses IP publiques d’Azure Active Directory. Notez que les politiques réseau ont une limite de 100 000 caractères pour les adresses IP autorisées.
- 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.- Définition des rôles autorisés:
Par défaut, les rôles système ACCOUNTADMIN, ORGADMIN et SECURITYADMIN ne peuvent pas utiliser Microsoft Power BI pour instancier une session Snowflake. S’il est nécessaire d’utiliser ces rôles à hauts privilèges, mettez à jour le paramètre d’intégration de sécurité
EXTERNAL_OAUTH_ALLOWED_ROLES
pour spécifier ces rôles. Faites preuve de prudence avant de spécifier les rôles système ACCOUNTADMIN, ORGADMIN et SECURITYADMIN dans le paramètre d’intégration de sécuritéEXTERNAL_OAUTH_ALLOWED_ROLES
.Pour plus d’informations, voir CREATE SECURITY INTEGRATION et ALTER SECURITY INTEGRATION.
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.
Si votre compte Snowflake ou votre service Microsoft Power BI se trouve dans la région du Cloud Microsoft Azure Government, définissez la valeur de la propriété external_oauth_audience_list
sur https://analysis.usgovcloudapi.net/powerbi/connector/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', 'https://analysis.windows.net/powerbi/connector/snowflake') external_oauth_token_user_mapping_claim = 'upn' external_oauth_snowflake_user_mapping_attribute = 'login_name'
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', 'https://analysis.usgovcloudapi.net/powerbi/connector/snowflake') external_oauth_token_user_mapping_claim = 'upn' external_oauth_snowflake_user_mapping_attribute = 'login_name'
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.
Les valeurs de liste que vous spécifiez pour la propriété EXTERNAL_OAUTH_AUDIENCE_LIST
sont des URLs avec un nom Snowflake en majuscules et en minuscules. Incluez les deux URLs dans cette liste pour vous assurer que votre client peut se connecter à Snowflake sur la base des valeurs que Microsoft pourrait attendre pour former une connexion.
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 hôtes 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', '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 (External OAuth).
Utilisation de rôles secondaires avec SSO de Power BI pour Snowflake¶
Le champ d’application souhaité pour le rôle primaire est transmis dans le jeton externe. Ce rôle est un rôle spécifique qui a été accordé à l’utilisateur (session:role:<nom_du_rôle>
).
Par défaut, les rôles secondaires par défaut d’un utilisateur (c’est-à-dire la propriété utilisateur DEFAULT_SECONDARY_ROLES) ne sont pas activés dans la session.
Pour activer les rôles secondaires par défaut pour un utilisateur dans une session et autoriser l’exécution de la commande USE SECONDARY ROLES tout en utilisant External OAuth, effectuez cette étape :
Configurez l’intégration de la sécurité pour la connexion. Définissez la valeur du paramètre EXTERNAL_OAUTH_ANY_ROLE_MODE comme ENABLE ou ENABLE_FOR_PRIVILEGE lorsque vous créez l’intégration de sécurité (à l’aide de CREATE SECURITY INTEGRATION) ou ultérieurement (à l’aide de ALTER SECURITY INTEGRATION).
Utilisation de la redirection des clients avec BI SSO vers Snowflake¶
Snowflake prend en charge l’utilisation de la redirection des clients avec Power BI SSO vers Snowflake.
Pour plus d’informations, voir Rediriger les connexions du client.
Utilisation de la réplication avec SSO de Power BI¶
Snowflake prend en charge la réplication et le basculement/la restauration de l’intégration de sécurité External OAuth d’un compte source à un compte cible.
Pour plus de détails, voir Réplication des intégrations de sécurité et des politiques réseau sur plusieurs comptes.
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 External OAuth¶
Actuellement, les politiques de réseau ne peuvent pas être ajoutées à une intégration de sécurité OAuth externe, ce qui signifie que vous ne pouvez pas définir une politique réseau qui s’applique uniquement à l’intégration Power BI. Cependant, vous pouvez toujours mettre en œuvre des politiques de réseau qui s’appliquent largement à l’ensemble du compte Snowflake. Pour plus d’informations sur la plage d’IP Microsoft qui doit être incluse dans la politique réseau, voir la section Conditions préalables (dans cette rubrique).
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 ou 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 |
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 |
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 |
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 |
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 surOAUTH_ACCESS_TOKEN
.