Configurer Microsoft Azure AD pour OAuth externe

Ce chapitre décrit comment configurer Snowflake en tant que ressource OAuth et Azure AD en tant que serveur d’autorisation OAuth externe pour permettre un accès automatique sécurisé aux données Snowflake.

Dans ce chapitre :

Procédure de configuration

Les quatre étapes suivantes supposent que votre environnement n’a rien configuré concernant les serveurs d’autorisation Azure AD OAuth, les clients OAuth, les champs d’application et les métadonnées nécessaires.

Les informations des étapes 1-3 seront utilisées pour créer une intégration de sécurité dans Snowflake.

Si vous avez déjà un serveur et un client d’autorisation Azure AD configurés, il n’est pas nécessaire de suivre toutes les étapes ci-dessous. Parcourez plutôt les trois étapes suivantes et vérifiez que vous pouvez obtenir les informations souhaitées, créer des champs d’application, affecter des champs d’application à une ou plusieurs politiques et accéder aux métadonnées.

Si vous n’avez pas un serveur et un client d’autorisation Azure AD OAuth configurés, suivez les quatre étapes ci-dessous.

Important

Ces étapes de ce chapitre sont un exemple représentatif sur la façon de configurer Azure AD pour OAuth externe.

Vous pouvez configurer Azure AD sur n’importe quel état souhaité et utiliser n’importe quel flux OAuth à condition que vous puissiez obtenir les informations nécessaires pour l” intégration de la sécurité (dans ce chapitre).

Notez que les étapes suivantes servent de guide pour obtenir les informations nécessaires à la création de l’intégration de sécurité dans Snowflake.

Les étapes 1-3 sont tirées de la documentation Azure AD sur OAuth 2.0 et l’authentification. Pour plus d’informations sur la façon dont Microsoft définit ses termes, son interface utilisateur et les options relatives à OAuth 2.0 et à l’authentification, consultez les guides Azure AD suivants :

Étape préalable : Déterminer le flux OAuth dans Azure AD

Azure AD prend en charge deux flux OAuth différents dans lesquels un client OAuth peut obtenir un jeton d’accès.

  1. Le serveur d’autorisation peut accorder au client OAuth un jeton d’accès au nom de l’utilisateur.

  2. Le serveur d’autorisation peut accorder au client OAuth un jeton d’accès pour le client OAuth lui-même.

Dans le premier flux, l’identité du jeton d’accès fait référence à l’utilisateur. Dans le deuxième flux, l’identité du jeton d’accès fait référence au client OAuth.

Microsoft Azure AD n’autorise pas le même format de rôle pour chacun de ces deux flux OAuth. Le format de rôle à utiliser dépend du flux OAuth utilisé. Après avoir déterminé le flux OAuth à utiliser :

