Gestion/Utilisation de l’authentification fédérée

Ce chapitre décrit comment gérer et utiliser l’authentification fédérée une fois qu’elle a été configurée.

Dans ce chapitre :

Gestion des utilisateurs avec l’authentification fédérée activée

Gestion des mots de passe utilisateur Snowflake

Avec l’authentification fédérée activée pour votre compte, Snowflake permet toujours de gérer et d’utiliser les informations d’identification d’utilisateur Snowflake (nom de connexion et mot de passe). En d’autres termes :

  • Les administrateurs de comptes et de sécurité peuvent toujours créer des utilisateurs avec des mots de passe gérés dans Snowflake.

  • Les utilisateurs peuvent toujours se connecter à Snowflake en utilisant leurs identifiants Snowflake.

Cependant, si l’authentification fédérée est activée pour votre compte, Snowflake ne recommande pas de gérer les mots de passe utilisateurs dans Snowflake. Au lieu de cela, les mots de passe d’utilisateurs doivent être conservés uniquement dans votre IdP.

Si vous créez un utilisateur sans mot de passe (ou si vous modifiez un utilisateur existant et supprimez son mot de passe), l’authentification Snowflake est désactivée pour cet utilisateur. Sans mot de passe dans Snowflake, un utilisateur ne peut pas se connecter en utilisant l’authentification Snowflake et doit plutôt utiliser l’authentification fédérée. Notez que vous ne pouvez pas utiliser l’interface Web de Snowflake pour créer des utilisateurs sans mots de passe ou supprimer des mots de passe d’utilisateurs existants. Vous devez utiliser CREATE USER ou ALTER USER.

Plus précisément, nous vous recommandons de désactiver l’authentification Snowflake pour tous les utilisateurs qui ne sont pas administrateurs.

Important

La propriété utilisateur MUST_CHANGE_PASSWORD ne s’applique pas à l’authentification fédérée et ne doit pas être utilisée. Plus précisément, si vous choisissez de ne pas gérer les mots de passe dans Snowflake pour les utilisateurs, assurez-vous que cette propriété est définie sur FALSE pour ces utilisateurs.

De plus, vous devez conserver au moins un administrateur de compte Snowflake avec un mot de passe Snowflake. Ainsi, un administrateur de compte peut accéder à Snowflake à tout moment pour gérer l’authentification fédérée et dépanner les problèmes qui surviennent.

Désactivation et suppression d’utilisateurs

En tant qu’administrateur de compte ou de sécurité dans Snowflake, vous devrez peut-être détruire ou, plus probablement, désactiver un utilisateur. Les utilisateurs qui sont détruits ou désactivés dans Snowflake peuvent toujours se connecter à leur compte Okta, mais ils recevront un message d’erreur lorsqu’ils tenteront de se connecter à Snowflake. Vous devez recréer ou activer l’utilisateur avant qu’il puisse se connecter.

Vous pouvez détruire/créer et désactiver/activer des utilisateurs à l’aide de l’interface Web de Snowflake ou des commandes SQL équivalentes.

Utilisation de SSO avec des applications clientes qui se connectent à Snowflake

Avec un IdP configuré pour votre compte, Snowflake prend en charge l’utilisation de SSO pour se connecter et s’authentifier avec les clients suivants fournis par Snowflake :

SnowSQL

v1.1.43 ou supérieur

Connecteur Python

v1.4.8 ou supérieur

Pilote JDBC

v3.2.7 ou supérieur

Pilote ODBC

v2.13.11 ou supérieur

Pilote .NET

v1.0.13 ou une version supérieure

Pilote Node.js

v1.6.0 ou supérieur (pour l’authentification SSO par navigateur) ; v1.6.1 ou supérieur (pour l’authentification SSO native par Okta)

Pilote Go

v1.1.5 ou version supérieure

Snowflake accepte deux méthodes d’authentification :

  • SSO basé sur le navigateur

  • SSO programmatique (seulement pour Okta)

Important

