Usar la federación Open ID Connect (OIDC) para habilitar la autenticación en las comparticiones de Delta Sharing (compartición abierta)

En esta página se explica cómo los proveedores de datos de Azure Databricks pueden federar la autenticación a un proveedor de identidades (IdP) para controlar el acceso a los recursos compartidos de Delta Sharing creados en Azure Databricks. Este flujo de autenticación usa la federación de OIDC, lo que permite tokens web JSON (JWT) emitidos por el IdP del destinatario como tokens de OAuth de corta duración autenticados por Azure Databricks. Este método de autenticación de uso compartido abierto de Databricks está diseñado para los destinatarios que no tienen acceso a un área de trabajo de Databricks habilitada para Unity Catalog.

En la federación de OIDC, el IdP del destinatario es responsable de emitir tokens JWT y aplicar directivas de seguridad, como Multi-Factor Authentication (MFA). Del mismo modo, la duración del token JWT se rige por el IdP del destinatario. Databricks no genera ni administra estos tokens. Solo federa la autenticación al IdP del destinatario y valida el JWT respecto a la directiva de federación configurada del destinatario. Los proveedores de datos también pueden optar por federar la autenticación a su propio IdP al compartir datos internamente con otros usuarios o departamentos dentro de su organización.

La federación de OIDC es una alternativa al uso de tokens de portador de larga duración emitidos por Azure Databricks para conectar a los destinatarios que no pertenecen a Databricks con los proveedores. Permite el control de acceso específico, admite MFA y reduce los riesgos de seguridad eliminando la necesidad de que los destinatarios administren y protejan las credenciales compartidas. Para obtener información sobre cómo usar tokens portadores para gestionar la autenticación en recursos compartidos, consulte Crear un objeto destinatario para usuarios que no son de Databricks utilizando tokens portadores (compartición abierta).

¿Cómo funciona la federación de OIDC en Delta Sharing?

1. Cuando el proveedor de datos crea el destinatario en Delta Sharing en Azure Databricks, configuran una directiva de federación de tokens de OIDC que especifica la dirección URL del emisor del IdP del destinatario, como Microsoft Entra ID o Okta, y define el usuario destinatario, grupo, entidad de servicio o aplicación OAuth que debe tener acceso al recurso compartido.

2. Azure Databricks genera una dirección URL del portal web de perfil de OIDC, basada en la directiva y el proveedor comparte esa dirección URL con el destinatario.

   El usuario final copia la dirección URL del punto de conexión o descarga el archivo de perfil, en función de su plataforma preferida, y proporciona la dirección URL o el archivo de perfil a la plataforma en la que consultará los datos compartidos. Este archivo de perfil compartido descargado de la web del portal de OIDC de Databricks no contiene información confidencial.

   • Para la autenticación de usuario a máquina (U2M), el destinatario introduce el punto de conexión del destinatario desde el portal web del perfil de OIDC en su aplicación U2M.
   • Para la autenticación de máquina a máquina (M2M), el desarrollador de aplicaciones destinatarios descarga el archivo de perfil y hace referencia a él en la aplicación cliente del destinatario.

3. Cuando el destinatario intenta acceder a los datos compartidos mediante su plataforma preferida, la autenticación se federa a su IdP.

   Databricks no genera ni administra tokens ni credenciales. En su lugar, el IdP del destinatario genera un JWT que contiene declaraciones de identidad. El IdP del destinatario aplica la vigencia de este token de corta duración. A continuación, el servicio Delta Sharing valida el JWT respecto a la directiva del destinatario para asegurarse de que concuerde con las reclamaciones esperadas, incluidos el emisor, la audiencia y el asunto. Si la validación se realiza correctamente, la solicitud se autentica y se concede acceso en función de los permisos del catálogo de Unity.

Antes de empezar

Para crear un destinatario, debe cumplir los siguientes requisitos:

• Debe ser administrador del metastore o tener el privilegio CREATE RECIPIENT para el metastore de Unity Catalog donde están registrados los datos que quiere compartir.
• Es necesario crear el destinatario mediante un área de trabajo de Azure Databricks que tenga asociado ese metastore de Unity Catalog.
• Si usa un cuaderno de Databricks para crear el destinatario, su computación debe usar Databricks Runtime 11.3 LTS o superior y el modo de acceso estándar o dedicado (anteriormente modos de acceso compartido y de usuario único).

¿Qué proveedor de identidades se va a usar?

Puede usar la federación de OIDC con un proveedor de identidades interno o externo, en función del escenario de uso compartido:

• Proveedor de identidades interno (Provider-Managed)

  • Esto resulta útil para compartir datos dentro de organizaciones de gran tamaño en los que distintos departamentos no tienen acceso directo a Databricks, pero comparten el mismo IdP.
  • Este enfoque permite al proveedor administrar el acceso en nombre del destinatario.
  • Las directivas de seguridad, como MFA y el control de acceso basado en roles, se aplican mediante el IdP del proveedor.

