Intégration SCIM Okta avec Snowflake

Ce guide décrit les étapes nécessaires à la configuration du provisionnement dans Okta pour Snowflake et comprend les sections suivantes :

Fonctionnalités

L’administration des utilisateurs et des rôles est prise en charge pour l’application Snowflake.

Cela permet à Okta de :

  • Gérer le cycle de vie des utilisateurs (c’est-à-dire création, mise à jour et suppression) dans Snowflake.

  • Gérer le cycle de vie des rôles (c’est-à-dire création, mise à jour et suppression) dans Snowflake.

  • Gérer les attributions de rôles aux utilisateurs dans Snowflake.

Les fonctionnalités de provisionnement suivantes sont prises en charge :

Effectuer une transmission de type push pour de nouveaux utilisateurs

Les nouveaux utilisateurs créés via OKTA seront également créés dans Snowflake.

Effectuer une transmission de type push pour les mises à jour de profil

Les mises à jour apportées au profil d’un utilisateur via OKTA seront transmises par push à Snowflake.

Effectuer une transmission de type push pour la désactivation d’un utilisateur

La désactivation de l’utilisateur ou la désactivation de son accès à Snowflake via OKTA désactivera l’utilisateur dans Snowflake.

Note

Pour Snowflake, la désactivation d’un utilisateur signifie que l’attribut isActive de l’utilisateur est défini sur « false ».

Réactiver des utilisateurs

Les comptes utilisateur peuvent être réactivés Snowflake.

Synchroniser mot de passe

Le mot de passe de l’utilisateur peut être transmis par push d’Okta dans Snowflake, si nécessaire.

Astuce

La configuration par défaut consiste à créer un mot de passe aléatoire pour les utilisateurs en leur attribuant un paramètre d’attribut has_Password=true. Sans mot de passe, les utilisateurs doivent accéder à Snowflake via Okta SSO. Pour empêcher la génération d’un mot de passe pour les utilisateurs, désactivez ce paramètre avant de provisionner des utilisateurs comme suit :

  1. Cliquez sur Edit.

  2. Sous Sync Password, décochez le paramètre Generate a new random password whenever the user’s Okta password changes.

  3. Enregistrez la modification.

L’activation de ce paramètre dans Okta crée un mot de passe permettant à l’utilisateur d’accéder à Snowflake. Cela pourrait donner aux utilisateurs un chemin pour accéder à Snowflake sans SSO.

Push Groups

La fonction Push Groups crée des rôles dans Snowflake et facilite la gestion des rôles. Les rôles créés dans Snowflake à l’aide d’Okta Push Groups ont les mêmes noms dans Okta et Snowflake. Créez toujours des rôles dans Okta en premier et utilisez Push Groups pour mettre à jour Snowflake afin de vous assurer qu’Okta et Snowflake puissent se synchroniser. Okta et le rôle personnalisé OKTA_PROVISIONER dans Snowflake ne peuvent pas gérer les rôles créés manuellement dans Snowflake. La fonction Push Groups ne crée pas d’utilisateurs dans Snowflake.

Astuce

Okta peut créer des utilisateurs dans Snowflake si l’application Snowflake dans Okta est attribuée à un utilisateur dans Okta.

Pour plus d’informations, consultez Attribuer une application à un utilisateur.

Les attributs utilisateur suivants sont pris en charge :

Type d’attribut

Attribut utilisateur SCIM

Attribut utilisateur Snowflake

Attributs de base

userName

name et login_name

givenName

first_name

familyName

last_name

email

email

Attributs personnalisés

defaultRole

default_role

defaultWarehouse

default_warehouse

Problèmes connus

  • Si votre compte Snowflake a été créé avec des traits de soulignement dans le nom de compte (par exemple my_account), vous pouvez accéder à votre compte Snowflake avec le nom de compte ayant des traits de soulignement ou des tirets (par exemple, my-account). Si vous réutilisez le nom de compte avec trait d’union pour Okta SAML SSO et Okta SCIM, les noms de compte avec des traits de soulignement ne sont pas pris en charge. Par conséquent, utilisez le nom de compte avec un trait d’union pour configurer SCIM.

  • Les rôles existants de Snowflake ne peuvent pas être confiés à la gestion d’Okta par un transfert de propriété. Seuls les nouveaux rôles peuvent être créés via Okta.

  • Les utilisateurs existants de Snowflake peuvent être gérés par Okta grâce à un transfert de propriété. Pour plus d’informations, voir Astuces de dépannage (dans ce chapitre).