Étape 1 : Configurer la ressource OAuth dans Azure AD

  1. Accédez au Microsoft Azure Portal et authentifiez-vous.

  2. Accédez à Azure Active Directory.

  3. Cliquez sur App Registrations.

  4. Cliquez sur New Registration.

  5. Entrez Snowflake OAuth Resource, ou une valeur similaire à Name.

  6. Vérifiez que Supported account types est défini sur Single Tenant.

  7. Cliquez sur Register.

  8. Cliquez sur Expose an API.

  9. Cliquez sur le lien Set à côté de Application ID URI pour définir le Application ID URI.

    Important

    Le Application ID URI doit être unique dans le répertoire de votre organisation, tel que https://your.company.com/4d2a8c2b-a5f4-4b86-93ca-294185f45f2e. Cette valeur sera appelée <SNOWFLAKE_APPLICATION_ID_URI> dans les étapes de configuration suivantes.

    L’option par défaut dans Azure pour le Application ID URI commence par api://. Cela doit être modifié pour commencer par https://.

    Pour obtenir de l’aide sur l’obtention de l’URIID de votre application, veuillez contacter votre administrateur interne Microsoft Azure AD.

    Si l’URI ID de l’application n’est pas utilisé, il est nécessaire de créer une intégration de sécurité avec les audiences à l’aide de l’URL du compte Snowflake (c’est-à-dire <compte>.<région>.snowflakecomputing.com). Pour plus d’informations, consultez l’intégration de l’audience à l”étape 4 : Créer un serveur d’autorisation OAuth dans Snowflake.

  10. Pour ajouter un rôle Snowflake en tant que champ d’application OAuth pour les flux OAuth où le client automatique agit au nom d’un utilisateur, cliquez sur Add a scope pour ajouter un champ d’application représentant le rôle Snowflake.

    • Entrez le champ d’application en ayant le nom du rôle Snowflake avec le préfixe session:scope:. Par exemple, pour le rôle Snowflake Analyst, entrez session:scope:analyst.

    • Sélectionnez qui peut consentir.

    • Entrez un display name pour le champ d’application (par exemple : Administrateur du compte).

    • Entrez un description pour le champ d’application (par exemple : peut administrer le compte Snowflake).

    • Cliquez sur Add Scope.

  11. Pour ajouter un rôle Snowflake en tant que rôle pour les flux OAuth où le client automatique demande un jeton d’accès pour lui-même :

    • Cliquez sur Manifest.

    • Recherchez l’élément appRoles .

    • Saisissez un App Role avec les paramètres suivants.

    Réglage

    Description

    allowedMemberTypes

    Application.

    description

    Une description du rôle.

    displayName

    Un nom convivial à afficher pour les utilisateurs.

    id

    Un ID unique. Vous pouvez utiliser la fonction [System.Guid]::NewGuid() à partir de PowerShell pour générer un ID unique si nécessaire.

    isEnabled

    Définissez sur : true.

    lang

    La langue. Définissez sur : null.

    origin

    Définissez sur : Application.

    value

    Définissez le nom du rôle Snowflake avec le préfixe session:role:. . Pour le rôle Analyste, entrez session:role:analyst.

    Le App Role se manifeste comme suit.

    "appRoles":[
        {
            "allowedMemberTypes": [ "Application" ],
            "description": "Account Administrator.",
            "displayName": "Account Admin",
            "id": "3ea51f40-2ad7-4e79-aa18-12c45156dc6a",
            "isEnabled": true,
            "lang": null,
            "origin": "Application",
            "value": "session:role:analyst"
        }
    ]
    
  12. Cliquez sur Save.

Étape 2 : Créer un client OAuth dans Azure AD

  1. Accédez au Microsoft Azure Portal et authentifiez-vous.

  2. Accédez à Azure Active Directory.

  3. Cliquez sur App Registrations.

  4. Cliquez sur New Registration.

  5. Entrez un nom pour le client tel que Snowflake OAuth Client.

  6. Vérifiez que les types de comptes pris en charge sont définis sur Client unique.

  7. Cliquez sur Register.

  8. Dans la section Overview, copiez le ClientID du champ Application (client) ID . Ce sera connu sous le nom de <OAUTH_CLIENT_ID> dans les étapes suivantes.

  9. Cliquez sur Certificates & secrets puis sur New client secret.

  10. Ajoutez une description du secret.

  11. Sélectionnez never expire. À des fins de test, sélectionnez des secrets qui n’expirent jamais.

  12. Cliquez sur Add. Copiez le secret. Ce sera connu sous le nom de <OAUTH_CLIENT_SECRET> dans les étapes suivantes.

  13. Pour les clients automatiques qui demanderont un jeton d’accès au nom d’un utilisateur, configurez les autorisations déléguées pour les applications comme suit.

    • Cliquez sur API Permissions.

    • Cliquez sur Add Permission.

    • Cliquez sur My APIs.

    • Cliquez sur le Snowflake OAuth Resource que vous avez créé à l” étape 1 : Configurer la ressource OAuth dans Azure AD.

    • Cliquez sur la zone Delegated Permissions.

    • Vérifiez les autorisations relatives aux champs d’application définis dans l’application que vous souhaitez accorder à ce client.

    • Cliquez sur Add Permissions.

    • Cliquez sur le bouton Grant Admin Consent pour accorder les autorisations au client. Notez qu’à des fins de test, les autorisations sont configurées de cette façon. Cependant, dans un environnement de production, l’octroi d’autorisations de cette manière n’est pas recommandé.

    • Cliquez sur Yes.

  14. Pour les clients automatiques qui demanderont un jeton d’accès pour eux-mêmes, configurez API permissions for Applications comme suit.

    • Cliquez sur API Permissions.

    • Cliquez sur Add Permission.

    • Cliquez sur My APIs.

    • Cliquez sur le Snowflake OAuth Resource que vous avez créé à l” étape 1 : Configurer la ressource OAuth dans Azure AD.

    • Cliquez sur Application Permissions.

    • Vérifiez les Permission liées aux rôles définis manuellement dans le Manifest de l’application que vous souhaitez accorder à ce client.

    • Cliquez sur Add Permissions.

    • Cliquez sur le bouton Grant Admin Consent pour accorder les autorisations au client. Notez qu’à des fins de test, les autorisations sont configurées de cette façon. Cependant, dans un environnement de production, l’octroi d’autorisations de cette manière n’est pas recommandé.

    • Cliquez sur Yes.

