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 (création, mise à jour et suppression) dans Snowflake.

  • Gérer le cycle de vie des rôles (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.

Effectuer une transmission de type push pour les groupes

The Push Groups feature creates roles in Snowflake and facilitates role management. The roles created in Snowflake using Okta Push Groups have the same names in Okta and Snowflake. Always create roles in Okta first and use Push Groups to update Snowflake to ensure Okta and Snowflake can synchronize. Okta and the OKTA_PROVISIONER custom role in Snowflake cannot manage manually created roles in Snowflake. Push Groups do not create users in Snowflake.

Astuce

Okta can create users in Snowflake if the Snowflake application in Okta is assigned to a user in Okta.

For more information, see Assign an application to a user.

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

Non pris en charge

  • Enhanced Group Push et Push Now d’Okta.

    Note

    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.

  • Si vous utilisez AWS PrivateLink pour accéder à Snowflake, assurez-vous de ne pas saisir l’URL PrivateLink 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 indiqué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.

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

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

The Snowflake configuration process creates a SCIM security integration to allow users and roles created in Okta to be owned by the OKTA_PROVISIONER SCIM role in Snowflake and creates an access token to use in SCIM API requests. The access token is valid for six months. Upon expiration, create a new access token manually using SYSTEM$GENERATE_SCIM_ACCESS_TOKEN as shown below.

Exécutez les instructions SQL suivantes dans votre client Snowflake préféré.

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');

Chacune des instructions SQL est expliquée ci-dessous.

  1. Vérifiez 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.

    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 et des rôles Snowflake existants via Okta, procédez comme suit :

    1. Transférez la propriété des utilisateurs et des rôles existants vers le rôle okta_provisioner.

      use role accountadmin;
      grant ownership on user <user_name> to role okta_provisioner;
      grant ownership on role <role_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.