Présentation de External OAuth

Cette rubrique vous apprend à configurer des serveurs External OAuth qui utilisent OAuth 2.0 pour accéder à Snowflake.

External OAuth intègre le serveur OAuth 2.0 du client pour fournir une expérience SSO transparente, permettant l’accès client externe à Snowflake.

Snowflake prend en charge les serveurs d’autorisation externes, les clients personnalisés et les applications partenaires suivants :

Après avoir configuré le serveur externe OAuth de votre organisation, qui inclut tous les mappages OAuth 2.0 de champs d’application nécessaires aux rôles Snowflake, l’utilisateur peut se connecter à Snowflake de manière sécurisée et automatique sans avoir à saisir de facteurs ou de méthodes d’authentification ou d’autorisation supplémentaires. L’accès de l’utilisateur aux données Snowflake dépend à la fois de son rôle et du rôle intégré dans le jeton d’accès pour la session. Pour plus d’informations, reportez-vous à Champs d’application (dans cette rubrique).

Cas d’utilisation et avantages

  1. Snowflake délègue l’émission de jetons à un serveur d’autorisation dédié pour s’assurer que le client OAuth et l’utilisateur s’authentifient correctement. Le résultat est une gestion centralisée des jetons émis pour Snowflake.

  2. Les clients peuvent intégrer leurs politiques d’authentification (par exemple multifacteur, sous-réseau, biométrique) et d’autorisation (par exemple aucune approbation, approbation du gestionnaire requise) dans le serveur d’autorisation. Le résultat est une plus grande sécurité conduisant à une protection des données plus robuste en posant des défis à l’utilisateur. Si l’utilisateur ne réussit pas à relever le(s) défi(s) des politiques, la session Snowflake n’est pas instanciée et l’accès aux données Snowflake ne se produit pas.

  3. Pour les clients automatiques qui peuvent accéder à Snowflake et aux utilisateurs qui n’initient leurs sessions Snowflake que par un OAuth externe, aucune configuration d’authentification supplémentaire (c’est-à-dire la définition d’un mot de passe) n’est nécessaire dans Snowflake. Le résultat est que les comptes de service ou les utilisateurs utilisés exclusivement pour l’accès automatique ne pourront utiliser les données Snowflake qu’en passant par le service configuré OAuth externe.

  4. Les clients peuvent s’authentifier auprès de Snowflake sans accès au navigateur, ce qui facilite l’intégration avec le serveur externe OAuth.

  5. L’intégration de Snowflake aux serveurs externes OAuth est indépendante du cloud.

    • Cela ne fait aucune différence que le serveur d’autorisation existe dans le cloud d’un fournisseur de cloud ou si le serveur d’autorisation est on-premise. Le résultat est que les clients ont de nombreuses options en termes de configuration du serveur d’autorisation pour interagir avec Snowflake.

Workflow général

Pour chacun des fournisseurs d’identité pris en charge, le workflow pour OAuth relatif aux serveurs d’autorisation externes OAuth peut être résumé comme suit. Notez que la première étape ne se produit qu’une seule fois et les étapes restantes se produisent à chaque tentative d’accès aux données Snowflake.

workflow overview
  1. Configurez votre serveur d’autorisation OAuth externe dans votre environnement et l’intégration de sécurité dans Snowflake pour établir une confiance.

  2. Un utilisateur tente d’accéder aux données Snowflake via son application de Business Intelligence et l’application tente de vérifier l’utilisateur.

  3. Lors de la vérification, le serveur d’autorisation envoie un jeton Web JSON (c’est-à-dire un jeton OAuth) à l’application cliente.

  4. Le pilote Snowflake transmet une chaîne de connexion à Snowflake avec le jeton OAuth.

  5. Snowflake valide le jeton OAuth.

  6. Snowflake effectue une recherche d’utilisateur.

  7. Lors de la vérification, Snowflake instancie une session pour que l’utilisateur accède aux données dans Snowflake en fonction de son rôle.

