Présentation de External OAuth¶

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.

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.

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 à :

• Rôles secondaires avec Okta

• Rôles secondaires avec Azure

• Rôles secondaires avec PingFederate

• Rôles secondaires avec les clients personnalisés

• Utilisation de rôles secondaires avec SSO de Power BI pour Snowflake

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 :

• Configuration des applications partenaires

• Configuration de clients personnalisés configurés par votre organisation

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 :

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.