Utiliser la fédération Open ID Connect (OIDC) pour activer l'authentification aux partages Delta Sharing (partage ouvert)

Cette page explique comment les fournisseurs de données dans Azure Databricks peuvent fédérer l’authentification auprès d’un fournisseur d’identité pour régir l’accès aux partages delta créés dans Azure Databricks. Ce flux d’authentification utilise la fédération OIDC, autorisant les jetons Web JSON (JWT) émis par le fournisseur d’identité du destinataire en tant que jetons OAuth de courte durée authentifiés par Azure Databricks. Cette méthode d'authentification de partage Databricks-to-open est conçue pour les destinataires qui n'ont pas accès à un espace de travail Databricks compatible avec le catalogue Unity.

Dans la fédération OIDC, l'IdP du destinataire est chargé d'émettre des jetons JWT et d'appliquer les politiques de sécurité, telles que l'authentification multifacteur (MFA). De même, la durée de vie du jeton JWT est régie par l'IdP du destinataire. Databricks ne génère pas ou ne gère pas ces jetons. Il se contente de fédérer l’authentification auprès de l’IdP du destinataire et de valider le JWT conformément à la stratégie de fédération configurée pour le destinataire. Les fournisseurs de données peuvent également choisir de fédérer l’authentification auprès de leur propre fournisseur d’identité lors du partage de données en interne avec d’autres utilisateurs ou services au sein de leur organisation.

La fédération OIDC est une alternative à l’utilisation de jetons porteurs à long terme émis par Azure Databricks pour connecter des utilisateurs qui ne sont pas de Databricks aux fournisseurs. Il permet un contrôle d’accès affiné, prend en charge l’authentification multifacteur et réduit les risques de sécurité en éliminant la nécessité pour les destinataires de gérer et de sécuriser les informations d’identification partagées. Pour plus d’informations sur l’utilisation de jetons porteurs pour gérer l’authentification sur les ressources partagées, consultez Créer un objet destinataire pour les utilisateurs autres que Databricks à l’aide de jetons porteurs (partage ouvert).

Comment fonctionne la fédération OIDC dans Delta Sharing ?

1. Lorsque le fournisseur de données crée le destinataire dans Delta Sharing sur Azure Databricks, il configure une politique de fédération de jetons OIDC qui spécifie l'URL de l'émetteur de l'IdP du destinataire, tel que Microsoft Entra ID ou Okta, et définit l'utilisateur, le groupe, le principal de service ou l'application OAuth du destinataire qui doit avoir accès au partage.

2. Azure Databricks génère une URL du portail web de profil OIDC, basée sur la stratégie et le fournisseur partage cette URL avec le destinataire.

   L’utilisateur final copie l’URL du point de terminaison ou télécharge le fichier de profil, en fonction de sa plateforme préférée, et fournit l’URL ou le fichier de profil à la plateforme sur laquelle il interroge les données partagées. Ce fichier de profil partagé téléchargé à partir du web du portail Databricks OIDC ne contient aucune information sensible.

   • Pour l'authentification utilisateur-machine (U2M), le destinataire saisit le point de terminaison destinataire du portail Web du profil OIDC dans son application U2M.
   • Pour l’authentification machine à machine (M2M), le développeur de l’application destinataire télécharge le fichier de profil et le référence dans l’application cliente destinataire.

3. Lorsque le destinataire tente d'accéder aux données partagées à l'aide de sa plateforme préférée, l'authentification est fédérée vers son IdP.

   Databricks ne génère ni ne gère aucun jeton ou informations d’identification. À la place, l'IdP du destinataire génère un JWT contenant des revendications d'identité. La durée de vie de ce jeton à courte durée de vie est appliquée par l'IdP du destinataire. Le service Delta Sharing valide ensuite le JWT par rapport à la politique du destinataire afin de s'assurer qu'il correspond aux revendications attendues, notamment l'émetteur, l'audience et le sujet. Si la validation réussit, la demande est authentifiée et l’accès est accordé en fonction des autorisations du catalogue Unity.

Avant de commencer

Pour créer un destinataire, vous devez répondre aux exigences suivantes :

• Vous devez être administrateur de metastore ou avoir le CREATE RECIPIENT privilège pour le metastore Unity Catalog où les données que vous souhaitez partager sont inscrites.
• Vous devez créer le destinataire à l’aide d’un espace de travail Azure Databricks dont le metastore Unity Catalog est attaché.
• Si vous utilisez un notebook Databricks pour créer le destinataire, votre calcul doit utiliser Databricks Runtime 11.3 LTS ou version ultérieure, et soit le mode d’accès standard ou dédié (anciennement les modes d’accès partagé et mono-utilisateur).

Quel fournisseur d’identité utiliser ?

Vous pouvez utiliser la fédération OIDC avec un fournisseur d’identité interne ou externe, en fonction de votre scénario de partage :

• Fournisseur d’identité interne (Provider-Managed)

  • Cela est utile pour partager des données au sein de grandes organisations où différents services n’ont pas d’accès direct à Databricks, mais partagent le même fournisseur d’identité.
  • Cette approche permet au fournisseur de gérer l’accès au nom du destinataire.
  • Les politiques de sécurité, telles que l'authentification multifactorielle (MFA) et le contrôle d'accès basé sur les rôles, sont appliquées par l'IdP du fournisseur.