Étape 3 : Recueillir les informations Azure AD pour Snowflake

  1. Accédez au Microsoft Azure Portal et authentifiez-vous.

  2. Accédez à Azure Active Directory.

  3. Cliquez sur App Registrations.

  4. Cliquez sur le Snowflake OAuth Resource que vous avez créé à l” étape 1 : Configurer la ressource OAuth dans Azure AD.

  5. Cliquez sur Endpoints dans l’interface Overview.

  6. Sur le côté droit, copiez le OAuth 2.0 token endpoint (v2) et notez les URLs pour OpenID Connect metadata et Federation Connect metadata.

    • Le OAuth 2.0 token endpoint (v2) sera appelé le <AZURE_AD_OAUTH_TOKEN_ENDPOINT> dans les étapes de configuration suivantes. Le point de terminaison doit être similaire à https://login.microsoftonline.com/90288a9b-97df-4c6d-b025-95713f21cef9/oauth2/v2.0/token.

    • Pour le OpenID Connect metadata, ouvrez-les dans une nouvelle fenêtre de navigateur.

      • Recherchez le paramètre "jwks_uri" et copiez sa valeur.

      • Cette valeur de paramètre sera appelée <AZURE_AD_JWS_KEY_ENDPOINT> dans les étapes de configuration suivantes. Le point de terminaison doit être similaire à https://login.microsoftonline.com/90288a9b-97df-4c6d-b025-95713f21cef9/discovery/v2.0/keys.

    • Pour le Federation metadata document, ouvrez l’URL dans une nouvelle fenêtre de navigateur.

      • Recherchez le paramètre "entityID" dans le XML Root Element et copiez sa valeur.

      • Cette valeur de paramètre sera appelée <AZURE_AD_ISSUER> dans les étapes de configuration suivantes. La valeur entityID doit être similaire à https://sts.windows.net/90288a9b-97df-4c6d-b025-95713f21cef9/).

Étape 4 : Créer un serveur d’autorisation OAuth dans Snowflake

Cette étape implique la création d’une intégration de sécurité dans Snowflake pour garantir que Snowflake peut communiquer avec Microsoft Azure AD en toute sécurité, valider les jetons depuis Azure AD et fournir l’accès aux données Snowflake approprié aux utilisateurs en fonction du rôle d’utilisateur associé au jeton OAuth.

Choisissez l’intégration de sécurité qui répond le mieux à votre cas d’utilisation et à vos besoins de configuration. Si votre intégration est uniquement basée sur la configuration précédente, utilisez la première intégration de sécurité. Pour plus d’informations, voir CREATE SECURITY INTEGRATION.

