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
Cas d’utilisation SCIM
Intégrations SCIM prises en charge
Utilisation de la réplication avec SCIM

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_provisioner
Rôle SCIM Azure AD : aad_provisioner
Rô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_history pour 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 email ou password.
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
`id`	`id`	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 `id` peut être trouvé en appelant la fonction de table REST_EVENT_HISTORY. Vérifiez les journaux IdP pour vous assurer que les valeurs correspondent.
`userName`	`userName`, `loginName`	chaîne	Identificateur pour se connecter à Snowflake. Pour plus de détails sur ces attributs Snowflake, voir CREATE USER.
`name.givenName`	`firstName`	chaîne	Prénom de l’utilisateur.
`name.familyName`	`familyName`	chaîne	Nom de famille de l’utilisateur.
`emails`	`email`	chaîne	Adresse e-mail de l’utilisateur. La valeur prend en charge une seule adresse e-mail.
`displayName`	`displayName`	chaîne	Nom que l’interface utilisateur affiche pour l’utilisateur.
`externalID`	N/A	chaîne	Identificateur unique défini par le client de provisionnement (par exemple, Azure, Okta).
`password`	`password`	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é `SYNC_PASSWORD` de l’intégration de sécurité SCIM est définie sur `FALSE` et que la requête API SCIM spécifie l’attribut `password` alors Snowflake ignore la valeur de l’attribut `password`. Tous les autres attributs de la requête API sont traités en conséquence.
`active`	`disabled`	booléen	Désactive l’utilisateur lorsqu’il est défini sur `false`.
`groups`	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.
`meta.created`	`createdON`	chaîne	Heure d’ajout de l’utilisateur à Snowflake.
`meta.lastModified`	`lastModified`	chaîne	Heure de la dernière modification de l’utilisateur dans Snowflake.
`meta.resourceType`	N/A	chaîne	Les utilisateurs doivent avoir une valeur d’utilisateur.
`schemas`	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 : `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:2.0:User`

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:User

Cet 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:User

Ce 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.	`GET scim/v2/Users?filter=userName eq "{{user_name}}"`	Renvoie les détails d’un compte utilisateur avec le `userName` donné et un code de statut HTTP `200` en cas de réussite.
Obtenir des détails pour un utilisateur spécifique.	`GET scim/v2/Users/{{user_id}}`	Renvoie les détails d’un compte utilisateur avec le `user_id` donné et un code de statut HTTP `200` en cas de réussite.
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 HTTP `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 HTTP `201` en cas de réussite. Si l’utilisateur existe déjà ou si un autre conflit survient, Snowflake renvoie un code de statut HTTP `409`.
Mettre à jour l’utilisateur avec des attributs partiels.	`PATCH scim/v2/Users/{id}`	Désactive l’utilisateur correspondant si la clé `active` est définie sur « false ». Pour activer un utilisateur actuellement désactivé, définissez `active` sur true. PATCH requiert une clé d’opérations (c’est-à-dire `op`) avec un tableau indiquant de remplacer une valeur d’attribut. Renvoie un code de statut HTTP `200` en cas de réussite ou `204` (c’est-à-dire aucun contenu) en cas d’échec.
Mettre à jour un utilisateur.	`PUT scim/v2/Users/{id}`	Vérifie si un utilisateur avec l” `id` donné existe. Cette opération échoue si des attributs immuables doivent être modifiés. 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 `400` si les valeurs des attributs immuables dans le corps de la requête ne correspondent pas aux valeurs dans Snowflake.
Supprimer un utilisateur.	`DELETE scim/v2/Users/{id}`

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 userName et loginName mappé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 userName et loginName mappé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 userName et loginName mappé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 userName et loginName mappé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
`id`	`id`	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.
`displayName`	`name`	Chaîne	Nom que l’interface utilisateur affiche pour le rôle.
`members.value`	N/A	Chaîne	Valeur userID de l’utilisateur qui est membre du rôle.
`schemas`	N/A	Chaîne	Tableau de chaînes pour indiquer les URIs d’espaces de noms. Par exemple, `urn:ietf:params:scim:schemas:core:2.0:Group`.

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 `displayName` donné et avec un code de statut HTTP `200` en cas de réussite.
Obtenir un groupe par son `groupId`.	`GET scim/v2/Groups/{group_id}`	Renvoie les détails du groupe avec le `groupId` donné et un code de statut HTTP `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 HTTP `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 HTTP `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 requiert une clé d’opérations (c’est-à-dire `op`) avec un tableau indiquant s’il s’agit d’un ajout ou d’un remplacement. Renvoie un code de statut HTTP `200` en cas de réussite ou `204` (c’est-à-dire aucun contenu) en cas d’échec.
Supprimer un groupe.	`DELETE scim/v2/Groups/{id}`

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.

Utilisation de la réplication avec SCIM¶

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 de réseau à travers plusieurs comptes.

Chapitres suivants :