Intégration Azure SCIM avec Snowflake

Snowflake prend en charge Microsoft Azure Active Directory en tant que fournisseur d’identité SCIM.

Ce guide décrit les étapes nécessaires à la configuration du provisionnement (dans Azure AD) pour les utilisateurs et les groupes Azure AD dans Snowflake, et comprend les sections suivantes :

Fonctionnalités

  • Provisionnement automatique d’utilisateurs Azure AD dans Snowflake.

  • Provisionnement automatique de groupes Azure AD dans Snowflake.

  • Synchronisation des utilisateurs et des groupes Azure AD avec Snowflake.

  • Si Azure AD est configuré pour le SSO (authentification unique) SAML sur Snowflake, les utilisateurs Azure AD provisionnés dans Snowflake peuvent accéder à Snowflake à l’aide du SSO SAML.

    Note

    Par défaut, aucun mot de passe n’est attribué dans Snowflake aux utilisateurs Azure AD provisionnés dans Snowflake à l’aide de SCIM. Cela signifie que si le SSO SAML est configuré dans Azure AD, les utilisateurs s’authentifieront auprès de Snowflake en utilisant le SSO.

    Le SSO SAML n’est pas obligatoire si vous utilisez SCIM pour provisionner des utilisateurs et des groupes Azure AD dans Snowflake. Pour plus d’options, voir Configurer l’authentification unique Azure AD.

Limites

  • Snowflake prend en charge un maximum de 500 demandes simultanées par compte par point de terminaison SCIM (par ex. le point de terminaison /Users, le point de terminaison /Groups). Une fois que votre compte a dépassé ce seuil, Snowflake renvoie un code de statut HTTP 429 (c’est-à-dire trop de demandes). Il convient de noter que cette limite de demandes n’intervient généralement que lors du provisionnement initial lorsqu’un nombre relativement important de demandes (c’est-à-dire plus de 10 000) est adressé en vue de provisionner des utilisateurs ou des groupes.

Non pris en charge

  • AWS PrivateLink. Les clients souhaitant provisionner des utilisateurs et des groupes dans Snowflake à partir de Microsoft Azure AD sans passer par l’Internet public doivent disposer de leur compte Snowflake dans Microsoft Azure.

  • Si vous utilisez Azure Private Link pour accéder à Snowflake, assurez-vous de ne pas utiliser l’URL Azure Private Link dans les paramètres d’intégration. Entrez le point de terminaison public (c’est-à-dire sans .privatelink) et assurez-vous que la politique réseau autorise l’accès à partir des adresses IP d’Azure comme indiqué dans la section Conditions préalables (dans cette rubrique), sinon vous ne pourrez pas utiliser cette intégration.

  • Transfert de la propriété des utilisateurs et des rôles existants. Azure AD est la source faisant autorité pour ses utilisateurs et ses groupes. L’appartenance à un groupe peut être mise à jour dans Azure AD. Toutefois, les utilisateurs et les groupes existants dans Snowflake ne peuvent pas être transférés vers Microsoft Azure AD.

  • Microsoft Azure AD ne prend actuellement pas en charge la lecture ou le provisionnement des groupes imbriqués. Par conséquent, vous ne pouvez pas utiliser l’intégration Snowflake Azure SCIM pour provisionner ou gérer des groupes imbriqués dans Snowflake. Veuillez contacter Microsoft pour demander la prise en charge des groupes imbriqués.

Conditions préalables

Avant d’utiliser SCIM pour provisionner des utilisateurs et des groupes Azure AD dans Snowflake, vérifiez que les conditions suivantes sont respectées :

  1. Un client Azure AD existant.

  2. Un client Snowflake existant.

    • Lors du processus de configuration dans Microsoft, vous devrez saisir l’URL de la base Snowflake (c’est-à-dire Tenant URL dans le guide de configuration de Microsoft Azure Active Directory SCIM) pour SCIM. L” URL de la base pour SCIM est l’URL du compte Snowflake avec /scim/v2/ en annexe. Par exemple, si votre nom de compte Snowflake est acme et votre région Azure est east-us-2, l’URL de la base pour SCIM est https://acme.east-us-2.azure.snowflakecomputing.com/scim/v2/.

  3. Au moins un utilisateur dans Snowflake avec le rôle ACCOUNTADMIN

  4. Avant de provisionner des utilisateurs ou des groupes, s’agissant de votre compte, assurez-vous que la politique réseau de Snowflake autorise l’accès à partir de toutes les adresses IP Azure AD du Cloud public ou du Cloud du gouvernement US. Actuellement, toutes les adresses IP Azure AD sont requises pour créer une politique réseau Azure SCIM. Pour plus d’informations, voir Gestion des politiques réseau SCIM.

