Gestion des utilisateurs et des groupes avec SCIM¶
Ce sujet décrit :
Intégrations SCIM avec Snowflake.
Cas d’utilisation SCIM avec Snowflake.
Utilisation des APIs SCIM de Snowflake pour adresser des requêtes à un fournisseur d’identité.
Vue d’ensemble SCIM¶
SCIM est une spécification ouverte destinée à faciliter la gestion automatisée des identités d’utilisateurs et des groupes (c.-à-d. des rôles) dans des applications Cloud utilisant des APIs RESTful.
Ces APIs utilisent des méthodes communes (par exemple GET, POST) avec des attributs de paire clé-valeur au format JSON. L’ensemble d’attributs utilisateur est unique pour l’utilisateur. De même, les attributs du groupe sont uniques au groupe.
Actuellement, Snowflake prend en charge SCIM 2.0 pour intégrer Snowflake à Okta et Microsoft Azure AD, qui fonctionnent tous deux en tant que fournisseurs d’identité. Snowflake prend également en charge des fournisseurs d’identité différents d’Okta et de Microsoft Azure (c.-à-d. personnalisés). Les utilisateurs et les groupes du fournisseur d’identité peuvent être provisionnés dans Snowflake, qui fonctionne en tant que fournisseur de services.
Important
Le rôle SCIM spécifique dans Snowflake doit posséder les utilisateurs et les rôles importés à partir du fournisseur d’identité. Si le rôle SCIM Snowflake ne possède pas les utilisateurs ou les rôles importés, les mises à jour du fournisseur d’identité ne seront pas synchronisées avec Snowflake. Le rôle SCIM Snowflake est spécifique au fournisseur d’identité (IdP) et se présente comme suit :
Rôle SCIM Okta :
okta_provisionerRôle SCIM Azure AD :
aad_provisionerRôle SCIM personnalisé :
generic_scim_provisioner
Pour plus d’informations sur l’utilisation du rôle SCIM Snowflake, voir les sections de configuration SCIM pour l’intégration SCIM Okta, Azure AD et personnalisée.
Le fournisseur d’identité utilise un client SCIM pour envoyer la requête API RESTful au serveur SCIM Snowflake. Lors de la validation de la requête API, Snowflake exécute des actions sur l’utilisateur ou le groupe.
Le processus d’authentification utilise un jeton du porteur OAuth. Ce jeton est valide pour six mois. Les clients doivent garder un suivi de leur jeton d’authentification et peuvent générer un nouveau jeton à la demande. Lors de chaque requête API, le jeton est transmis à l’en-tête en tant que paramètre du porteur d’autorisation.
Après la configuration SCIM initiale de Snowflake, vous pouvez utiliser l’API SCIM de Snowflake pour résoudre les cas d’utilisation suivants :
Gestion du cycle de vie de l’utilisateur
Mappage de groupes Active Directory sur des rôles Snowflake
Prudence
Actuellement, l’API SCIM de Snowflake permet aux administrateurs de gérer des utilisateurs et des groupes du fournisseur d’identité du client à Snowflake.
Par conséquent, si vous utilisez l’API SCIM de Snowflake pour l’administration de la gestion des identités et des accès des utilisateurs et des groupes, ne modifiez pas les utilisateurs et les groupes dans Snowflake (car ces modifications ne seront pas synchronisées avec le fournisseur d’identité du client).
Cas d’utilisation SCIM¶
L’API SCIM de Snowflake peut traiter les cas d’utilisation suivants.
- Gestion de utilisateurs
Les administrateurs peuvent provisionner et gérer leurs utilisateurs depuis le fournisseur d’identité de leur entreprise vers Snowflake. La gestion des utilisateurs est un mappage individuel entre le fournisseur d’identité et Snowflake.
- Gestion des rôles
Les administrateurs peuvent provisionner et gérer leurs groupes (c.-à-d. les rôles) entre le fournisseur d’identité de leur entreprise et Snowflake. La gestion des rôles est un mappage individuel entre le fournisseur d’identité et Snowflake.
- Audit
Les administrateurs peuvent interroger la table
rest_event_historypour déterminer si le fournisseur d’identité envoie des mises à jour (c.-à-d. des requêtes API SCIM) à Snowflake.
Gestion des utilisateurs avec SCIM¶
Snowflake prend en charge la gestion du cycle de vie des utilisateurs avec les APIs SCIM. La gestion du cycle de vie des utilisateurs est une activité administrative qui coïncide avec le chemin emprunté par l’utilisateur au sein de l’entreprise. Les événements courants du cycle de vie de l’utilisateur incluent ces activités.
Création et activation d’un utilisateur.
Mise à jour des attributs utilisateur, tels que
emailoupassword.Désactivation d’un utilisateur après le départ.
Dans Snowflake, l’automatisation du cycle de vie des utilisateurs utilisant SCIM nécessite de transmettre des attributs utilisateur dans le corps de la requête API. Une requête réussie API du fournisseur d’identité affecte l’utilisateur dans Snowflake presque immédiatement.
Attributs utilisateur¶
Les attributs utilisateur sont les paires clé-valeur associées à l’utilisateur. Ces paires sont les informations sur l’utilisateur, telles que son nom d’affichage et son adresse e-mail. Les fournisseurs d’identité définissent parfois différemment les clés d’attribut, telles que surname, familyName ou lastName, qui indiquent tous le nom de famille de l’utilisateur. Snowflake ne prend pas en charge les attributs utilisateur à valeurs multiples.
L’API SCIM Snowflake transmet les attributs utilisateur au format JSON, comme indiqué dans les exemples API utilisateur correspondants.
Snowflake prend en charge les attributs SCIM suivants pour la gestion du cycle de vie des utilisateurs. Les attributs sont accessibles en écriture, sauf indication contraire.
Important
Dans la table, les attributs Snowflake userName et loginName sont tous deux mappés sur l’attribut SCIM userName. Snowflake prend en charge différentes valeurs pour l’attribut Snowflake de userName et loginName. Cette séparation des valeurs d’attribut permet aux clients d’avoir un contrôle plus granulaire sur la valeur d’attribut pouvant être utilisée pour accéder à Snowflake.
Pour plus d’informations, voir les exemples API utilisateur pour POST et PATCH.
Attribut utilisateur SCIM |
Attribut utilisateur Snowflake |
Type |
Description |
|---|---|---|---|
|
|
chaîne |
Identificateur unique et immuable (c.-à-d. GUID) de l’utilisateur dans Snowflake. Snowflake n’expose pas cette valeur dans la sortie DESCRIBE USER ou SHOW USERS. Pour certains chemins de requête qui contiennent cet attribut (par exemple, PATCH), le Vérifiez les journaux IdP pour vous assurer que les valeurs correspondent. |
|
|
chaîne |
Identificateur pour se connecter à Snowflake. Pour plus de détails sur ces attributs Snowflake, voir CREATE USER. |
|
|
chaîne |
Prénom de l’utilisateur. |
|
|
chaîne |
Nom de famille de l’utilisateur. |
|
|
chaîne |
Adresse e-mail de l’utilisateur. La valeur prend en charge une seule adresse e-mail. |
|
|
chaîne |
Nom que l’interface utilisateur affiche pour l’utilisateur. |
|
N/A |
chaîne |
Identificateur unique défini par le client de provisionnement (par exemple, Azure, Okta). |
|
|
chaîne |
Mot de passe de l’utilisateur. Cette valeur n’est pas renvoyée dans la réponse JSON. Remarque : si la propriété |
|
|
booléen |
Désactive l’utilisateur lorsqu’il est défini sur |
|
N/A |
chaîne |
Liste des groupes auxquels l’utilisateur appartient. Le displayName (nom que l’interface utilisateur affiche pour l’utilisateur) du groupe est requis. Les groupes d’utilisateurs sont en lecture seule et leur appartenance doit être mise à jour avec les API des groupes SCIM. |
|
|
chaîne |
Heure d’ajout de l’utilisateur à Snowflake. |
|
|
chaîne |
Heure de la dernière modification de l’utilisateur dans Snowflake. |
|
N/A |
chaîne |
Les utilisateurs doivent avoir une valeur d’utilisateur. |
|
N/A |
chaîne |
Un tableau de chaînes, séparées par des virgules, indiquant les URIs d’espaces de noms. Les valeurs prises en charge incluent :
|
Attributs personnalisés¶
Snowflake prend en charge la définition d’attributs personnalisés qui ne sont pas définis par RFC 7643, tels que defaultRole, defaultWarehouse, et defaultSecondaryRoles.
Actuellement, Snowflake prend en charge l’utilisation de deux espaces de noms pour définir des attributs personnalisés pour les requêtes POST, PUT et PATCH API suivantes :
urn:ietf:params:scim:schemas:extension:enterprise:2.0:UserCet espace de noms faisait partie de la mise en œuvre originale SCIM dans Snowflake et peut être utilisé pour définir des attributs personnalisés pour les intégrations Okta SCIM uniquement.
Cet espace de noms n’est pas pris en charge pour définir des attributs personnalisés pour les intégrations Microsoft Azure SCIM ou les intégrations SCIM personnalisées.
urn:ietf:params:scim:schemas:extension:2.0:UserCe nouvel espace de noms peut être utilisé pour définir des attributs personnalisés pour toutes les intégrations SCIM et doit être utilisé pour les attributs personnalisés avec soit une intégration SCIM personnalisée soit une intégration SCIM Microsoft Azure.
APIs utilisateur¶
Snowflake prend en charge les APIs suivantes pour faciliter la gestion du cycle de vie des utilisateurs. Vous pouvez obtenir des informations sur les utilisateurs grâce à des filtres et également créer, mettre à jour, désactiver et supprimer des utilisateurs.
But |
Méthode et API |
Remarques |
|---|---|---|
Vérifier si un utilisateur existe. |
|
Renvoie les détails d’un compte utilisateur avec le |
Obtenir des détails pour un utilisateur spécifique. |
|
Renvoie les détails d’un compte utilisateur avec le |
Obtenir des détails pour un utilisateur spécifique. |
|
Renvoie un exemple d’utilisateur pour autoriser le client SCIM à lire le schéma, avec un code de statut HTTP |
Créer un utilisateur. |
|
Crée un utilisateur dans Snowflake et renvoie un code de statut HTTP Si l’utilisateur existe déjà ou si un autre conflit survient, Snowflake renvoie un code de statut HTTP |
Mettre à jour l’utilisateur avec des attributs partiels. |
|
Désactive l’utilisateur correspondant si la clé Pour activer un utilisateur actuellement désactivé, définissez PATCH requiert une clé d’opérations (c’est-à-dire Renvoie un code de statut HTTP |
Mettre à jour un utilisateur. |
|
Vérifie si un utilisateur avec l” Sinon, les attributs en lecture-écriture ou en écriture seule seront remplacés en fonction de la requête. Renvoie un code de statut HTTP |
Supprimer un utilisateur. |
|
Pour plus d’informations sur les requêtes API SCIM, voir Réalisation d’une demande API SCIM.
POST scim/v2/Users¶
Créer un utilisateur avec
userNameetloginNamemappés à la même valeur.{ "schemas": [ "urn:ietf:params:scim:schemas:core:2.0:User", "urn:ietf:params:scim:schemas:extension:2.0:User" ], "userName": "test_user_1", "password": "test", "name": { "givenName": "test", "familyName": "user" }, "emails": [{ "value": "test.user@snowflake.com" } ], "displayName": "test user", "active": true }Créer un utilisateur avec
userNameetloginNamemappés à des valeurs différentes.Si Okta est votre fournisseur d’identité, suivez cette procédure.
{ "active": true, "displayName": "test user", "emails": [ { "value": "test.user@snowflake.com" } ], "name": { "familyName": "test_last_name", "givenName": "test_first_name" }, "password": "test_password", "schemas": [ "urn:ietf:params:scim:schemas:core:2.0:User", "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User" ], "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User": { "snowflakeUserName": "USER5" }, "userName": "USER5" }
PATCH scim/v2/Users/{id}¶
Mettre à jour un utilisateur avec
userNameetloginNamemappés à la même valeur.{ "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"], "Operations": [{ "op": "replace", "value": { "active": false } }] }Mettre à jour un utilisateur avec
userNameetloginNamemappés à des valeurs différentes.Si Okta est votre fournisseur d’identité, suivez cette procédure.
{ "Operations": [ { "op": "Replace", "path": "userName", "value": "test_updated_name" }, { "op": "Replace", "path": "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User.snowflakeUserName", "value": "USER5" } ], "schemas": [ "urn:ietf:params:scim:api:messages:2.0:PatchOp" ] }
PUT scim/v2/Users/{id}¶
Mettre à jour un utilisateur, notamment en définissant les champs "defaultRole", "defaultSecondaryRoles", et "defaultWarehouse"
Pour spécifier les propriétés "defaultRole", "defaultSecondaryRoles", et "defaultWarehouse", Snowflake exige l’utilisation de l’un des extension schémas. Notez que la seule valeur possible pour defaultSecondaryRoles est "ALL".
Note
Bien que Snowflake la prenne en charge, les clients doivent faire preuve de prudence lors de l’utilisation de l’opération PUT , car cette opération coûte plus cher qu’une opération PATCH. Utilisez plutôt l’opération PATCH.
{ "schemas": [ "urn:ietf:params:scim:schemas:core:2.0:User", "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User" ], "userName": "test_user_1", "password": "test", "name": { "givenName": "test", "familyName": "user" }, "emails": [{ "primary": true, "value": "test.user@snowflake.com", "type": "work" } ], "displayName": "test user", "active": true, "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User": { "defaultRole" : "test_role", "defaultSecondaryRoles" : "ALL", "defaultWarehouse" : "test_warehouse" } }
Gestion des rôles avec SCIM¶
Snowflake prend en charge l’utilisation de SCIM pour importer des rôles d’Okta, Azure AD et d’applications personnalisées. Il existe un mappage direct entre ces rôles et les rôles de Snowflake.
Les rôles, qui sont généralement synonymes de groupes, constituent un ensemble logique de privilèges d’accès. Dans le modèle Snowflake, l’accès aux objets sécurisables est permis via des privilèges affectés à des rôles, qui sont à leur tour affectés à d’autres rôles ou utilisateurs.
Les autorisations d’accès et les droits accordés au rôle sont automatiquement hérités par chaque membre (par exemple, un utilisateur) du rôle. Pour plus d’informations, voir Aperçu du contrôle d’accès.
Au fur et à mesure que les utilisateurs suivent leur cheminement de carrière au sein de leur entreprise, leurs exigences d’accès à Snowflake pourraient changer. Par exemple, un utilisateur pourrait passer d’un contributeur individuel à un responsable avec des rapports directs. Lors de la modification de leur rôle, leur accès à Snowflake pourrait également nécessiter d’autoriser des ensembles de données uniquement disponibles pour les gestionnaires.
Au fur et à mesure que l’appartenance à un rôle de l’utilisateur change dans son entreprise, l’accès à Snowflake peut changer automatiquement une fois que ses rôles dans l’entreprise sont mappés au rôle Snowflake correspondant.
Attributs de rôle¶
L’API SCIM de Snowflake transmet les attributs de rôle au format JSON, comme indiqué dans les exemples API correspondants.
Snowflake prend en charge les attributs SCIM suivants pour la gestion du cycle de vie des rôles. Les attributs sont accessibles en écriture, sauf indication contraire.
Attribut de groupe SCIM |
Attribut de groupe Snowflake |
Type |
Description |
|---|---|---|---|
|
|
Chaîne |
Identificateur unique et immuable (c.-à-d. GUID) du rôle dans Snowflake. Snowflake n’expose pas cette valeur. Elle peut être trouvée en appelant la fonction de table Information Schema REST_EVENT_HISTORY. Vérifiez les journaux IdP pour vous assurer que les valeurs correspondent. |
|
|
Chaîne |
Nom que l’interface utilisateur affiche pour le rôle. |
|
N/A |
Chaîne |
Valeur userID de l’utilisateur qui est membre du rôle. |
|
N/A |
Chaîne |
Tableau de chaînes pour indiquer les URIs d’espaces de noms. Par exemple, |
APIs de rôle¶
Vous pouvez obtenir des informations sur les rôles grâce à des filtres et également créer un rôle, mettre à jour l’appartenance au rôle et supprimer un rôle. Snowflake prend en charge les APIs suivantes pour faciliter la gestion des rôles.
But |
Méthode et API |
Remarques |
|---|---|---|
Obtenir un groupe par nom d’affichage. |
|
Renvoie les détails du groupe avec le |
Obtenir un groupe par son |
|
Renvoie les détails du groupe avec le |
Obtenir un exemple de groupe. |
|
Renvoie un exemple de groupe pour autoriser le client SCIM à lire le schéma, avec un code de statut HTTP |
Créer un nouveau groupe. |
|
Crée un nouveau groupe avec un code de statut HTTP |
Mettre à jour un groupe. |
|
Met à jour l’attribut du nom d’affichage du groupe ou l’appartenance au groupe. PATCH requiert une clé d’opérations (c’est-à-dire Renvoie un code de statut HTTP |
Supprimer un groupe. |
|
Pour plus d’informations sur les requêtes API SCIM, voir Réalisation d’une demande API SCIM.
POST scim/v2/Groups¶
{ "schemas": ["urn:ietf:params:scim:schemas:core:2.0:Group"], "displayName":"scim_test_group2" }
PATCH scim/v2/Groups/{id}¶
{ "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"], "Operations": [{ "op": "replace", "value": { "displayName": "updated_name" } }, { "op" : "remove", "path": "members[value eq \"user_id_1\"]" }, { "op": "add", "value": [{ "value": "user_id_2" }] } ] }
Audit avec SCIM¶
Il est possible d’interroger Snowflake pour déterminer quelles requêtes API SCIM ont été effectuées sur un intervalle de temps donné.
Par exemple, ces informations peuvent aider à déterminer si la population d’utilisateurs actifs de l’entreprise à provisionner dans Snowflake correspond aux utilisateurs provisionnés dans Snowflake.
Le code SQL ci-dessous est un exemple représentatif qui appelle la fonction de table d’Information Schema REST_EVENT_HISTORY pour déterminer quelles requêtes API REST SCIM ont été effectuées au cours des cinq dernières minutes, jusqu’à 200 requêtes.
use role accountadmin;
use database demo_db;
use schema information_schema;
select *
from table(rest_event_history(
'scim',
dateadd('minutes',-5,current_timestamp()),
current_timestamp(),
200))
order by event_timestamp;
Pour plus d’informations sur la façon de modifier cette requête, voir les fonctions DATEADD et CURRENT_TIMESTAMP.
Intégrations SCIM prises en charge¶
Snowflake peut s’intégrer aux fournisseurs d’identité suivants pour provisionner, gérer et synchroniser des utilisateurs et des groupes dans Snowflake.
Okta
Microsoft Azure Active Directory
Personnalisés
Note
Les intégrations SCIM personnalisées permettent aux fournisseurs d’identité n’ayant pas d’intégration dédiée de provisionner, gérer et synchroniser des utilisateurs et des groupes dans Snowflake.
Actuellement, l’intégration SCIM personnalisée doit être utilisée pour les fournisseurs d’identité qui ne sont ni Okta ni Microsoft Azure AD.
Les clients utilisant Okta en tant que fournisseur d’identité doivent suivre les instructions indiquées dans Intégration SCIM Okta avec Snowflake.
Les clients utilisant Microsoft Azure Active Directory en tant que fournisseur d’identité doivent suivre les instructions fournies dans Intégration Azure SCIM avec Snowflake.
Les clients qui n’utilisent pas Okta ou Microsoft Azure Active Directory en tant que fournisseur d’identité doivent créer leur propre client SCIM, puis suivre les instructions fournies dans Intégration SCIM personnalisée avec Snowflake.
Chapitres suivants :