Important

Si vous essayez de créer une intégration de sécurité pour Microsoft Power BI, suivez les instructions de configuration dans SSO Power BI pour Snowflake.

Seuls les administrateurs de compte (c’est-à-dire les utilisateurs dotés du rôle ACCOUNTADMIN) ou un rôle disposant du privilège global CREATE INTEGRATION peuvent exécuter cette commande SQL.

Les valeurs des paramètres d’intégration de sécurité sont sensibles à la casse et les valeurs que vous insérez dans l’intégration de sécurité doivent correspondre à ces valeurs dans votre environnement. Si la casse ne correspond pas, il est possible que le jeton d’accès ne soit pas validé, ce qui entraînera l’échec d’une tentative d’authentification.

Vérifiez que toutes les valeurs correspondent exactement. Par exemple, si la valeur de l’émetteur ne se termine pas par une barre oblique inverse et que l’intégration de sécurité est créée avec une barre oblique inversée à la fin de l’URL, un message d’erreur se produit. Il serait alors nécessaire de supprimer l’objet d’intégration de sécurité (en utilisant DROP INTEGRATION), puis de recréer l’objet avec la valeur d’émetteur correcte (en utilisant CREATE SECURITY INTEGRATION).

Créer un serveur d’autorisation OAuth

create security integration external_oauth_azure_1
    type = external_oauth
    enabled = true
    external_oauth_type = azure
    external_oauth_issuer = '<AZURE_AD_ISSUER>'
    external_oauth_jws_keys_url = '<AZURE_AD_JWS_KEY_ENDPOINT>'
    external_oauth_token_user_mapping_claim = 'upn'
    external_oauth_snowflake_user_mapping_attribute = 'login_name';

Créer un serveur d’autorisation OAuth avec des audiences

Si le Application ID URI entré lors de la création de l’application de ressources Snowflake OAuth dans Azure AD n’est pas l’URL du compte Snowflake (c’est-à-dire : <compte>.<région>.snowflakecomputing.com), ajoutez le paramètre external_oauth_audience_list à la commande avec la valeur <SNOWFLAKE_APPLICATION_ID_URI>.

create security integration external_oauth_azure_2
    type = external_oauth
    enabled = true
    external_oauth_type = azure
    external_oauth_issuer = '<AZURE_AD_ISSUER>'
    external_oauth_jws_keys_url = '<AZURE_AD_JWS_KEY_ENDPOINT>'
    external_oauth_audience_list = ('<SNOWFLAKE_APPLICATION_ID_URI>')
    external_oauth_token_user_mapping_claim = 'upn'
    external_oauth_snowflake_user_mapping_attribute = 'login_name';

Modification de votre intégration de sécurité externe OAuth

Vous pouvez mettre à jour votre intégration de sécurité externe OAuth en exécutant une instruction ALTER sur l’intégration de sécurité.

Pour plus d’informations, voir ALTER SECURITY INTEGRATION.

Utilisation du rôle ANY avec un serveur externe OAuth

Dans l’étape de configuration visant à créer une intégration de sécurité dans Snowflake, le jeton d’accès OAuth inclut la définition du champ d’application. Par conséquent, au moment de l’exécution, l’utilisation de l’intégration de sécurité externe OAuth ne permet ni au client OAuth ni à l’utilisateur d’utiliser un rôle non défini dans le jeton d’accès OAuth.

Après avoir validé le jeton d’accès et créé une session, le rôle ANY peut permettre au client et à l’utilisateur OAuth de décider de son rôle. Si nécessaire, le client ou l’utilisateur peut basculer vers un rôle différent de celui défini dans le jeton d’accès OAuth.

