Présentation de l’authentification fédérée et de SSO

Ce chapitre décrit les composants qui constituent un environnement fédéré pour l’authentification des utilisateurs et les workflows SSO (Single Sign-on) pris en charge par Snowflake.

Dans ce chapitre :

Qu’est-ce qu’un environnement fédéré ?

Dans un environnement fédéré, l’authentification des utilisateurs est séparée de l’accès des utilisateurs par l’utilisation d’une ou de plusieurs entités externes qui fournissent une authentification indépendante des informations d’identification des utilisateurs. L’authentification est ensuite transmise à un ou plusieurs services, permettant aux utilisateurs d’accéder aux services par SSO. Un environnement fédéré comprend les éléments suivants :

  • Fournisseur de services (SP) :

    Dans un environnement fédéré Snowflake, Snowflake sert de SP.

  • Fournisseur d’identité (IdP) :

    L’entité externe et indépendante chargée de fournir les services suivants au SP :

    • Création et mise à jour des informations d’identification des utilisateurs et d’autres informations de profil.

    • Authentification des utilisateurs pour l’accès SSO au SP.

Snowflake prend en charge la plupart des fournisseurs conformes SAML 2.0 en tant qu’IdP ; cependant, certains fournisseurs incluent une prise en charge native de Snowflake (voir ci-dessous pour plus de détails).

Fournisseurs d’identité pris en charge

Les fournisseurs suivants fournissent la prise en charge native de Snowflake pour l’authentification fédérée et le SSO :

  • Okta — service hébergé

  • Microsoft AD FS (Services ADFS) — logiciels sur site (installés sur Windows Server)

En plus de la prise en charge native de Snowflake fournie par Okta et AD FS, Snowflake prend en charge l’utilisation de la plupart des fournisseurs conformes SAML 2.0 en tant qu’IdP, y compris :

Note

Pour utiliser un IdP autre que Okta ou AD FS, vous devez définir une application personnalisée pour Snowflake dans l’IdP.

Pour plus de détails sur la configuration d’Okta, AD FS ou d’un autre fournisseur conforme SAML 2.0 comme IdP pour Snowflake, voir Configuration d’un fournisseur d’identité (IdP) pour Snowflake.

Workflows SSO pris en charge

L’authentification fédérée active les workflows SSO suivants :

  • Ouverture de session dans Snowflake.

  • Déconnexion de Snowflake.

  • Expiration du système en raison d’une période d’inactivité.

Le comportement de chaque workflow est déterminé par le fait que l’action est initiée dans Snowflake ou dans votre IdP.

Workflow de connexion

Lorsqu’un utilisateur se connecte, le comportement du système est déterminé par le fait que la connexion est initiée par Snowflake ou par IdP :

  • Ouverture de session à l’initiative de Snowflake :

    Pour vous connecter via Snowflake :

    1. L’utilisateur accède à l’interface Web de Snowflake.

    2. L’utilisateur choisit de se connecter en utilisant l’IdP configuré pour votre compte (Okta, AD FS ou un IdP personnalisé).

    3. L’utilisateur s’authentifie avec l’IdP en utilisant ses données d’identification pour l’IdP (par exemple, son adresse e-mail et son mot de passe).

    4. Si l’authentification est réussie, l’IdP envoie une réponse SAML à Snowflake pour lancer une session et affiche l’interface Web de Snowflake.

    Note

    Pour la connexion initiée par Snowflake, la page de connexion de Snowflake offre deux options d’authentification (IdP ou Snowflake). Pour utiliser l’authentification fédérée, les utilisateurs doivent choisir l’option IdP, puis entrer leurs identifiants lorsqu’on leur demande. Le choix de l’option Snowflake contourne l’authentification fédérée et connecte l’utilisateur en utilisant l’authentification native de Snowflake.

  • Ouverture de session à l’initiative d’IdP :

    Pour vous connecter à l’IdP pour votre compte :

    1. L’utilisateur se rend sur le site/l’application IdP et s’authentifie à l’aide de ses identifiants IdP (par exemple, son adresse e-mail et son mot de passe).

    2. Dans l’IdP, l’utilisateur clique sur l’application Snowflake (si elle utilise Okta ou AD FS) ou sur l’application personnalisée qui a été définie dans l’IdP (si elle utilise un autre IdP).

    3. L’IdP envoie une réponse SAML à Snowflake pour lancer une session, puis affiche l’interface Web de Snowflake.

Workflow de déconnexion

Lorsqu’un utilisateur se déconnecte, les options disponibles sont dictées par le fait que IdP prend en charge la déconnexion globale ou seulement la déconnexion standard :

Standard