Limites

  • Snowflake prend en charge un maximum de 500 demandes simultanées par compte par point de terminaison SCIM (par ex. le point de terminaison /Users, le point de terminaison /Groups). Une fois que votre compte a dépassé ce seuil, Snowflake renvoie un code de statut HTTP 429 (c’est-à-dire trop de demandes). Il convient de noter que cette limite de demandes n’intervient généralement que lors du provisionnement initial lorsqu’un nombre relativement important de demandes (c’est-à-dire plus de 10 000) est adressé en vue de provisionner des utilisateurs ou des groupes.

Non pris en charge

  • Fonctionnalités Enhanced Group Push et Push Now d’Okta.

    Note

    Les attributs defaultRole et defaultWarehouse ne sont pas mappés, car ils sont facultatifs. Pour cartographier ces attributs dans Okta, utilisez des profils, des expressions ou définissez une valeur par défaut pour tous les utilisateurs. Pour plus d’informations, voir Gérer les profils (dans Okta).

  • Si vous utilisez AWS PrivateLink ou Azure Private Link pour accéder à Snowflake, assurez-vous de ne pas saisir l’une de ces URLs dans les paramètres d’intégration. Entrez le point de terminaison public (c’est-à-dire sans .privatelink) et assurez-vous que la politique réseau autorise l’accès à partir de l’adresse IP d’Okta listée ici, sinon vous ne pourrez pas utiliser cette intégration.

  • Okta ne prend actuellement pas en charge l’importation de groupes imbriqués Active Directory. Par conséquent, si votre intégration Okta utilise des groupes imbriqués dans AD, vous ne pouvez pas utiliser l’intégration SCIM Okta Snowflake pour provisionner ou gérer des groupes imbriqués dans Snowflake. Veuillez contacter Okta et Microsoft pour demander la prise en charge des groupes imbriqués.

Conditions préalables

  1. Avant de provisionner des utilisateurs ou des groupes, assurez-vous que la politique réseau dans Snowflake autorise l’accès à partir des adresses IP d’Okta documentées ici. Pour plus d’informations, voir Gestion des politiques réseau SCIM.

  2. Avant de configurer le provisionnement pour Snowflake, assurez-vous que vous avez configuré les General Settings et toutes les Sign-On Options pour l’application Snowflake dans Okta.

Une fois les étapes ci-dessus terminées, cliquez sur Next dans Okta pour revenir à l’onglet Provisioning.

Étapes de configuration

Le processus de configuration nécessite d’effectuer des étapes dans Snowflake et dans Okta.

Configuration de Snowflake

Le processus de configuration de Snowflake crée une intégration de sécurité SCIM pour permettre aux utilisateurs et aux rôles créés dans Okta d’être la propriété du rôle OKTA_PROVISIONER SCIM dans Snowflake et crée un jeton d’accès à utiliser dans les requêtes SCIM API. Le jeton d’accès est valable six mois. À l’expiration, créez un nouveau jeton d’accès manuellement à l’aide de SYSTEM$GENERATE_SCIM_ACCESS_TOKEN comme indiqué ci-dessous.

Note

Pour invalider un jeton d’accès existant pour une intégration SCIM, exécutez une instruction DROP INTEGRATION.

Pour continuer à utiliser SCIM avec Snowflake, recréez l’intégration SCIM avec une instruction CREATE SECURITY INTEGRATION et générez un nouveau jeton d’accès en utilisant SYSTEM$GENERATE_SCIM_ACCESS_TOKEN.

Exécutez les instructions SQL suivantes dans votre client Snowflake préféré. Chacune des instructions SQL est expliquée ci-dessous.

use role accountadmin;
create or replace role okta_provisioner;
grant create user on account to role okta_provisioner;
grant create role on account to role okta_provisioner;
grant role okta_provisioner to role accountadmin;
create or replace security integration okta_provisioning
    type = scim
    scim_client = 'okta'
    run_as_role = 'OKTA_PROVISIONER';
select system$generate_scim_access_token('OKTA_PROVISIONING');

Important

Les instructions SQL de l’exemple utilisent le rôle système ACCOUNTADMIN et le rôle personnalisé OKTA_PROVISIONER est attribué au rôle ACCOUNTADMIN.

Il est possible de ne pas utiliser le rôle ACCOUNTADMIN en faveur d’un rôle moins privilégié. L’utilisation d’un rôle aux privilèges moins élevés peut aider à résoudre les problèmes de conformité liés à un accès moins privilégié, mais elle peut aussi entraîner des erreurs inattendues au cours du processus de configuration et de gestion SCIM.

