Gestion des utilisateurs et des groupes avec SCIM

Ce sujet décrit :

  1. Intégrations SCIM avec Snowflake.

  2. Cas d’utilisation SCIM avec Snowflake.

  3. 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_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 :

  1. Gestion du cycle de vie de l’utilisateur

  2. 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.

  1. Création et activation d’un utilisateur.

  2. Mise à jour des attributs utilisateur, tels que email ou password.

  3. 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êtes qui contiennent cet attribut (ex. PATCH), le id peut être trouvé dans la table Snowflake rest_event_history. . Consultez les journaux IdP pour vous assurer que les valeurs correspondent.

userName

userName, loginName

chaîne

Nom d’utilisateur que l’utilisateur utilise pour se connecter.

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

Ne prend en charge qu’une seule adresse e-mail.

displayName

displayName

chaîne

Nom que l’interface utilisateur affiche pour l’utilisateur.

externalID

N/A

chaîne

Identifiant 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.

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. . 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 userName donné et un code de statut 200 en cas de réussite.

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 user_id donné et un code de statut 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 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é active est définie sur « false ». Pour activer un utilisateur actuellement désactivé, définissez active sur « true ». . PATCH nécessite une clé d’opérations (c’est-à-dire op) avec un tableau indiquant de remplacer une valeur d’attribut. . Renvoie un code de statut 200 en cas de réussite ou 204 (c.-à-d. sans contenu) en cas d’échec.

Mettre à jour l’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, elle remplacera les attributs lecture/écriture ou écriture seule en fonction de la requête. . Renvoie un code de statut 400 si les valeurs d’attribut immuable dans le corps de la requête ne correspondent pas à celles de Snowflake.

Supprimer l’utilisateur

DELETE scim/v2/Users/{id}

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.

  • 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

id

id

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 rest_event_history. . Consultez 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 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 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. op) avec un tableau indiquant s’il s’agit d’un ajout ou d’un remplacement. . Renvoie un code de statut 200 en cas de réussite ou 204 (c.-à-d. sans contenu) en cas d’échec.

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.

  1. Okta

  2. Microsoft Azure Active Directory

  3. 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.