Exige que les utilisateurs se déconnectent explicitement d’IdP et de Snowflake pour se déconnecter complètement. Tous les IdPs sont compatibles avec la déconnexion standard.

Global

Permet à un utilisateur de se déconnecter de l’IdP et par la suite de toutes ses sessions Snowflake. La prise en charge de la déconnexion globale dépend de l’IdP.

De plus, le comportement du système est déterminé par le fait que la déconnexion est initiée par Snowflake ou par IdP :

  • Déconnexion initiée par Snowflake :

    La déconnexion globale n’est pas prise en charge à partir de Snowflake, que l’IdP la prenne en charge ou non. Lorsqu’un utilisateur se déconnecte d’une session de Snowflake, il n’est déconnecté que de cette session. Toutes les autres sessions de Snowflake restent ouvertes, de même que la session IdP. Par conséquent, il peut continuer à travailler dans ses autres sessions ou il peut lancer des sessions supplémentaires sans avoir à se réauthentifier avec l’IdP.

    Pour se déconnecter complètement, l’utilisateur doit se déconnecter explicitement de Snowflake et de l’IdP.

  • Déconnexion à l’initiative d’IdP :

    Lorsqu’un utilisateur se déconnecte via un IdP, le comportement varie suivant le fait que l’IdP prend en charge la déconnexion standard uniquement ou également la déconnexion globale :

    • AD FS prend en charge la déconnexion standard et globale. Si la déconnexion globale est activée, la page de connexion AD FS IdP offre une option pour se déconnecter de tous les sites auxquels l’utilisateur a accès. Sélectionner cette option et cliquer sur Sign Out déconnecte l’utilisateur d’AD FS et de toutes ses sessions Snowflake. Pour accéder à nouveau à Snowflake, l’utilisateur doit se réauthentifier en utilisant AD FS.

    • Okta ne prend en charge que la déconnexion standard. Lorsqu’un utilisateur se déconnecte d’Okta, il n’est pas automatiquement déconnecté de ses sessions Snowflake actives et il peut continuer à travailler. Cependant, pour initier de nouvelles sessions Snowflake, il doit s’authentifier à nouveau via Okta.

    • Tous les fournisseurs personnalisés prennent en charge la déconnexion standard ; la prise en charge de la déconnexion globale varie selon le fournisseur.

    Note

    Pour un IdP sur le Web (p. ex. Okta), la fermeture de l’onglet ou de la fenêtre du navigateur ne met pas nécessairement fin à la session IdP. Si la session IdP d’un utilisateur est toujours active, celui-ci peut toujours accéder à Snowflake jusqu’à la fin de la session IdP.

Workflow d’expiration

Lorsque la session d’un utilisateur expire, le comportement varie en fonction de la session terminée (Snowflake ou IdP) :

  • Expiration de Snowflake :

    Si un utilisateur se connecte à Snowflake en utilisant SSO et que sa session Snowflake expire pour cause d’inactivité, l’interface Web de Snowflake est désactivée et l’invite d’authentification IdP s’affiche :

    • Pour continuer à utiliser la session Snowflake expirée, l’utilisateur doit s’authentifier à nouveau avec IdP.

    • L’utilisateur peut quitter la session en cliquant sur le bouton Cancel.

    • L’utilisateur peut aussi aller directement sur le site/l’application IdP et relancer Snowflake, mais cela initie une nouvelle session Snowflake.

  • Expiration d’IdP :

    Après une période de temps spécifiée (définie par l’IdP), la session d’un utilisateur dans l’IdP expire automatiquement, sans incidence sur ses sessions Snowflake. Toutes les sessions Snowflake qui sont actives au même moment restent ouvertes et n’ont pas besoin d’une nouvelle authentification. Cependant, pour lancer de nouvelles sessions Snowflake, l’utilisateur doit se connecter à nouveau à l’IdP.

SSO avec 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).

Actuellement, pour tout compte Snowflake donné, SSO fonctionne avec une seule URL de compte à la fois : l’URL de compte publique ou l’URL associée au service de connectivité privée sur AWS, Microsoft Azure ou Google Cloud Platform.

Snowflake prend en charge l’utilisation de SSO avec des organisations, et vous pouvez utiliser les URL correspondantes dans l’intégration de sécurité SAML2. Pour plus d’informations, voir Configuration de Snowflake pour l’utilisation de l’authentification fédérée.

Pour utiliser SSO avec une connectivité privée vers Snowflake, configurez la connectivité privée avant de configurer SSO :

Réplication de la configuration SSO

Snowflake prend en charge la réplication et le basculement/la restauration de l’intégration de sécurité SAML2 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.