Configuration

Le processus de configuration de Snowflake crée une intégration de sécurité SCIM pour permettre aux utilisateurs et aux rôles créés dans Azure AD d’être la propriété du rôle AAD_PROVISIONER SCIM dans Snowflake et crée un jeton d’accès à utiliser dans les demandes API SCIM. Le jeton d’accès (c’est-à-dire le Secret Token dans le guide de configuration de Microsoft Azure Active Directory SCIM) est valable six mois. À l’expiration, créez un nouveau jeton d’accès manuellement à l’aide de SYSTEM$GENERATE_SCIM_ACCESS_TOKEN comme indiqué ci-dessous.

Note

Pour invalider un jeton d’accès existant pour une intégration SCIM, exécutez une instruction DROP INTEGRATION.

Pour continuer à utiliser SCIM avec Snowflake, recréez l’intégration SCIM avec une instruction CREATE SECURITY INTEGRATION et générez un nouveau jeton d’accès en utilisant SYSTEM$GENERATE_SCIM_ACCESS_TOKEN.

Pour utiliser Microsoft Azure Active Directory en tant que fournisseur d’identité SCIM , suivez les instructions fournies dans la documentation Microsoft.

Pour faciliter la configuration de Snowflake, vous pouvez copier le code SQL ci-dessous pour l’utiliser lors de cette première étape. Chacune des instructions suivantes est expliquée ci-dessous.

use role accountadmin;
create role if not exists aad_provisioner;
grant create user on account to role aad_provisioner;
grant create role on account to role aad_provisioner;
grant role aad_provisioner to role accountadmin;
create or replace security integration aad_provisioning
    type = scim
    scim_client = 'azure'
    run_as_role = 'AAD_PROVISIONER';
select system$generate_scim_access_token('AAD_PROVISIONING');

Important

Les instructions SQL de l’exemple utilisent le rôle système ACCOUNTADMIN et le rôle personnalisé AAD_PROVISIONER est attribué au rôle ACCOUNTADMIN.

Il est possible de ne pas utiliser le rôle ACCOUNTADMIN en faveur d’un rôle moins privilégié. L’utilisation d’un rôle aux privilèges moins élevés peut aider à résoudre les problèmes de conformité liés à un accès moins privilégié, mais elle peut aussi entraîner des erreurs inattendues au cours du processus de configuration et de gestion SCIM.

Ces erreurs pourraient être dues au fait que le rôle moins privilégié ne dispose pas de droits suffisants pour gérer tous les rôles par SCIM en raison de la manière dont les rôles sont créés et de la hiérarchie des rôles qui en résulte. Par conséquent, afin d’éviter les erreurs dans les processus de configuration et de gestion, choisissez l’une des options suivantes :

  1. Utilisez le rôle ACCOUNTADMIN comme indiqué dans les instructions SQL d’exemple.

  2. Utilisez un rôle avec le privilège global MANAGE GRANTS.

  3. Si aucune de ces deux premières options n’est souhaitable, utilisez un rôle personnalisé qui dispose du privilège OWNERSHIP sur tous les rôles qui seront gérés à l’aide de SCIM.

  1. Connectez-vous à Snowflake en tant qu’administrateur et exécutez la procédure suivante à partir de l’interface de la feuille de calcul Snowflake ou de SnowSQL.

  2. Utilisez le rôle ACCOUNTADMIN.

    use role accountadmin;
    
  3. Créez le rôle personnalisé AAD_PROVISIONER. Tous les utilisateurs et les rôles dans Snowflake créés par Azure AD appartiendront au rôle AAD_PROVISIONER restreint.

    create role if not exists aad_provisioner;
    grant create user on account to role aad_provisioner;
    grant create role on account to role aad_provisioner;
    
  4. Laissez le rôle ACCOUNTADMIN créer l’intégration de sécurité à l’aide du rôle AAD_PROVISIONER personnalisé. Pour plus d’informations, voir CREATE SECURITY INTEGRATION.

    grant role aad_provisioner to role accountadmin;
    create or replace security integration aad_provisioning
        type=scim
        scim_client='azure'
        run_as_role='AAD_PROVISIONER';
    
  5. Créez et copiez le jeton d’autorisation dans le Presse-papiers et stockez-le de manière sécurisée pour une utilisation ultérieure. Utilisez ce jeton pour chaque requête API REST SCIM et placez-le dans l’en-tête de la requête. Le jeton d’accès expire après six mois et un nouveau jeton d’accès peut être généré avec cette instruction.

    select system$generate_scim_access_token('AAD_PROVISIONING');
    

