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 la définition de la propriété DISABLED de l’utilisateur sur TRUE.

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.

Pour désactiver la synchronisation des mots de passe, désactivez cette option dans Okta et mettez à jour l’intégration de sécurité SCIM Okta Snowflake pour définir la propriété SYNC_PASSWORD sur False.

Pousser des groupes:

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

Remarques

Attributs de base

userName

name et login_name

givenName

first_name

familyName

last_name

email

email

Attributs personnalisés

defaultRole

default_role

defaultWarehouse

entrepôt_par_défaut

defaultSecondaryRoles

rôles_secondaires_par_défaut

Vous ne pouvez spécifier que la valeur "ALL".

Problèmes connus

  • Okta ne prend pas en charge les URLs qui contiennent des caractères de soulignement. Si le nom du compte Snowflake contient un trait de soulignement, vous devez utiliser une URL de compte spécial qui remplace le trait de soulignement par un trait d’union. Par exemple, si vous utilisez le format d’URL de nom de compte, l’URL spéciale pourrait être https://myorg-account-name.snowflakecomputing.com.

  • 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 Dépannage (dans cette rubrique).

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, defaultSecondaryRoles, 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 une connectivité privée au service Snowflake pour accéder à Snowflake, assurez-vous de ne pas saisir 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 role if not exists 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');
Copy

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;
    
    Copy
  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 role if not exists okta_provisioner;
    grant create user on account to role okta_provisioner;
    grant create role on account to role okta_provisioner;
    
    Copy
  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';
    
    Copy
  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');
    
    Copy

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

Cette section explique comment créer et configurer une application Snowflake dans Okta.

Note

Lors de la création de l’application Snowflake dans Okta, le champ SubDomain de l’application doit contenir l’identificateur du compte de votre compte Snowflake. Si le nom du compte Snowflake contient un caractère de soulignement et que vous utilisez le format de nom de compte de l’identificateur, vous devez convertir le caractère de soulignement en trait d’union car Okta ne prend pas en charge les caractères de soulignement dans les URLs (par exemple, myorg-account-name).

N’incluez pas de segment privatelink dans le champ SubDomain, car la connectivité privée n’est pas prise en charge et l’introduction de ce segment entraîne l’échec de la connexion SCIM.

Pour configurer l’application Snowflake dans Okta, effectuez les étapes suivantes.

  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, defaultSecondaryRoles, 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

L’application d’une politique réseau à une intégration de sécurité SCIM permet à la politique réseau SCIM d’être distincte des politiques réseau qui s’appliquent à l’ensemble du compte Snowflake. Elle permet au fournisseur SCIM de mettre à disposition des utilisateurs et des groupes sans ajouter d’adresses IP à une politique réseau qui contrôle l’accès des utilisateurs normaux.

Une politique réseau appliquée à une intégration SCIM est prioritaire sur une politique réseau appliquée à l’ensemble du compte Snowflake, mais elle est prioritaire sur une politique réseau attribuée à un utilisateur.

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

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

alter security integration okta_provisioning unset network_policy;
Copy

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 Contrôle du trafic réseau avec des politiques réseau et ALTER SECURITY INTEGRATION.

Utilisation de rôles secondaires avec SCIM

Snowflake prend en charge la configuration de la propriété user DEFAULT_SECONDARY_ROLES sur 'ALL' avec SCIM pour permettre aux utilisateurs d’utiliser des rôles secondaires dans une session Snowflake.

Pour un exemple représentatif, voir PUT scim/v2/Users/{id}.

Réplication de l’intégration de sécurité SCIM Okta

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.

Dépannage

  • Transfert de propriété. Si la mise à jour de l’utilisateur échoue, vérifiez l’appartenance 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 l’appartenance en exécutant l’instruction SQL suivante dans Snowflake, puis réessayez.

    grant ownership on user <username> to role OKTA_PROVISIONER;
    
    Copy
  • 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;
    
    Copy
  • 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]
    
    Copy

    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 :