• Proveedor de identidades externo (Recipient-Managed)

  • El proveedor configura la directiva de uso compartido para confiar en el IdP del destinatario.
  • La organización de destinatarios conserva el control total sobre quién puede acceder a los datos compartidos.
  • Las directivas de seguridad, como MFA y el control de acceso basado en rol, se aplican mediante el IdP del destinatario.

Escenario de autenticación U2M o M2M

Secure Open Sharing with OIDC Token Federation admite flujos de autenticación de usuario a máquina (U2M) y de máquina a máquina (M2M), lo que permite una amplia gama de escenarios seguros de uso compartido de datos.

Autenticación de usuario a máquina (U2M)

Un usuario de la organización de destinatarios se autentica mediante su IdP. Si se configura MFA, se aplica durante el inicio de sesión.

Una vez autenticados, los usuarios pueden acceder a datos compartidos mediante herramientas como Power BI o Tableau. El proveedor de datos puede definir directivas de acceso que restrinjan el acceso de datos a usuarios o grupos específicos dentro de la organización del destinatario, lo que garantiza un control preciso sobre quién puede acceder a los recursos compartidos. La aplicación cliente U2M (por ejemplo, Power BI) usa el flujo de concesión de código de autorización de OAuth para obtener tokens de acceso del IdP.

Autenticación de máquina a máquina (M2M)

M2M es ideal para cargas de trabajo automatizadas, como trabajos nocturnos o servicios en segundo plano, que requieren acceso sin interacción del usuario. La organización del destinatario registra un Servicio Principal en su IdP. Esta identidad de servicio permite a las aplicaciones o scripts acceder de forma segura a los recursos mediante programación. No se intercambian secretos ni credenciales entre Databricks, el proveedor o el destinatario. Toda la administración de secretos permanece interna en cada organización. Los clientes M2M, como el cliente de uso compartido delta de Python o el cliente de uso compartido delta de Spark, usan el flujo de concesión de credenciales de cliente de OAuth para recuperar tokens de acceso del IdP.

Creación de un destinatario que use una directiva de federación de OIDC

Paso 1. Creación de un destinatario de federación de OIDC abierto

Para crear un destinatario que se autentique mediante OIDC:

1. En el área de trabajo de Azure Databricks, haga clic en Catálogo.

2. En la parte superior del panel Catálogo, haga clic en el y seleccione Delta Sharing.

   Como alternativa, en la página Acceso rápido, haga clic en el botón Delta Sharing>.

3. En la pestaña Compartido por mí, haga clic en Nuevo destinatario.

4. Escriba el nombre del destinatario.

5. En Tipo de destinatario, seleccione Abrir.

6. Elija Federación de OIDC como método de autenticación abierto.

7. Haga clic en Crear.

8. (Opcional) Cree propiedades de Destinatario personalizadas. En la pestaña Detalles del destinatario, haga clic en Editar propiedades > +Agregar propiedad. A continuación, agregue un nombre de propiedad (Clave) y un Valor. Para obtener más información, consulte Administrar las propiedades del destinatario.

Paso 2. Creación de una directiva de federación de OIDC

Antes de crear la directiva, recopile la información necesaria del destinatario sobre su IdP, incluidos los usuarios, grupos, entidades de servicio o aplicaciones de OAuth que deben tener acceso al recurso compartido. Si utiliza su propio IdP (interno) para el uso compartido interno, recupere esta información de su propio sistema de identidad.

Primero debe solicitar información del destinatario sobre su IdP y los usuarios, grupos, entidades de servicio o aplicaciones de OAuth que deben tener acceso al recurso compartido. A continuación, proporcione esa información en Azure Databricks al crear el destinatario.

En la página de edición del destinatario, en Directivas de federación de OIDC, haga clic en Agregar directiva.

Escribe lo siguiente:

• Nombre de la directiva: Nombre que sea comprensible para el usuario.

• Dirección URL del emisor: la dirección URL HTTPS del IdP que emite el token JWT.

• Reclamación de sujeto: la reclamación en el JWT que identifica el tipo de identidad autenticada. En Microsoft Entra ID, puede configurar los siguientes valores:

  • oid (Id. de objeto):seleccione si un usuario está pensado para acceder a los datos a través de una aplicación U2M, como PowerBI.
  • groups: seleccione si un grupo de usuarios está pensado para acceder a los datos a través de una aplicación U2M, como PowerBI.
  • azp: seleccione si una aplicación de OAuth está pensada para acceder a los datos a través de una aplicación M2M, como python Delta Sharing Client o Spark Delta Sharing Client.

  En otros IdP, se pueden usar notificaciones como sub u otras. Consulte la documentación del IdP para determinar la afirmación correcta para su caso de uso.

• Asunto: el usuario, grupo o aplicación específico que tiene permiso para acceder al recurso compartido.