• Fournisseur d’identité externe (Recipient-Managed)

  • Le fournisseur configure la politique de partage afin de faire confiance à l'IdP du destinataire.
  • L’organisation destinataire conserve un contrôle total sur les personnes autorisées à accéder aux données partagées.
  • Les politiques de sécurité, telles que l'authentification multifactorielle (MFA) et le contrôle d'accès basé sur les rôles, sont appliquées par l'IdP du destinataire.

Scénario d’authentification U2M ou M2M

Secure Open Sharing with OIDC Token Federation prend en charge les flux d’authentification Utilisateur à Machine (U2M) et Machine à Machine (M2M), ce qui permet un large éventail de scénarios de partage de données sécurisés.

Authentification utilisateur à machine (U2M)

Un utilisateur de l'organisation destinataire s'authentifie à l'aide de son IdP. Si l’authentification multifacteur est configurée, elle est appliquée lors de la connexion.

Une fois authentifiés, les utilisateurs peuvent accéder aux données partagées à l’aide d’outils tels que Power BI ou Tableau. Le fournisseur de données peut définir des stratégies d’accès qui limitent l’accès aux données à des utilisateurs ou groupes spécifiques au sein de l’organisation destinataire, ce qui garantit un contrôle précis sur qui peut accéder aux ressources partagées. L'application cliente U2M (par exemple, Power BI) utilise le flux d'octroi de code d'autorisation OAuth pour obtenir des jetons d'accès auprès de l'IdP.

Authentification machine à machine (M2M)

M2M est idéal pour les charges de travail automatisées, telles que les travaux nocturnes ou les services en arrière-plan, qui nécessitent un accès sans interaction utilisateur. L'organisation destinataire enregistre un principal de service dans son IdP. Cette identité de service permet aux applications ou aux scripts d’accéder en toute sécurité aux ressources par programmation. Aucun secret ou informations d’identification n’est échangé entre Databricks, le fournisseur ou le destinataire. Toute la gestion des secrets reste interne à chaque organisation. Les clients M2M, tels que Python Delta Sharing Client ou Spark Delta Sharing Client, utilisent le flux d'octroi d'informations d'identification client OAuth pour récupérer les jetons d'accès auprès de l'IdP.

Créer un destinataire qui utilise une stratégie de fédération OIDC

Étape 1. Créer un destinataire de fédération OIDC ouverte

Pour créer un destinataire qui s’authentifie à l’aide d’OIDC :

1. Dans votre espace de travail Azure Databricks, cliquez sur Catalogue.

2. En haut du volet Catalogue, cliquez sur l'icône d'engrenage et sélectionnez Partage Delta.

   Vous pouvez également, dans la page Accès rapide, cliquer sur le bouton Delta Sharing >.

3. Sous l’onglet Partagé par moi, cliquez sur Nouveau destinataire.

4. Entrez le nom du destinataire.

5. Pour Type de destinataire, sélectionnez Ouvert.

6. Choisissez la fédération OIDC comme méthode d'authentification ouverte.

7. Cliquez sur Créer.

8. (Facultatif) Créez des propriétés de destinataire personnalisées. Sous l'onglet Détails du destinataire, cliquez sur Modifier les propriétés > +Ajouter une propriété. Ajoutez ensuite un nom de propriété (Clé) et une Valeur. Pour plus d’informations, consultez Gérer les propriétés du destinataire.

Étape 2. Créer une stratégie de fédération OIDC

Avant de créer la stratégie, recueillez les informations nécessaires auprès du destinataire concernant son IdP, notamment les utilisateurs, les groupes, les principaux de service ou les applications OAuth qui doivent avoir accès au partage. Si vous utilisez votre propre IdP (interne) pour le partage interne, récupérez ces informations à partir de votre propre système d'identité.

Vous devez d'abord demander au destinataire des informations sur son IdP et les utilisateurs, groupes, principaux de service ou applications OAuth qui doivent avoir accès au partage. Vous fournissez ensuite ces informations dans Azure Databricks lorsque vous créez le destinataire.

Sur la page de modification du destinataire, sous Stratégies de fédération OIDC, cliquez sur Ajouter une stratégie.

Entrez les informations suivantes :

• Nom de la politique: nom lisible par l’homme pour la politique.

• URL de l'émetteur : URL HTTPS de l'IdP émettant le jeton JWT.

• Objet de la demande : réclamation dans le JWT qui identifie le type d'identité d'authentification. Dans Microsoft Entra ID, vous pouvez configurer les valeurs suivantes :

  • oid (ID d’objet) : sélectionnez si un utilisateur est destiné à accéder aux données via une application U2M, telle que PowerBI.
  • groups: sélectionnez si un groupe d’utilisateurs est destiné à accéder aux données via une application U2M, telle que PowerBI.
  • azp: sélectionnez si une application OAuth est destinée à accéder aux données via une application M2M, telle que le client de partage Delta Python ou le client de partage Delta Spark.

  Dans certains autres IdP, des réclamations telles que « sub » ou autres peuvent être utilisées. Reportez-vous à la documentation idP pour déterminer la revendication appropriée pour votre cas d’usage.

