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 de 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ê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 requête 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
}
Copy

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"
}
Copy
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
        }
    }]
}
Copy

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"
    ]
}
Copy
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"
    }
}
Copy

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 requête API SCIM.

POST scim/v2/Groups
{
    "schemas": ["urn:ietf:params:scim:schemas:core:2.0:Group"],
    "displayName":"scim_test_group2"
}
Copy
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"
            }]
        }
    ]
}
Copy

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;
Copy

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.

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 réseau sur plusieurs comptes.

Chapitres suivants :