• Audiencias: uno o varios identificadores de recursos con los cuales el JWT debe coincidir. Se considera que un token es válido si su notificación aud coincide con alguna de las audiencias enumeradas.

Si no está seguro acerca de los valores que debe usar (emisor, declaración de asunto, asunto, destinatario), consulte el ejemplo siguiente. Debe determinar los detalles de la directiva de federación de OIDC antes de crearla.

Si usa un IdP administrado por destinatario externo, solicite la siguiente información del destinatario compartido mediante un canal seguro. Si está utilizando el IdP gestionado por su proveedor interno, esta información procede de su propio IdP y se basa en las identidades con las que está compartiendo.

Ejemplo de U2M cuando IdP es Entra ID:

A continuación se muestran ejemplos de configuración para el uso compartido con un usuario determinado cuyo id. de objeto es 11111111-2222-3333-4444-555555555555 en el inquilino de Entra ID aaaaaaaa-bbbb-4ccc-dddd-eeeeeeeeeeee.

• Emisor: https://login.microsoftonline.com/aaaaaaaa-bbbb-4ccc-dddd-eeeeeeeeeeee/v2.0
• asunto de reclamación: oid (Id. de objeto)
• Asunto: 11111111-2222-3333-4444-555555555555
• Audiencias: 64978f70-f6a6-4204-a29e-87d74bfea138 (este es el identificador de cliente de la aplicación multiinquilino registrada por Databricks en Entra ID)

A continuación se muestran ejemplos de configuración para el uso compartido con un grupo determinado cuyo id. de objeto es 66666666-2222-3333-4444-555555555555 en el inquilino de Entra ID aaaaaaaa-bbbb-4ccc-dddd-eeeeeeeeeeee.

• Emisor: https://login.microsoftonline.com/aaaaaaaa-bbbb-4ccc-dddd-eeeeeeeeeeee/v2.0
• reclamación del sujeto: groups
• Asunto: 66666666-2222-3333-4444-555555555555
• Audiencias: 64978f70-f6a6-4204-a29e-87d74bfea138 (este es el identificador de cliente de la aplicación multiinquilino registrada por Databricks en Entra ID)

Para obtener más información sobre las aplicaciones U2M y sus directivas de federación de OIDC, consulte Recepción de recursos compartidos de Delta Sharing mediante la federación de Open ID Connect (OIDC) en un flujo de usuario a equipo (uso compartido abierto).

Ejemplo de M2M cuando IdP es Entra ID:

Para una aplicación de OAuth M2M con el identificador (cliente) de aplicación 11111111-2222-3333-4444-555555555555 en el inquilino de Entra ID aaaaaaaa-bbbb-4ccc-dddd-eeeeeeeeeeee:

• Emisor: https://login.microsoftonline.com/aaaaaaaa-bbbb-4ccc-dddd-eeeeeeeeeeee/v2.0
• Reclamación del sujeto: azp
• subject: 11111111-2222-3333-4444-555555555555 (Este es el identificador de aplicación (cliente), que es el identificador de cliente de la aplicación OAuth registrada y se puede encontrar en el portal de Entra ID del destinatario).
• Audiencias: 66666666-2222-3333-4444-555555555555 (puede ser cualquier identificador de audiencia válido definido por el destinatario, como el identificador de cliente de la aplicación OAuth registrada). Para obtener más información sobre las aplicaciones M2M y sus directivas de federación de OIDC, consulte Recepción de recursos compartidos de uso compartido delta mediante un cliente de Python y una federación de Open ID Connect (OIDC) en un flujo de máquina a máquina (uso compartido abierto).

Paso 3. Conceder al destinatario acceso a un recurso compartido

Una vez que haya creado el destinatario y creado recursos compartidos, puede conceder al destinatario acceso a esos recursos compartidos.

Para conceder acceso compartido a los destinatarios, puede usar Catalog Explorer, la CLI de Unity Catalog de Databricks o el comando SQL GRANT ON SHARE en un cuaderno de Azure Databricks o en el editor de consultas de Databricks SQL.

Permisos necesarios: uno de los siguientes:

• Administrador del metastore.
• Permisos delegados o control tanto en el recurso compartido como en los objetos de destinatario ((USE SHARE + SET SHARE PERMISSION) o propietario del recurso compartido) AND (USE RECIPIENT o propietario del destinatario).

Para obtener instrucciones, consulte Administrar el acceso a los recursos compartidos de datos de Delta Sharing (para proveedores).

Flujo de trabajo del destinatario

Para obtener información sobre cómo los destinatarios autentican y acceden a los recursos compartidos mediante la federación de tokens de OIDC, consulte:

• Recibir recursos compartidos de Delta Sharing mediante la federación de Open ID Connect (OIDC) en un flujo de usuario a máquina (uso compartido abierto)
• Recibir recursos compartidos de Delta Sharing mediante un cliente de Python y una federación de Open ID Connect (OIDC) en un flujo de máquina a máquina (uso compartido abierto)