Ya disponible (GA): Creación de Databricks Apps basadas en permisos con autorización en nombre del usuario

Databricks Apps permite a los desarrolladores crear e implementar aplicaciones de datos e IA directamente en la plataforma Databricks, desde paneles interactivos y herramientas operativas hasta agentes de IA personalizados.

Ahora disponible de forma general, la autorización en nombre del usuario (OBO) permite crear aplicaciones que ofrecen experiencias personalizadas y adaptadas a los permisos sin tener que volver a implementar las reglas de gobernanza de datos en el código de la aplicación. Cuando una aplicación llama a las API de Databricks compatibles con OBO, actúa utilizando la identidad del usuario que inició sesión: Unity Catalog aplica los permisos de datos existentes de ese usuario, incluidos los filtros de fila y las máscaras de columna, y los alcances de la API limitan las operaciones que la aplicación puede realizar en nombre del usuario. Las aplicaciones pueden seguir utilizando su entidad de servicio dedicada para las operaciones propias de la aplicación, como la lectura de la configuración compartida o la escritura de métricas de la aplicación.

Por ejemplo, un asistente de insights de ventas puede responder preguntas utilizando únicamente las cuentas y los campos a los que el vendedor está autorizado a acceder, sin otorgar a la aplicación amplias capacidades de SQL o de administración del espacio de trabajo.

Comience con la identidad que rige cada operación

Al diseñar una aplicación, pregúntese: ¿Los permisos de quién deberían regir esta operación en particular?

Databricks Apps admite dos modelos de autorización complementarios: la autorización de la aplicación y la autorización del usuario. La autorización de la aplicación utiliza la entidad de servicio dedicada de la aplicación y es adecuada para operaciones propias de la aplicación o experiencias que deberían devolver el mismo resultado a todos los usuarios. La autorización del usuario utiliza la identidad del usuario que inició sesión cuando los permisos de ese usuario deben regir una operación. La mayoría de las aplicaciones de producción pueden utilizar ambos modelos, eligiendo la identidad adecuada para cada ruta de solicitud. Consulte Configurar la autorización en una aplicación de Databricks.

Considere una aplicación que responda a preguntas como: ¿Cómo se están desempeñando mis cuentas este trimestre y qué explica el cambio? La aplicación necesita:

• Consultar datos de ventas y clientes como el usuario solicitante.
• Respetar los permisos de Unity Catalog, incluidos los filtros a nivel de fila y las máscaras de columna.
• Devolver análisis de solo lectura.
• Opcionalmente, llamar a un servicio independiente para resumir los resultados.
• Evitar modificar datos o administrar recursos de SQL.

Esto se adapta de forma natural a la autorización del usuario. La aplicación pasa el token de acceso reenviado del usuario solicitante al conector SQL, y Databricks evalúa la consulta utilizando el SQL warehouse existente de ese usuario y los permisos de Unity Catalog. Un gerente regional podría ver solo las cuentas de su región, mientras que un líder nacional vería todas las regiones, sin que la aplicación tenga que volver a crear esas reglas en el código. Cuando los administradores actualizan las políticas de Unity Catalog, las solicitudes posteriores de la aplicación reflejan esos cambios. 

El permiso del usuario determina qué datos puede devolver la consulta. La siguiente decisión de diseño es qué se le permite hacer a la aplicación en nombre del usuario con el token de usuario reenviado.

Utilice el alcance de API más estrecho que se adapte a la tarea

El asistente de insights de ventas necesita ejecutar consultas de solo lectura. No necesita un acceso amplio a SQL para administrar recursos o realizar otras operaciones de SQL. Por esa razón, debe solicitar sql:restricted-query en lugar del alcance más amplio sql. 

sql:restricted-query permite a la aplicación ejecutar consultas SQL de solo lectura. No permite que la aplicación realice otras operaciones de SQL. Esto crea una mejor coincidencia entre el comportamiento del producto de la aplicación y su límite de autorización: la aplicación puede leer datos gobernados para su análisis, pero no puede usar la identidad del usuario como una credencial operativa general de SQL.

Si la aplicación también invoca a Genie o Unity Gateway en nombre de un usuario, solicite únicamente los alcances correspondientes, como genie o ai-gateway. No solicite files, model-serving o vector-search a menos que la aplicación realmente utilice esas capacidades. 

Los alcances son un límite máximo de capacidad, no una concesión de acceso a los datos. La aplicación debe tener el alcance de API adecuado, y el usuario aún debe tener permiso para acceder al recurso de destino. Consulte Seguridad basada en alcances y escalada de privilegios.

Configure la aplicación con un alcance de API explícito

Configure la autorización del usuario en la UI de Databricks o en un Declarative Automation Bundle. 

Para un asistente de análisis de solo lectura, la aplicación puede declarar:

Nota: El alcance de la API forma parte de la configuración de autorización de usuario declarada de la aplicación. No otorga acceso a un SQL warehouse ni a los datos de Unity Catalog. El usuario solicitante aún debe tener permitido utilizar el SQL warehouse de destino y tener los privilegios de Unity Catalog requeridos sobre los datos que se consultan. 

Cuando un usuario accede por primera vez a una aplicación autorizada por el usuario, Databricks le solicita que dé su consentimiento para los alcances de API solicitados. 

Pasar la identidad del usuario al conector SQL

Databricks reenvía el token de acceso del usuario actual en el encabezado HTTP x-forwarded-access-token. La aplicación debe recuperar ese token para la solicitud que necesita acceso al contexto del usuario y pasarlo al conector SQL.

