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êtes qui contiennent cet attribut (ex. PATCH), le |
|
|
chaîne |
Nom d’utilisateur que l’utilisateur utilise pour se connecter. |
|
|
chaîne |
Prénom de l’utilisateur. |
|
|
chaîne |
Nom de famille de l’utilisateur. |
|
|
chaîne |
Ne prend en charge qu’une seule adresse e-mail. |
|
|
chaîne |
Nom que l’interface utilisateur affiche pour l’utilisateur. |
|
N/A |
chaîne |
Identifiant 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. |
|
|
booléen |
Désactive l’utilisateur lorsqu’il est défini sur false. |
|
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. . urn:ietf:params:scim:schemas:core:2.0:User . urn:ietf:params:scim:schemas:extension:enterprise:2.0:User |
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 l’utilisateur existe |
GET scim/v2/Users?filter=userName eq « {{user_name}} » |
Retourne les détails d’un compte utilisateur avec le |
Obtenir des détails pour un utilisateur spécifique |
GET scim/v2/Users/{{id_utilisateur}} |
Retourne les détails d’un compte utilisateur avec le |
Obtenir des détails pour un utilisateur spécifique |
GET scim/v2/Users?startIndex=0&count=1 |
Renvoie un exemple d’utilisateur pour autoriser le client SCIM à lire le schéma, avec un code de statut 200 en cas de réussite. |
Créer un utilisateur |
POST scim/v2/Users |
Crée un utilisateur dans Snowflake et renvoie un code de statut 201 en cas de réussite. . Si l’utilisateur existe déjà ou si un autre conflit se produit, Snowflake renvoie un code de statut 409. |
Mettre à jour l’utilisateur avec des attributs partiels |
PATCH scim/v2/Users/{id} |
Désactive l’utilisateur correspondant si la clé |
Mettre à jour l’utilisateur |
PUT scim/v2/Users/{id} |
Vérifie si un utilisateur avec l” |
Supprimer l’utilisateur |
DELETE scim/v2/Users/{id} |
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.
Actuellement, la définition des champs
"defaultWarehouse"et"defaultRole"n’est possible qu’avec Okta ; Azure AD ne prend pas en charge cette configuration.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": { "defaultWarehouse" : "test_warehouse", "defaultRole" : "test_role" } }
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 peuvent changer. Par exemple, un utilisateur peut passer d’un contributeur individuel à un responsable avec des rapports directs. Lors de la modification de leur rôle, leur accès à Snowflake peut é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. Vous pouvez le trouver dans la table Snowflake |
|
|
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 |
GET scim/v2/Groups?filter=displayName= »scim_test_group » |
Renvoie les détails du groupe avec le |
Obtenir un groupe par son |
GET scim/v2/Groups/{group_id} |
Renvoie les détails du groupe avec l’ID de groupe donné et un code de statut 200 en cas de réussite. |
Obtenir un exemple de groupe |
GET scim/v2/Groups?startIndex=0&count=1 |
Renvoie un exemple de groupe pour autoriser le client SCIM à lire le schéma, avec un code de statut 200 en cas de réussite. |
Créer un nouveau groupe |
POST scim/v2/Groups |
Crée un nouveau groupe avec un code de statut 201 en cas de réussite. |
Mettre à jour un groupe |
PATCH scim/v2/Groups/{id} |
Met à jour l’attribut du nom d’affichage du groupe ou l’appartenance au groupe. . PATCH nécessite une clé d’opérations (c.-à-d. |
Supprimer un groupe |
DELETE scim/v2/Groups/{id}) |
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 permettant d’interroger la table 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'));
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.