Ces erreurs pourraient être dues au fait que le rôle moins privilégié ne dispose pas de droits suffisants pour gérer tous les rôles par SCIM en raison de la manière dont les rôles sont créés et de la hiérarchie des rôles qui en résulte. Par conséquent, afin d’éviter les erreurs dans les processus de configuration et de gestion, choisissez l’une des options suivantes :

  1. Utilisez le rôle ACCOUNTADMIN comme indiqué dans les instructions SQL d’exemple.

  2. Utilisez un rôle avec le privilège global MANAGE GRANTS.

  3. Si aucune de ces deux premières options n’est souhaitable, utilisez un rôle personnalisé qui dispose du privilège OWNERSHIP sur tous les rôles qui seront gérés à l’aide de SCIM.

  1. Utilisez le rôle ACCOUNTADMIN.

    use role accountadmin;
    
  2. Créez le rôle personnalisé OKTA_PROVISIONER. Tous les utilisateurs et rôles dans Snowflake créés par Okta appartiendront au rôle OKTA_PROVISIONER restreint.

    create or replace role okta_provisioner;
    grant create user on account to role okta_provisioner;
    grant create role on account to role okta_provisioner;
    
  3. Laissez le rôle ACCOUNTADMIN créer l’intégration de sécurité à l’aide du rôle OKTA_PROVISIONER personnalisé. Pour plus d’informations, voir CREATE SECURITY INTEGRATION.

    grant role okta_provisioner to role accountadmin;
    create or replace security integration okta_provisioning
        type = scim
        scim_client = 'okta'
        run_as_role = 'OKTA_PROVISIONER';
    
  4. Créez et copiez le jeton d’autorisation dans le Presse-papiers et stockez-le de manière sécurisée pour une utilisation ultérieure. Utilisez ce jeton pour chaque requête API REST SCIM et placez-le dans l’en-tête de la requête. Le jeton d’accès expire après six mois et un nouveau jeton d’accès peut être généré avec cette instruction.

    select system$generate_scim_access_token('OKTA_PROVISIONING');
    

    Important

    Tous les utilisateurs et rôles dans Snowflake créés par Okta appartiendront au rôle okta_provisioner restreint.

    Si vous souhaitez gérer des utilisateurs Snowflake existants via Okta, procédez comme suit :

    1. Transférez la propriété des utilisateurs existants au rôle de okta_provisioner.

      use role accountadmin;
      grant ownership on user <user_name> to role okta_provisioner;
      
    2. Assurez-vous que la propriété login_name est définie pour les utilisateurs existants. Cette propriété doit déjà l’être si ces utilisateurs Snowflake existants utilisent le service SSO Okta.

    3. Sachez que le nom des utilisateurs existants placés sous la gestion d’Okta sera mis à jour pour correspondre au nom d’utilisateur d’Okta. Informez vos utilisateurs de cette modification, car ils pourraient utiliser le nom pour se connecter à Snowflake à partir d’une autre intégration (c.-à-d. un Tableau).

Configuration Okta

Dans Okta, accédez à l’application Snowflake et procédez comme suit.

  1. Dans Settings, sélectionnez Integration dans le menu de gauche, puis cochez la case Enable API Integration.

  2. Pour API Token, entrez la valeur générée ci-dessus dans le Presse-papiers. Cliquez sur le bouton Test API Credentials et, en cas de succès, enregistrez la configuration.

  3. Sélectionnez To App dans le menu de gauche.

  4. Sélectionnez les Provisioning Features que vous souhaitez activer.

  5. Vérifiez les mappages d’attributs. Les attributs defaultRole et defaultWarehouse ne sont pas mappés, car ils sont facultatifs. Si nécessaire, vous pouvez les mapper à l’aide d’un profil ou d’une expression Okta ou définir la même valeur pour tous les utilisateurs.

Vous pouvez maintenant affecter des utilisateurs à l’application Snowflake (si nécessaire) et terminer la configuration de l’application.

Note

Okta prend en charge un attribut appelé snowflakeUserName qui correspond au champ name de l’utilisateur Snowflake.