El siguiente ejemplo utiliza Flask y el Databricks SQL Connector para Python para hacer explícito el flujo de tokens. Si crea la aplicación con Databricks AppKit, aplique el mismo principio de autorización: utilice el cliente de contexto de usuario o la identidad en tiempo de solicitud para las operaciones específicas del usuario, y mantenga las operaciones propias de la aplicación en la identidad de la aplicación.

Nota: El token reenviado es de corta duración y por solicitud. La aplicación lo lee en cada solicitud y nunca lo almacena entre solicitudes ni en una sesión. 

La diferencia importante con la autorización de la aplicación es que el conector recibe el token de usuario reenviado a través de access_token. El alcance de la API sql:restricted-query limita la aplicación a la capacidad de SQL de solo lectura que necesita, mientras que Unity Catalog determina a qué filas y columnas puede acceder realmente ese usuario. Consulta Consulta con autorización de usuario.

Permite que los administradores del espacio de trabajo establezcan el límite superior

Los desarrolladores especifican qué alcances de API necesita su aplicación. Los administradores del espacio de trabajo pueden controlar qué alcances de API tienen permitido agregar los desarrolladores a las aplicaciones en el espacio de trabajo.

Esta política permite a los equipos crear experiencias de análisis e IA de solo lectura, al tiempo que evita que las aplicaciones soliciten capacidades más amplias o no relacionadas. Un desarrollador de aplicaciones no puede expandir la autorización de la aplicación más allá del límite de alcance de API configurado para el espacio de trabajo.

Esto proporciona a las organizaciones dos niveles de control:

• La aplicación declara los alcances de API mínimos requeridos para su funcionamiento.
• El administrador del espacio de trabajo define los alcances de API máximos disponibles para las aplicaciones en ese espacio de trabajo.

Los administradores del espacio de trabajo configuran esta lista de permitidos en Configuración > Desarrollo > Aplicaciones. La configuración predeterminada incluye todas las API compatibles, se puede limitar a alcances de API seleccionados o se puede establecer en Ninguno para deshabilitar la autorización de usuario. Consulta Restringir los alcances de autorización de usuario.

Los administradores de la cuenta pueden agregar alcances incluso cuando estos no estén incluidos en la lista de permitidos del espacio de trabajo. Si un administrador elimina posteriormente un alcance permitido, las aplicaciones que ya se estén ejecutando con ese alcance pueden continuar haciéndolo, pero no se podrán iniciar, implementar ni actualizar hasta que se elimine el alcance no permitido.

Mantén separadas las operaciones propiedad de la aplicación y las propiedad del usuario

Muchas aplicaciones útiles necesitan ambos modelos de autorización. El asistente de información de ventas podría usar:

• Un cliente con alcance de aplicación para escribir métricas de la aplicación o leer la configuración compartida.
• Un cliente con alcance de usuario con sql:restricted-query para consultar datos del usuario actual.
• Un alcance de API de usuario independiente si necesita invocar otro servicio de Databricks en nombre del usuario.

Se recomienda hacer explícito ese límite de identidad en el código de la aplicación en lugar de crear un único cliente genérico y reutilizarlo en todas partes. El uso de dependencias, nombres y pruebas independientes ayuda a evitar que se use una credencial de la aplicación para una ruta específica del usuario o que se retenga un token de usuario para tareas en segundo plano.

Si una solicitud requiere autorización de usuario y falta el token reenviado, opta por un fallo seguro (fail closed) en lugar de cambiar de forma silenciosa a la entidad principal de servicio de la aplicación. De lo contrario, la aplicación podría devolver una respuesta que parezca válida pero que se generó con permisos diferentes. Por eso query_as_user en el ejemplo anterior comienza con require_user_token en lugar de controlar la falta de encabezado en línea.

Aplica el mismo patrón a los agentes

Los agentes personalizados implementados en Databricks Apps pueden usar el mismo modelo. Inicializa el cliente del espacio de trabajo con alcance de usuario dentro del controlador invoke o stream en el momento de la solicitud (y no al iniciar la aplicación), ya que el token de usuario reenviado solo está disponible durante una solicitud de usuario activa. Usa la autorización de la aplicación para recursos compartidos y operaciones en segundo plano. Consulta Autenticación para agentes.
 

Protege la implementación

• Solicita únicamente los alcances de API mínimos requeridos.
• Mantén separados los clientes propiedad de la aplicación y los autorizados por el usuario en el código, las pruebas y la conexión de dependencias.
• Nunca imprimas, registres ni persistas los tokens de acceso reenviados.
• Restringe la gestión de aplicaciones a desarrolladores de confianza y exige la revisión por pares para los cambios relacionados con la autorización.
• Usa la autorización de la aplicación para operaciones compartidas y en segundo plano en lugar de retener tokens de usuario.
• Realiza pruebas con usuarios que tengan diferentes accesos en Unity Catalog y, luego, repite esas pruebas después de realizar cambios en las políticas.

Comenzar

La autorización en nombre del usuario te ofrece personalización y gobernanza mediante el mismo mecanismo. Los permisos de Unity Catalog del usuario deciden a qué datos puede acceder una aplicación, y el alcance de API coincidente más restringido decide qué puede hacer en su nombre. Para comenzar, consulta nuestra documentación de ayuda para obtener más recursos y mejores prácticas.

(Esta entrada del blog ha sido traducida utilizando herramientas basadas en inteligencia artificial) Publicación original