Lors de l’utilisation de SSO avec des applications clientes qui se connectent à Snowflake, les utilisateurs doivent entrer leurs identifiants de connexion lorsqu’on leur demande ; cependant, pour des raisons de sécurité, ces identifiants ne sont jamais traités par le client. En revanche, les informations d’identification sont envoyées à l’IdP pour être authentifiées, et l’IdP envoie une réponse SAML valide qui permet au client de lancer une session Snowflake.

SSO basé sur le navigateur

Sous réserve que les utilisateurs disposent de la version requise (ou supérieure) des clients installés fournis par Snowflake, ils peuvent utiliser SSO basé sur le navigateur pour se connecter à Snowflake.

Fonctionnement de SSO sur navigateur

Lorsqu’une application cliente est configurée pour utiliser un SSO basé sur le navigateur, l’application utilise le workflow suivant pour l’authentification des utilisateurs :

  1. L’application lance le navigateur Web par défaut dans le système d’exploitation de l’utilisateur ou ouvre un nouvel onglet/une nouvelle fenêtre de navigateur, affichant la page d’authentification pour l’IdP.

  2. L’utilisateur saisit ses identifiants IdP (nom d’utilisateur et mot de passe).

  3. Si l’utilisateur est inscrit dans MFA (authentification multi-facteurs) dans Snowflake, il est invité à saisir le mot de passe MFA (envoyé par un autre appareil) ou à confirmer l’authentification (sur l’autre appareil).

  4. Après que l’IdP a authentifié les informations d’identification de l’utilisateur, le navigateur affiche un message de confirmation. L’utilisateur peut alors fermer l’onglet ou la fenêtre du navigateur (il n’est pas nécessaire de l’ouvrir après l’authentification), revenir à l’application et utiliser la session Snowflake qui a été lancée.

Conditions requises pour utiliser SSO sur navigateur

Avec le SSO basé sur le navigateur, le client fourni par Snowflake (par exemple, le pilote JDBC de Snowflake) doit pouvoir ouvrir le navigateur Web de l’utilisateur. Pour cette raison, le client fourni par Snowflake et l’application cliente qui l’utilise doivent être installés sur le poste de l’utilisateur. Le SSO basé sur le navigateur ne fonctionne pas si le client fourni par Snowflake est utilisé par du code qui s’exécute sur un serveur.

Configuration de SSO sur navigateur

Pour configurer le SSO basé sur le navigateur en vue de l’authentification, définissez le paramètre/l’option de connexion authenticator sur externalbrowser pour le client.

Client

Instructions

SnowSQL

Spécifiez l’indicateur de ligne de commande --authenticator externalbrowser lors du démarrage du client.

Python

Validez authenticator='externalbrowser' dans la fonction snowflake.connector.connect().

JDBC

Définissez authenticator=externalbrowser dans la chaîne de connexion du pilote.

ODBC (Linux/macOS)

Définissez authenticator=externalbrowser dans le fichier odbc.ini.

ODBC (Windows)

Dans l’outil Administrateur de la source de données ODBC, modifiez le DSN de Snowflake et définissez Authenticator sur externalbrowser.

.NET

Définissez authenticator=externalbrowser dans la chaîne de connexion du pilote.

Node.js

Définir l’option authenticator=EXTERNALBROWSER lors de l’appel de la fonction snowflake.createConnection.

Go

Définissez authenticator=externalbrowser dans la chaîne de connexion du pilote.

Utilisation de la mise en cache de connexion pour réduire le nombre d’invites pour l’authentification — Facultatif

Chaque fois qu’une application cliente établit une nouvelle connexion à Snowflake, l’utilisateur est invité à s’authentifier. Cela peut entraîner plusieurs invites d’authentification si l’application cliente établit une connexion plusieurs fois.

Pour réduire le nombre de fois qu’un utilisateur est invité à s’authentifier, l’administrateur du compte peut activer la mise en cache de la connexion.

Lorsque la mise en cache de connexion est activée, l’application cliente stocke un jeton de connexion à utiliser dans les connexions suivantes. Pour des raisons de sécurité, le jeton de connexion est stocké dans le magasin de clés du système d’exploitation. Avant d’activer la mise en cache des connexions, consultez votre équipe de sécurité pour déterminer si cela est conforme à vos politiques de sécurité.

Astuce