Champs d’application

Le paramètre de champ d’application dans le serveur d’autorisation limite les opérations et les rôles autorisés par le jeton d’accès et ce à quoi l’utilisateur peut accéder après l’instanciation d’une session Snowflake.

Notez que les rôles ACCOUNTADMIN, ORGADMIN et SECURITYADMIN sont bloqués par défaut. S’il est nécessaire d’utiliser l’un ou plusieurs de ces rôles, utilisez la commande ALTER ACCOUNT pour définir le paramètre du compte EXTERNAL_OAUTH_ADD_PRIVILEGED_ROLES_TO_BLOCKED_LIST sur FALSE.

  • Pour Okta, PingFederate et personnalisé, utilisez le modèle de champ d’application de rôle dans le tableau suivant.

  • Pour Azure AD, reportez-vous à Étape préalable : déterminer le flux OAuth dans Azure AD

  • Si vous ne souhaitez pas gérer les rôles Snowflake dans votre serveur OAuth externe, transmettez la valeur statique de SESSION:ROLE-ANY dans l’attribut de champ d’application du jeton.

Le tableau suivant récapitule les champs d’application OAuth externes. Notez que si vous ne définissez pas de champ d’application, la tentative de connexion à Snowflake échouera.

Champ d’application/Paramètre de connexion du rôle

Description

session:role-any

Mappage du rôle ANY dans Snowflake.

Utilisez cette portée si le rôle par défaut de l’utilisateur dans Snowflake est souhaitable.

Le paramètre d’intégration de sécurité external_oauth_any_role_mode doit être configuré afin d’activer le rôle ANY pour un fournisseur External OAuth. Pour des détails sur la configuration, reportez-vous à la section de rôle ANY dans Okta, Azure AD, PingFederate, ou Personnalisé.

Notez qu’avec une intégration Power BI à Snowflake, l’utilisateur PowerBI ne peut pas changer de rôle en utilisant ce champ d’application.

session:role:custom_role

Correspond à un rôle Snowflake personnalisé. Par exemple, si votre rôle personnalisé est ANALYST, votre champ d’application est session:role:analyst.

session:role:public

Correspond au rôle PUBLIC Snowflake.

Utilisation de rôles secondaires avec External OAuth

Snowflake prend en charge l’utilisation de rôles secondaires avec External OAuth.

Snowflake OAuth ne prend pas en charge le basculement de rôle en session vers des rôles secondaires.

Pour plus d’informations, reportez-vous à :

Configuration de la prise en charge de External OAuth

Snowflake prend en charge l’utilisation d’applications partenaires et de clients personnalisés prenant en charge External OAuth.

Reportez-vous à la liste ci-dessous si vous devez configurer des applications partenaires ou des clients personnalisés :

OAuth et rôles secondaires

Snowflake prend en charge l’utilisation de rôles secondaires avec External Oauth.

Pour plus d’informations, reportez-vous à Utilisation de rôles secondaires avec External OAuth.

Codes d’erreur

Reportez-vous au tableau ci-dessous pour les descriptions des codes d’erreur associés à External OAuth :

Code d’erreur

Erreur

Description

390318

OAUTH_ACCESS_TOKEN_EXPIRED

Le jeton d’accès OAuth a expiré. {0}

390144

JWT_TOKEN_INVALID

Le jeton JWT n’est pas valide.

Dépannage

  • Utilisez la fonction SYSTEM$VERIFY_EXTERNAL_OAUTH_TOKEN pour déterminer si votre jeton d’accès OAuth externe est valide ou doit être régénéré.

  • Si vous rencontrez un message d’erreur associé à l’échec d’une tentative de connexion External OAuth et que le message d’erreur comporte un UUID, vous pouvez demander à un administrateur qui a un privilège MONITOR attribué à son rôle d’utiliser l’UUID du message d’erreur pour obtenir une description plus détaillée de l’erreur à l’aide de la fonction SYSTEM$GET_LOGIN_FAILURE_DETAILS.