Activation de la fonction SSO initiée par Snowflake

Le processus de provisionnement SCIM n’active pas automatiquement la connexion unique (SSO).

Pour utiliser SSO une fois le processus de provisionnement SCIM terminé, activez SSO initié par Snowflake.

Gestion des politiques réseau SCIM

La stratégie réseau SCIM a son propre paramètre, de façon à ce que le fournisseur SCIM puisse être spécifiquement autorisé à provisionner des utilisateurs et des groupes sans ajouter ces adresses IP pour un accès utilisateur normal.

La configuration d’une politique réseau spécifique à l’intégration SCIM permet à SCIM d’être distinct des autres politiques réseau qui peuvent s’appliquer au compte Snowflake. La politique réseau SCIM n’affecte pas les autres politiques réseau du compte et les autres politiques réseau du compte n’affectent pas la politique réseau SCIM. Par conséquent, la politique réseau SCIM permet à l’intégration Snowflake SCIM de provisionner des utilisateurs et des groupes comme prévu.

Après avoir créé l’intégration de sécurité SCIM, créez la politique réseau SCIM à l’aide de cette commande :

alter security integration aad_provisioning set network_policy = <politique_réseau_scim>;

Pour annuler la politique réseau SCIM, utilisez cette commande :

alter security integration aad_provisioning unset <politique_réseau_scim>;

Où :

aad_provisioning

Spécifie le nom de l’intégration de sécurité Azure AD SCIM.

<scim_network_policy>

Spécifie la politique réseau Azure AD SCIM dans Snowflake.

Pour plus d’informations, voir Politiques réseau et ALTER SECURITY INTEGRATION.

Utilisation de rôles secondaires avec SCIM

Snowflake prend en charge la configuration de la propriété user DEFAULT_SECONDARY_ROLE sur ALL avec SCIM pour permettre aux utilisateurs d’utiliser des rôles secondaires dans une session Snowflake.

Pour un exemple représentatif, voir PUT scim/v2/Users/{id}.

Astuces de dépannage

  • Pour vérifier qu’Azure AD envoie des mises à jour à Snowflake, vérifiez les événements de journal dans Azure AD pour l’application Snowflake et les journaux d’audit SCIM dans Snowflake pour vous assurer que Snowflake reçoit les mises à jour d’Azure AD. Utilisez le code SQL suivant pour interroger les journaux d’audit Snowflake SCIM.

    use role accountadmin;
    use database demo_db;
    use schema information_schema;
    select * from table(rest_event_history('scim'));
    select *
        from table(rest_event_history(
            'scim',
            dateadd('minutes',-5,current_timestamp()),
            current_timestamp(),
            200))
        order by event_timestamp;
    
  • Si la mise à jour de l’utilisateur échoue, vérifiez à qui appartient l’utilisateur dans Snowflake. S’il n’appartient pas au rôle aad_provisioner (ou au rôle défini dans le paramètre run_as_role lors de la création de l’intégration de sécurité dans Snowflake), la mise à jour échouera. Transférez la propriété en exécutant l’instruction SQL suivante dans Snowflake, puis réessayez.

    grant ownership on user <username> to role AAD_PROVISIONER;
    
  • En cas de modification de la valeur d’attribut UPN https://docs.microsoft.com/en-us/azure/active-directory/hybrid/plan-connect-userprincipalname#what-is-userprincipalname dans Azure AD après le provisionnement SCIM initial, les mises à jour ultérieures de l’utilisateur ne fonctionneront pas. Une modification de la valeur d’attribut UPN rompt le lien entre l’objet utilisateur Azure AD et l’objet utilisateur Snowflake. Si une modification de la valeur d’attribut UPN se produit, réapprovisionnez l’utilisateur avec la valeur d’attribut UPN correcte.

Chapitres suivants :