La mise en cache des connexions peut être combinée avec la mise en cache des jetons MFA.

Pour plus d’informations sur la manière de combiner ces deux fonctions, voir Utilisation de la mise en cache des jetons MFA pour réduire le nombre d’invites lors de l’authentification — Facultatif.

Snowflake prend en charge la mise en cache des connexions avec les pilotes et connecteurs suivants sur macOS et Windows (actuellement, cette fonctionnalité n’est pas prise en charge sous Linux) :

  • Version du pilote Go 1.6.15 (ou ultérieure)

  • Version du pilote JDBC 3.12.8 (ou ultérieure)

  • Version du pilote ODBC 2.21.2 (ou ultérieure)

  • Connecteur Snowflake pour Python 2.2.8 (ou supérieur)

Pour activer la mise en cache de connexion :

  1. Définissez le paramètre au niveau du compte ALLOW_ID_TOKEN sur true :

    alter account set allow_id_token = true;
    
    Copy

    Note

    Vous devez être un administrateur de compte (c’est-à-dire un utilisateur avec le rôle ACCOUNTADMIN) pour activer la mise en cache des connexions.

  2. Ajoutez le paquet ou les bibliothèques requis par le pilote ou le connecteur :

    • Si vous utilisez le connecteur Snowflake pour Python, installez le paquet du « trousseau » facultatif en exécutant :

      pip install "snowflake-connector-python[secure-local-storage]"
      
      Copy

      Vous devez saisir les crochets ([ et ]) comme indiqué dans la commande. Les crochets spécifient la partie supplémentaire du paquet qui doit être installée.

      Utilisez des guillemets autour du nom du paquet (comme indiqué) pour éviter que les crochets ne soient interprétés comme des caractères génériques.

      Si vous devez installer d’autres « extras » (par exemple, pandas pour à l’aide des APIs du connecteur Python pour Pandas), utilisez une virgule entre les extras :

      pip install "snowflake-connector-python[secure-local-storage,pandas]"
      
      Copy
    • Pour le pilote JDBC Snowflake, voir Ajout de classes JNA à votre classpath.

Authentication SSO native — Okta uniquement

Si Okta est votre IdP, Snowflake prend également en charge l’authentification native via Okta. Cette méthode d’authentification est utile lorsque vous utilisez SSO avec un client qui n’a pas accès à un navigateur Web (par exemple, connexion programmatique via le connecteur Python ou le pilote JDBC ou ODBC).

Note

Veuillez désactiver Okta MFA pour l’utilisateur qui utilise l’authentification native SSO avec les pilotes clients. Veuillez consulter votre administrateur Okta pour plus d’informations.

Pour activer l’option native SSO via Okta, définissez le paramètre/l’option de connexion authenticator pour le client sur le point de terminaison de l’URL Okta pour votre compte Okta (fourni par Okta), généralement sous la forme : https://<nom_compte_okta>.okta.com :

Client

Instructions

SnowSQL

Spécifiez l’indicateur de ligne de commande --authenticator https://<nom_de_compte_okta>.okta.com lors du démarrage du client.

Python

Validez authenticator='https://<nom_de_compte_okta>.okta.com' dans la fonction snowflake.connector.connect().

JDBC

Définissez authenticator=https://<nom_de_compte_okta>.okta.com dans la chaîne de connexion du pilote.

ODBC (Linux/macOS)

Définissez authenticator=https://<nom_de_compte_okta>.okta.com dans le fichier odbc.ini.

ODBC (Windows)

Dans l’outil Administrateur de la source de données ODBC, modifiez le DSN de Snowflake et définissez Authenticator sur https://<nom_compte_okta>.okta.com.

.NET

Définissez authenticator=https://<nom_de_compte_okta>.okta.com dans la chaîne de connexion du pilote.

Node.js

Définissez l’option authenticator sur https://<nom_compte_okta>.okta.com lors de l’appel de snowflake.createConnection.

Mise à niveau vers Okta Identity Engine

Si vous mettez à jour Okta Classic vers Okta Identity Engine for native SSO, vous devez mettre à jour les pilotes de votre client Snowflake avant la mise à jour.