Pour configurer le rôle ANY, définissez le champ d’application en tant que SESSION:ROLE-ANY et configurez l’intégration de la sécurité avec le paramètre external_oauth_any_role_mode. Ce paramètre peut avoir trois valeurs de chaîne possibles :

  • DISABLE n’autorise pas le client ou l’utilisateur OAuth à changer de rôle (c’est-à-dire use role <rôle>;). Par défaut.

  • ENABLE permet au client ou à l’utilisateur OAuth de changer de rôle.

  • ENABLE_FOR_PRIVILEGE permet au client ou à l’utilisateur OAuth de changer de rôle uniquement pour un client ou un utilisateur avec le privilège USE_ANY_ROLE. Ce privilège peut être accordé et révoqué à un ou plusieurs rôles disponibles pour l’utilisateur. Par exemple :

    grant USE_ANY_ROLE on integration external_oauth_1 to role1;
    
    revoke USE_ANY_ROLE on integration external_oauth_1 from role1;
    

Définissez l’intégration de la sécurité comme suit :

create security integration external_oauth_1
    type = external_oauth
    enabled = true
    external_oauth_any_role_mode = 'ENABLE'
    ...

Utilisation de politiques réseau avec OAuth externe

Actuellement, les politiques réseau ne peuvent pas être ajoutées à votre intégration de sécurité OAuth externe.

Si votre cas d’utilisation nécessite OAuth et une politique réseau Snowflake, utilisez Snowflake OAuth.

Pour plus d’informations, voir OAuth et politiques réseau.

Procédure de test

Dans le cadre du test de OAuth lors de l’utilisation d’Azure AD en tant que serveur d’autorisation, vous devez :

  1. Vérifier que l’utilisateur de test existe dans Azure AD et possède un mot de passe.

  2. Vérifier que l’utilisateur de test existe dans Snowflake avec la valeur d’attribut login_name définie sur <AZURE_AD_USER_USERNAME>

  3. Accorder le rôle SYSADMIN à cet utilisateur.

  4. Enregistrer un client OAuth.

  5. Autoriser le client OAuth à faire une demande POST au point de terminaison du jeton Azure AD comme suit :

    • Type d’autorisation défini sur Propriétaire de la ressource

    • En-tête d’autorisation de base HTTP contenant le clientID et le secret

    • Données FORM contenant le nom d’utilisateur et le mot de passe de l’utilisateur

    • Inclure les champs d’application

Voici un exemple pour obtenir un jeton d’accès en utilisant cURL.

curl -X POST -H "Content-Type: application/x-www-form-urlencoded;charset=UTF-8" \
  --data-urlencode "client_id=<OAUTH_CLIENT_ID>" \
  --data-urlencode "client_secret=<OAUTH_CLIENT_SECRET>" \
  --data-urlencode "username=<AZURE_AD_USER>" \
  --data-urlencode "password=<AZURE_AD_USER_PASSWORD>" \
  --data-urlencode "grant_type=password" \
  --data-urlencode "scope=<SCOPE_AS_IT_APPEARS_IN_AZURE_APP>" \
  '<AZURE_AD_OAUTH_TOKEN_ENDPOINT>'

Connexion à Snowflake via OAuth externe

Après avoir configuré votre intégration de sécurité et obtenu votre jeton d’accès, vous pouvez vous connecter à Snowflake en utilisant l’un des éléments suivants :

Remarques :

  • Il est nécessaire de définir le paramètre authenticator sur oauth et le paramètre token sur external_oauth_access_token.

  • Lors du passage de la valeur token en tant que paramètre de requête URL, il est nécessaire d’encoder en URL la valeur token.

  • Lors du passage de la valeur token à un objet Propriétés (par exemple, pilote JDBC), aucune modification n’est nécessaire.

Par exemple, si vous utilisez le connecteur Python, définissez la chaîne de connexion comme indiqué ci-dessous.

ctx = snowflake.connector.connect(
   user="<username>",
   host="<hostname>",
   account="<account_name>",
   authenticator="oauth",
   token="<external_oauth_access_token>",
   warehouse="test_warehouse",
   database="test_db",
   schema="test_schema"
)

Vous pouvez maintenant utiliser OAuth externe pour vous connecter à Snowflake en toute sécurité.