Présentation de OAuth externe

OAuth externe s’intègre au serveur OAuth 2.0 du client pour fournir une expérience SSO transparente, en particulier pour les applications clientes programmatiques se connectant à Snowflake. Les chapitres relatifs à OAuth externe décrivent comment configurer OAuth externe à l’aide de OAuth 2.0 pour permettre un accès automatique sécurisé aux données Snowflake pour les serveurs d’autorisation pris en charge, les clients personnalisés et les applications partenaires prises en charge.

Snowflake prend en charge trois serveurs OAuth externes, une intégration personnalisée et une application partenaire.

  1. Okta

  2. Microsoft Azure AD

  3. Ping Identity PingFederate

  4. Clients personnalisés OAuth externes

  5. SSO Power BI pour Snowflake

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, voir Champs d’application (dans ce chapitre).

Dans ce chapitre :

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 et SECURITYADMIN sont bloqués par défaut. S’il est nécessaire d’utiliser l’un ou les deux de ces deux rôles, veuillez contacter l’assistance Snowflake.

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

  • Pour Azure AD, voir É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 de rôle

Description

session:role-any

Correspond au rôle ANY dans Snowflake. . Si le rôle par défaut de l’utilisateur dans Snowflake est souhaitable, transmettez ce champ d’application dans le jeton OAuth externe. . Le paramètre external_oauth_any_role_mode d’intégration de sécurité doit être configuré afin d’activer le rôle ANY pour un fournisseur externe OAuth donné. . Pour plus d’informations sur la configuration, consultez la section ANY Rôle dans Okta, Azure AD, PingFederate, ou Personnalisé.

session:role:<rôle_personnnalisé>

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.

Dépannage