Si vous souhaitez que les champs name et login_name de l’utilisateur Snowflake aient des valeurs différentes, suivez cette procédure.

  1. Contactez le support de Snowflake pour activer le mappage séparé pour votre compte.

  2. Dans Okta, accédez à l’application Snowflake et accédez à Provisioning > Attribute Mappings > Edit Mappings.

  3. Recherchez l’attribut snowflakeUserName.

  4. Si l’attribut n’est pas trouvé, l’application Snowflake a été créée avant que cet attribut ne soit disponible. Recréez l’application Snowflake avec les mappages indiqués ci-dessous ou ajoutez l’attribut manuellement comme suit :

    • Cliquez sur Add Attribute.

    • Définissez les valeurs suivantes pour chacun des champs répertoriés dans la table.

    Champ

    Valeur

    Type de données

    chaîne

    Nom d’affichage

    Nom d’utilisateur Snowflake

    Nom de variable

    snowflakeUserName

    Nom externe

    snowflakeUserName

    Espace de noms externe

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

    Description

    Correspond au champ name de l’utilisateur dans Snowflake.

    Portée

    Utilisateur personnel

  5. Cliquez sur Save.

Activation de la fonction SSO initiée par Snowflake

Le processus de provisionnement SCIM n’active pas automatiquement la connexion unique (SSO).

Pour utiliser SSO une fois le processus de provisionnement SCIM terminé, activez SSO initié par Snowflake.

Gestion des politiques réseau SCIM

La stratégie réseau SCIM a son propre paramètre, de façon à ce que le fournisseur SCIM puisse être spécifiquement autorisé à provisionner des utilisateurs et des groupes sans ajouter ces adresses IP pour un accès utilisateur normal.

La configuration d’une politique réseau spécifique à l’intégration SCIM permet à SCIM d’être distinct des autres politiques réseau qui peuvent s’appliquer au compte Snowflake. La politique réseau SCIM n’affecte pas les autres politiques réseau du compte et les autres politiques réseau du compte n’affectent pas la politique réseau SCIM. Par conséquent, la politique réseau SCIM permet à l’intégration Snowflake SCIM de provisionner des utilisateurs et des groupes comme prévu.

Après avoir créé l’intégration de sécurité SCIM, créez la politique réseau SCIM à l’aide de cette commande :

alter security integration okta_provisioning set network_policy = <politique_réseau_scim>;

Pour annuler la politique réseau SCIM, utilisez cette commande :

alter security integration okta_provisioning unset <politique_réseau_scim>;

Où :

okta_provisioning

Spécifie le nom de l’intégration de sécurité Okta SCIM.

<scim_network_policy>

Spécifie la politique réseau SCIM d’Okta dans Snowflake.

Pour plus d’informations, voir Politiques réseau et ALTER SECURITY INTEGRATION.

Astuces de dépannage

  • Transfert de propriété. Si la mise à jour de l’utilisateur échoue, vérifiez la propriété de l’utilisateur dans Snowflake. S’il n’appartient pas au rôle okta_provisioner (ou au rôle défini dans le paramètre run_as_role lors de la création de l’intégration de sécurité dans Snowflake), la mise à jour échouera. Transférez la propriété en exécutant l’instruction SQL suivante dans Snowflake, puis réessayez.

    grant ownership on user <username> to role OKTA_PROVISIONER;
    
  • Assurez-vous que la propriété login_name est définie pour les utilisateurs existants. Cette propriété doit déjà l’être si ces utilisateurs Snowflake existants utilisent le service SSO Okta.

  • Pour vérifier qu’Okta envoie des mises à jour à Snowflake, vérifiez les événements de journal dans Okta pour l’application Snowflake et les journaux d’audit SCIM dans Snowflake pour vous assurer que Snowflake reçoit les mises à jour d’Okta. Utilisez le code suivant pour interroger les journaux d’audit Snowflake SCIM.

    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;
    
  • Il est possible qu’une erreur d’authentification se produise pendant le processus de provisionnement. Un message d’erreur possible est le suivant :

    Error authenticating: Forbidden. Errors reported by remote server: Invalid JSON: Unexpected character ('<' (code 60)): expected a valid value (number, String, array, object, 'true', 'false' or 'null') at [Source: java.io.StringReader@4c76ba04; line: 1, column: 2]
    

    Si ce message d’erreur ou d’autres messages d’erreur d’authentification se produisent, essayez cette procédure de dépannage :

    1. Dans Okta, supprimez l’application Snowflake actuelle et créez une nouvelle application Snowflake.

    2. Dans Snowflake, créez une nouvelle intégration de sécurité SCIM et générez un nouveau jeton d’accès.

    3. Copiez le nouveau jeton en cliquant sur Copy.

    4. Dans Okta, collez et vérifiez le nouveau jeton d’accès en suivant les instructions de la procédure de configuration d’Okta en tant que fournisseur d’identité SCIM.

    5. Provisionnez des utilisateurs et des rôles d’Okta à Snowflake à l’aide de la nouvelle application Snowflake d’Okta.

Chapitres suivants :