Référence d’API utilisateur SCIM¶

En-têtes HTTP¶

L’API SCIM Snowflake utilise des jetons porteurs pour l’authentification HTTP.

Chaque requête HTTP à l’API SCIM Snowflake autorise les en-têtes HTTP suivants :

Attributs utilisateur¶

Vous pouvez spécifier les attributs de l’utilisateur dans le corps des requêtes d’API sous forme de paires clé-valeur au format JSON. Ces paires contiennent des informations sur l’utilisateur, telles que son nom d’affichage ou son adresse e-mail. Les fournisseurs d’identité peuvent spécifier leurs propres noms de clés pour chaque attribut. Par exemple, les fournisseurs d’identité peuvent utiliser la clé lastName, au lieu de familyName, pour représenter le nom de famille de l’utilisateur. Snowflake ne prend pas en charge les attributs utilisateur à valeurs multiples.

Snowflake prend en charge les attributs suivants pour la gestion du cycle de vie des utilisateurs :

Attributs personnalisés¶

Vous pouvez définir des attributs personnalisés qui ne sont pas définis par RFC 7643, comme defaultRole.

Vous pouvez utiliser les espaces de noms suivants pour définir des attributs personnalisés lors des requêtes POST, PUT et PATCH :

urn:ietf:params:scim:schemas:extension:enterprise:2.0:User

Cet espace de noms faisait partie de l’implémentation d’origine de SCIM dans Snowflake. Vous ne pouvez utiliser cet espace de noms que pour définir des attributs personnalisés dans des intégrations de sécurité SCIM Okta.

Vous ne pouvez pas utiliser cet espace de noms pour définir des attributs personnalisés dans des intégrations de sécurité SCIM Microsoft Azure ou des intégrations SCIM personnalisées.

urn:ietf:params:scim:schemas:extension:2.0:User

Vous pouvez utiliser cet espace de noms pour définir des attributs personnalisés pour toutes les intégrations SCIM. Vous devez utiliser cet espace de noms pour définir des attributs personnalisés dans des intégrations de sécurité SCIM Microsoft Azure ou des intégrations de sécurité SCIM personnalisées.

Snowflake prend en charge les attributs personnalisés suivants :

Vérifier si un utilisateur existe¶

Méthode et point de terminaison:

GET /scim/v2/Users?filter=userName eq "{{user_name}}"

Description:

Renvoie des informations sur un utilisateur associé au paramètre de requête userName.

Renvoie le code de statut de la réponse HTTP 200 si la requête HTTP a abouti.

Obtenir des informations sur un utilisateur¶

Méthode et point de terminaison:

GET /scim/v2/Users/{{user_id}}

Description:

Renvoie des informations sur un utilisateur associé au paramètre de chemin user_id.

Renvoie le code de statut de la réponse HTTP 200 si la requête HTTP a abouti.

Créer un utilisateur¶

Méthode et point de terminaison:

POST /scim/v2/Users

Description:

Crée un utilisateur dans Snowflake.

Renvoie le code de statut de la réponse HTTP 201 si la requête HTTP a abouti.

Si l’utilisateur existe déjà ou si la requête HTTP a échoué pour une autre raison, Snowflake renvoie le code de statut de réponse HTTP 409.

Exemples:

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.

Note

Si vous utilisez Okta comme 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

Remplacer les attributs de l’utilisateur¶

Méthode et point de terminaison:

PATCH /scim/v2/Users/{{id}}

Description:

Remplace les attributs de l’utilisateur associé au paramètre de chemin id.

Vous devez définir op sur replace pour effectuer cette requête HTTP.

active accepte les valeurs suivantes :

• false : désactive l’utilisateur.

• true : active l’utilisateur.

Renvoie le code de statut de la réponse HTTP 200 si la requête HTTP a été exécutée avec succès.

En cas d’échec, renvoie le code de réponse HTTP 204.

Exemples:

Désactivez un utilisateur et mettez à jour son givenName sur deactivated_user :

{
  "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
  "Operations": [
    {"op": "replace", "value": { "active": false }}
    {"op": "replace", "value": { "givenName": "deactivated_user" }}
  ],
}

Copy

Mettez à 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

Mettre à jour un utilisateur.¶

Méthode et point de terminaison:

PUT /scim/v2/Users/{{id}}

Description:

Met à jour les attributs de l’utilisateur associé au paramètre de chemin id.

En cas d’échec, renvoie le code de réponse HTTP 400. La requête HTTP n’aboutit pas si elle tente de modifier des attributs immuables ou si les attributs modifiés n’existent pas dans Snowflake.

Exemples:

Mettez à jour un utilisateur et ses attributs "defaultRole", "defaultSecondaryRoles", et "defaultWarehouse".

Pour spécifier les attributs "defaultRole", "defaultSecondaryRoles", et "defaultWarehouse", vous devez utiliser l’un des schémas extension. L’attribut defaultSecondaryRoles n’accepte que la valeur "ALL".

Note

La méthode PUT est plus coûteuse que la méthode 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

Supprimer un utilisateur¶

Méthode et point de terminaison:

DELETE /scim/v2/Users/{{id}}

Description:

Supprime l’utilisateur associé au paramètre de chemin id.