• Objet : Utilisateur, groupe ou application spécifique autorisé à accéder au partage.

• Audiences : le JWT doit correspondre à un ou plusieurs identificateurs de ressource. Un jeton est considéré comme valide si sa réclamation « aud » correspond à l'un des publics répertoriés.

Si vous ne savez pas quelles sont les valeurs à utiliser (émetteur, revendication d’objet, sujet, audience), reportez-vous à l’exemple suivant. Vous devez déterminer les détails de la stratégie de fédération OIDC avant de la créer.

Si vous utilisez un IdP géré par un destinataire externe, demandez les informations suivantes au destinataire partagé via un canal sécurisé. Si vous utilisez votre propre IdP géré en interne, ces informations proviennent de votre propre IdP en fonction des identités que vous partagez.

Exemple pour U2M quand idP est Entra ID :

Voici un exemple de configuration pour le partage avec un utilisateur spécifique dont l'ID d'objet est 11111111-2222-3333-4444-555555555555 dans le locataire Entra ID aaaaaaaa-bbbb-4ccc-dddd-eeeeeeeeeeee

• Émetteur : https://login.microsoftonline.com/aaaaaaaa-bbbb-4ccc-dddd-eeeeeeeeeeee/v2.0
• revendication d’objet : oid (ID d’objet)
• Objet : 11111111-2222-3333-4444-555555555555
• Audiences : 64978f70-f6a6-4204-a29e-87d74bfea138 (il s’agit de l’ID client de l’application multilocataire inscrite par Databricks dans Entra ID)

Voici un exemple de configuration pour le partage avec un groupe spécifique dont l'ID d'objet est 66666666-2222-3333-4444-555555555555 dans le locataire Entra ID aaaaaaaa-bbbb-4ccc-dddd-eeeeeeeeeeee

• Émetteur : https://login.microsoftonline.com/aaaaaaaa-bbbb-4ccc-dddd-eeeeeeeeeeee/v2.0
• revendication du sujet : groups
• Objet : 66666666-2222-3333-4444-555555555555
• Audiences : 64978f70-f6a6-4204-a29e-87d74bfea138 (il s’agit de l’ID client de l’application multilocataire inscrite par Databricks dans Entra ID)

Pour plus d’informations sur les applications U2M et leurs stratégies de fédération OIDC, consultez Recevoir des partages Delta Sharing à l’aide de la fédération OpenID Connect (OIDC) dans un processus de partage ouvert entre l'utilisateur et la machine.

Exemple pour M2M quand idP est Entra ID :

Pour une application M2M OAuth avec un ID d'application (client) 11111111-2222-3333-4444-555555555555 dans le locataire Entra ID aaaaaaaa-bbbb-4ccc-dddd-eeeeeeeeeeee :

• Émetteur : https://login.microsoftonline.com/aaaaaaaa-bbbb-4ccc-dddd-eeeeeeeeeeee/v2.0
• Objet de la demande : azp
• Objet : 11111111-2222-3333-4444-555555555555 (Il s’agit de l’ID d’application (client), qui est l’ID client de l’application OAuth inscrite et qui se trouve dans le portail Entra ID du destinataire.
• Audiences : 66666666-2222-3333-4444-555555555555 (il peut s’agir de n’importe quel identificateur d’audience valide défini par le destinataire, tel que l’ID client de l’application OAuth inscrite.) Pour plus d’informations sur les applications M2M et leurs stratégies de fédération OIDC, consultez Recevoir des partages de partage delta à l’aide d’un client Python et d’une fédération Open ID Connect (OIDC) dans un flux de machine à machine (partage ouvert).

Étape 3. Accorder au destinataire l’accès à un partage

Une fois que vous avez créé le destinataire et créé des partages, vous pouvez accorder au destinataire l’accès à ces partages.

Pour accorder aux destinataires l’accès au partage, vous pouvez utiliser Catalog Explorer, l’interface CLI Databricks Unity Catalog ou la commande SQL GRANT ON SHARE dans un notebook Azure Databricks ou l’éditeur de requête Databricks SQL.

Autorisations requises : l’une des suivantes :

• Administrateur de metastore.
• Les permissions déléguées ou la propriété sur le partage et les objets du destinataire ((USE SHARE + SET SHARE PERMISSION) ou propriétaire du partage) ET (USE RECIPIENT ou propriétaire du destinataire).

Pour obtenir des instructions, consultez Gérer l’accès aux partages de données Delta Sharing (pour les fournisseurs).

Flux de travail du destinataire

Pour en savoir plus sur la façon dont les destinataires authentifient et accèdent aux partages à l’aide de la fédération de jeton OIDC, consultez :

• Recevoir des partages Delta Sharing à l'aide de la fédération Open ID Connect (OIDC) dans un flux utilisateur-machine (partage ouvert)
• Recevoir des partages Delta Sharing à l'aide d'un client Python et d'une fédération Open ID Connect (OIDC) dans un flux machine-machine (partage ouvert)