Intégration SCIM personnalisée avec Snowflake¶

Les intégrations personnalisées SCIM permettent aux utilisateurs de créer leurs propres applications pour se connecter à leur fournisseur d’identité afin de provisionner, mapper et gérer des utilisateurs et des rôles dans Snowflake.

Actuellement, les intégrations SCIM personnalisées sont prises en charge pour les fournisseurs d’identité qui ne sont ni Okta ni Microsoft Azure AD.

Après avoir créé votre application SCIM, suivez la procédure ci-dessous pour créer une intégration de sécurité Snowflake et générer un jeton d’autorisation API SCIM. Enregistrez le jeton d’autorisation et incluez-le dans l’en-tête de demande API SCIM comme décrit dans Réalisation d’une requête API SCIM.

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.
Si l’URL de votre compte Snowflake a été créée avec des traits de soulignement, vous pouvez accéder à votre compte Snowflake avec l’URL de compte ayant des traits de soulignement ou des tirets.

Si votre fournisseur SCIM réutilise la même URL de compte pour SAML SSO et SCIM, les URLs avec des traits de soulignement ne sont pas prises en charge. Par conséquent, utilisez l’URL de compte avec un trait d’union pour configurer SCIM.

Les URLs de comptes Snowflake qui ne contiennent pas de caractères de soulignement ne sont pas limitées par cette restriction.
Une intégration SCIM personnalisée peut permettre ou ne pas permettre le provisionnement et la gestion des groupes imbriqués. Avant d’essayer d’utiliser une intégration SCIM personnalisée pour provisionner des groupes imbriqués dans Snowflake, veuillez contacter votre fournisseur d’identité pour déterminer si les groupes imbriqués peuvent être utilisés avec une intégration SCIM.
Si vous utilisez une connectivité privée au service Snowflake pour accéder à Snowflake, assurez-vous de ne pas saisir ces URLs 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 de l’adresse IP IdP, sinon vous ne pourrez pas utiliser cette intégration.
- Notez que si votre compte IdP et votre compte Snowflake sont tous deux hébergés dans Microsoft Azure, il est nécessaire que la politique réseau de Snowflake permette l’accès à partir de toutes les adresses IP Azure AD pour le cloud public ou le le cloud du gouvernement US. Actuellement, toutes les adresses IP Azure AD sont requises dans la politique réseau. Pour plus d’informations, voir Gestion des politiques réseau SCIM.
Activation ou désactivation de la synchronisation des mots de passe entre un fournisseur d’identité personnalisé et Snowflake.

La définition de la propriété SYNC_PASSWORD dans l’intégration de sécurité Snowflake n’est prise en charge que pour les intégrations SCIM Okta.

Conditions préalables¶

Avant de provisionner des utilisateurs ou des groupes, assurez-vous que la politique réseau dans Snowflake autorise l’accès à partir des plages IP correspondant à votre organisation. Pour plus d’informations, voir Gestion des politiques réseau SCIM.

Créer une intégration de sécurité SCIM personnalisée et un jeton API¶

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 le fournisseur d’identité d’être la propriété du rôle GENERIC_SCIM_PROVISIONER SCIM dans Snowflake et crée un jeton d’accès à utiliser dans les requêtes SCIM API. Le jeton d’accès 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.

Exécutez les instructions SQL suivantes dans votre client Snowflake préféré. Chacune des instructions suivantes est expliquée ci-dessous.

use role accountadmin;
create role if not exists generic_scim_provisioner;
grant create user on account to role generic_scim_provisioner;
grant create role on account to role generic_scim_provisioner;
grant role generic_scim_provisioner to role accountadmin;
create or replace security integration generic_scim_provisioning
    type=scim
    scim_client='generic'
    run_as_role='GENERIC_SCIM_PROVISIONER';
select system$generate_scim_access_token('GENERIC_SCIM_PROVISIONING');

Copy

Important

Les instructions SQL de l’exemple utilisent le rôle système ACCOUNTADMIN et le rôle personnalisé GENERIC_SCIM_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 :

Utilisez le rôle ACCOUNTADMIN comme indiqué dans les instructions SQL d’exemple.
Utilisez un rôle avec le privilège global MANAGE GRANTS.
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.

Utilisez le rôle ACCOUNTADMIN.
use role accountadmin;
Copy

Créez le rôle personnalisé GENERIC_SCIM_PROVISIONER. Tous les utilisateurs et rôles dans Snowflake créés par IdP appartiendront au rôle GENERIC_SCIM_PROVISIONER restreint.

create role if not exists generic_scim_provisioner;
grant create user on account to role generic_scim_provisioner;
grant create role on account to role generic_scim_provisioner;

Copy

Laissez le rôle ACCOUNTADMIN créer l’intégration de sécurité à l’aide du rôle GENERIC_SCIM_PROVISIONER personnalisé. Pour plus d’informations, voir CREATE SECURITY INTEGRATION.

grant role generic_scim_provisioner to role accountadmin;
create or replace security integration generic_scim_provisioning
    type = scim
    scim_client = 'generic'
    run_as_role = 'GENERIC_SCIM_PROVISIONER';

Copy

Créez et enregistrez le jeton d’autorisation et stockez-le en toute sécurité 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('GENERIC_SCIM_PROVISIONING');
Copy

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¶

L’application d’une politique réseau à une intégration de sécurité SCIM permet à la politique réseau SCIM d’être distincte des politiques réseau qui s’appliquent à l’ensemble du compte Snowflake. Elle permet au fournisseur SCIM de mettre à disposition des utilisateurs et des groupes sans ajouter d’adresses IP à une politique réseau qui contrôle l’accès des utilisateurs normaux.

Une politique réseau appliquée à une intégration SCIM est prioritaire sur une politique réseau appliquée à l’ensemble du compte Snowflake, mais elle est prioritaire sur une politique réseau attribuée à un utilisateur.

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 generic_scim_provisioning set network_policy = <scim_network_policy>;

Copy

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

alter security integration generic_scim_provisioning unset network_policy;

Copy

Où :

generic_scim_provisioning: Spécifie le nom de l’intégration de sécurité SCIM personnalisée.
scim_network_policy: Spécifie la politique réseau SCIM personnalisée dans Snowflake.

Pour plus d’informations, voir Contrôle du trafic réseau avec des 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_ROLES 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}.

Réplication de l’intégration de sécurité SCIM personnalisée¶

Snowflake prend en charge la réplication et le basculement/la restauration avec l’intégration de sécurité SCIM du compte source au compte cible.

Pour plus de détails, voir Réplication des intégrations de sécurité et des politiques réseau sur plusieurs comptes.

Chapitres suivants :

Réalisation d’une requête API SCIM