Si vous rencontrez des erreurs HTTP 429 après votre mise à niveau, vous avez probablement atteint la limite de débit imposée par le point de terminaison d’authentification utilisé par les derniers pilotes clients. Pour plus de détails, voir Erreurs HTTP 429 (dans cette rubrique).

Erreurs HTTP 429

Le moteur d’identité Okta nécessite une communication via son point de terminaison d’authentification (/api/v1/authn), qui a actuellement une limite de débit de 20 requêtes par utilisateur toutes les 5 secondes. Pour prendre en charge le moteur d’identité Okta, les derniers pilotes du client Snowflake utilisent ce point de terminaison d’authentification et sont donc soumis à la limite de débit. Si cette limite est prohibitive, contactez le support Okta pour augmenter la limite de débit du point de terminaison d’authentification.

Les pilotes clients Snowflake sont passés au point de terminaison d’authentification dans les versions suivantes :

  • Go : 1.6.20

  • JDBC : 3.13.22

  • .NET : 2.0.20

  • Node.js : 1.6.21

  • ODBC : 2.25.5

  • Python : 2.7.12

  • SnowSQL : 1.2.24

  • SQLAlchemy : 1.4.6

Utilisation de SSO avec MFA

Snowflake prend en charge l’utilisation de MFA conjointement avec SSO pour fournir des niveaux de sécurité supplémentaires :

  • Les utilisateurs individuels de Snowflake peuvent s’inscrire à MFA. Si un utilisateur Snowflake est inscrit à MFA et utilise SSO pour se connecter, le workflow de connexion de MFA est lancé dans le workflow SSO et est nécessaire pour mener à bien l’authentification. Pour plus d’informations sur MFA dans Snowflake, voir Authentification multifactorielle (MFA).

    Note

    Pour se connecter via le SSO Okta avec MFA, Snowflake nécessite l’utilisation de SSO sur navigateur. Si vous utilisez SSO en natif pour Okta, MFA n’est pas pris en charge.

  • De plus, votre IdP peut aussi prendre en charge MFA, mais ceci séparément de MFA dans Snowflake, et doit être configuré séparément via votre IdP. Si MFA est activé pour votre IdP, l” IdP détermine le workflow à appliquer. Pour déterminer si votre IdP prend en charge MFA et comment il est implémenté, consultez la documentation de votre IdP.

  • Avec certains clients fournis par Snowflake, vous pouvez mettre en cache les jetons MFA pendant quatre heures maximum. Pour plus d’informations, voir Utilisation de la mise en cache des jetons MFA pour réduire le nombre d’invites lors de l’authentification — Facultatif.

Utilisation de SSO avec plusieurs valeurs d’audience

Snowflake prend en charge plusieurs valeurs d’audience (c.-à-d. des champs Audience ou Restriction d’audience) dans l’assertion SAML 2.0 du fournisseur d’identité de Snowflake.

Cette fonctionnalité prend en charge les URLs permettant d’accéder à Snowflake en tant que valeurs d’audience. Les URLs de plusieurs comptes Snowflake sont prises en charge, car chaque compte a une URL avec un identificateur de compte unique pour accéder à Snowflake. En outre, Snowflake accepte les noms de domaine du compte et les URLs pour accéder à Snowflake en utilisant une connectivité privée au service Snowflake en tant que valeurs d’audience.

Pour plus de détails sur SSO et sur la façon d’éviter l’Internet public, voir SSO avec connectivité privée.

Snowflake prend actuellement en charge et accepte jusqu’à quatre valeurs d’audience différentes. Aucune configuration n’est nécessaire dans Snowflake. S’il est nécessaire d’inclure plus de quatre valeurs d’audience, veuillez contacter l’assistance Snowflake.

Pour obtenir de l’aide sur la configuration des valeurs d’audience SAML 2.0, veuillez contacter l’administrateur du fournisseur d’identité de votre entreprise.

Utilisation de SSO avec une connectivité privée

Snowflake prend en charge SSO avec une connectivité privée au service Snowflake pour les comptes Snowflake sur Amazon Web Services (AWS), Microsoft Azure et Google Cloud Platform (GCP).

Pour plus de détails, voir SSO avec connectivité privée.