Documentación de Oracle Cloud Infrastructure

Acerca de la integración de Oracle Autonomous Database con Microsoft Entra ID

Oracle Autonomous Database y Microsoft Entra ID se pueden configurar para permitir que los usuarios y las aplicaciones se conecten a la base de datos mediante sus credenciales de Entra ID.

Los usuarios y las aplicaciones de Azure pueden iniciar sesión con credenciales de inicio de sesión único (SSO) de Entra ID para acceder a la base de datos. Esto se realiza con un token de acceso OAuth2 de ID de Entra que el usuario o la aplicación primero solicita del ID de Entra. Este token de acceso OAuth2 contiene la identidad del usuario y la información de acceso a la base de datos y, a continuación, se envía a la base de datos. Consulte el artículo de Microsoft Opciones de autenticación sin contraseña para Azure Active Directory para obtener información sobre la configuración de la autenticación multifactor y sin contraseña.

Puede realizar esta integración en los siguientes entornos de Oracle Database:

  • Oracle Database local versión 19.18 y posteriores
  • Oracle Autonomous Database Serverless
  • Oracle Autonomous Database en infraestructura de Exadata dedicada
  • Oracle Base Database Service:
  • Oracle Exadata Cloud Service (Oracle ExaCS)
  • Todas las plataformas de servidor de Oracle Database: Linux, Windows, AIX, Solaris y HPUX

Las instrucciones para configurar Entra ID utilizan el término "Oracle Database" para abarcar estos entornos.

Este tipo de integración permite al usuario de Azure acceder a una instancia de Oracle Autonomous Database. Los usuarios y las aplicaciones de Azure pueden conectarse con credenciales de inicio de sesión único (SSO) de Entra ID para obtener un token de acceso OAuth2 de Entra ID para enviarlo a la base de datos.

El administrador de Entra ID crea y registra Oracle Autonomous Database con Entra ID. Dentro de Entra ID, esto se denomina registro de aplicación, que es la abreviatura de registro de solicitud. Esta es la información digital que Entra ID debe conocer sobre el software que utiliza Entra ID. El administrador de Entra ID también crea roles de aplicación (aplicación) para el registro de la aplicación de base de datos en Entra ID. Los roles de aplicación conectan usuarios, grupos y aplicaciones de Azure a esquemas y roles de base de datos. El administrador de Entra ID asigna usuarios, grupos o aplicaciones de Azure a los roles de aplicación. Estos roles de aplicación se asignan a un esquema global de base de datos o a un rol global o a un esquema y a un rol. Un usuario, grupo o aplicación de Azure asignado a un rol de aplicación se asignará a un esquema global de base de datos, a un rol global o a un esquema y a un rol. Los esquemas globales de Oracle también se pueden asignar exclusivamente a usuarios de Azure. Un usuario invitado de Azure (usuario no de organización) o una entidad de servicio de Entra ID (aplicación) solo se pueden asignar a un esquema global de base de datos mediante un rol de aplicación de Entra ID. Un rol global de Oracle solo puede asignarse desde un rol de aplicación de Azure y no puede asignarse desde un usuario de Azure.

Las herramientas de Oracle Autonomous Database, incluidas Oracle APEX, Database Actions, Oracle Graph Studio y la API de Oracle Database para MongoDB, no son compatibles con el uso de tokens Entra ID para conectarse a la base de datos.

Las herramientas y aplicaciones que se actualizan para soportar tokens Entra ID pueden autenticar usuarios directamente con el ID Entra y transferir el token de acceso a la base de datos a la instancia de Oracle Autonomous Database. Puede configurar herramientas de base de datos existentes como SQL*Plus para utilizar un token Entra ID desde una ubicación de archivo. En estos casos, los tokens de Entra ID se pueden recuperar mediante herramientas como Microsoft PowerShell o Azure CLI y colocarse en una ubicación de archivo. Los tokens de acceso a base de datos OAuth2 de Entra ID se emiten con una hora de caducidad. El controlador de cliente de Oracle Database garantizará que el token tenga un formato válido y que no haya caducado antes de transferirse a la base de datos. El ámbito del token es la base de datos, lo que significa que hay información en el token sobre la base de datos en la que se utilizará el token. Los roles de aplicación a los que se asignó el principal Entra ID en el registro de la aplicación Entra ID de la base de datos se incluyen como parte del token de acceso. La ubicación del directorio para el token Entra ID sólo debe tener permisos suficientes para que el usuario escriba el archivo de token en la ubicación y el cliente de base de datos recupere estos archivos (por ejemplo, simplemente lectura y escritura por parte del usuario). Dado que el token permite el acceso a la base de datos, debe estar protegido en el sistema de archivos.

Los usuarios de Azure pueden solicitar un token de Entra ID mediante una serie de métodos para abrir una ventana de conexión de Azure para introducir sus credenciales de Entra ID.

Oracle Autonomous Database acepta tokens que representan los siguientes principales de Entra ID:

  • Usuario de Azure, que es usuario registrado en el arrendamiento de Entra ID
  • Usuario invitado, que está registrado como usuario invitado en el arrendamiento de Entra ID
  • Servicio, que es la aplicación registrada que se conecta a la base de datos como ella misma con el flujo de credenciales del cliente (caso de uso de pool de conexiones)

Oracle Autonomous Database soporta los siguientes flujos de autenticación de Entra ID:

  • Flujo interactivo (también denominado flujo de código de autorización) que utiliza la clave de prueba para el intercambio de código (PKCE), que se utiliza con mayor frecuencia para usuarios humanos (no aplicaciones) para autenticarse en Entra ID en un entorno de cliente con un explorador
  • Credenciales de cliente, para aplicaciones de base de datos que se conectan como ellas mismas (y no como usuario final)
  • On-Behalf-Of (OBO), donde una aplicación solicita un token de acceso en nombre de un usuario conectado para enviarlo a la base de datos
  • Credencial de contraseña de propietario de recurso (ROPC), que no se recomienda para uso de producción, pero se puede utilizar en entornos de prueba donde sería difícil incorporar una autenticación de usuario de explorador emergente. ROPC necesita que el nombre de usuario y la credencial de contraseña de Entra ID formen parte de la llamada de solicitud de token.

Tema principal: Uso de Azure Active Directory (Azure AD) con Autonomous Database

Arquitectura de la integración de Oracle Database con Microsoft Azure AD

Los tokens de acceso de Microsoft Azure Active Directory siguen el estándar OAuth 2.0 con extensiones.

El token de acceso de Azure AD será necesario antes de acceder a la base de datos desde el cliente de base de datos (por ejemplo, con SQLPlus o SQLcl). Los clientes de Oracle (por ejemplo, OCI, JDBC y ODP) se pueden configurar para seleccionar un token de Azure AD desde una ubicación de archivo o el token se puede transferir al cliente a través de la API de cliente de base de datos. Un usuario de Azure puede utilizar un script (ejemplos disponibles de Microsoft) para recuperar un token y colocarlo en una ubicación de archivo para que el cliente de base de datos lo recupere. Las aplicaciones pueden utilizar el SDK de Azure para obtener un token de acceso y transferirlo a través de la API de cliente de base de datos. Las herramientas de línea de comandos como Microsoft PowerShell o la interfaz de línea de comandos de Azure se pueden utilizar para recuperar el token de Azure AD si la aplicación no puede obtener directamente el token.

El siguiente diagrama es un diagrama de flujo generalizado para el estándar OAuth 2.0, mediante el token OAuth2. Consulte Compatibilidad con el flujo de autenticación de MSAL en la documentación de Microsoft Azure AD para obtener más información sobre cada flujo soportado.

Descripción de azure-authentication.eps siguiente

El flujo de código de autorización es un estándar OAuth2 y se describe en detalle como parte de los estándares. Hay dos pasos en el flujo. El primer paso autentica al usuario y recupera el código de autorización. El segundo paso utiliza el código de autorización para obtener el token de acceso a la base de datos.

  1. El usuario de Azure AD solicita acceso al recurso, la instancia de Oracle Database.
  2. El cliente o la aplicación de la base de datos necesitan un código de autorización de Azure AD.
  3. Azure AD autenticación al usuario de Azure AD y devuelve el código de autorización.
  4. La herramienta auxiliar o la aplicación utiliza el código de autorización con Azure AD para intercambiarlo por el token OAuth2.
  5. El cliente de base de datos envía el token de acceso OAuth2 a la base de datos Oracle. El token incluye los roles de aplicación de base de datos a los que se ha asignado el usuario en el registro de la aplicación Azure AD para la base de datos.
  6. La instancia de Oracle Database utiliza la clave pública de Azure AD para verificar que Azure AD ha creado el token de acceso.

Tanto el cliente de base de datos como el servidor de base de datos deben estar registrados con la función registros de aplicaciones en la sección Azure Active Directory del portal de Azure. El cliente de base de datos debe estar registrado en el registro de la aplicación Azure AD. También se debe otorgar permiso para permitir que el cliente de base de datos obtenga un token de acceso para la base de datos.

Asignación de usuarios de Azure AD a un esquema y roles de Oracle Database

Los usuarios de Microsoft Azure deben estar asignados a un esquema de Oracle Database y tener los privilegios necesarios (mediante roles) antes de poder autenticarse en la instancia de Oracle Database.

En Microsoft Azure, un administrador de Azure AD puede asignar usuarios, grupos y aplicaciones a los roles de aplicación de base de datos.

La asignación exclusiva de un esquema de Azure AD a un esquema de base de datos requiere que el administrador de la base de datos cree un esquema de base de datos cuando el usuario de Azure AD se une a la organización o está autorizado a la base de datos. El administrador de la base de datos también debe modificar los privilegios y roles otorgados al esquema de base de datos para alinearlos con las tareas a las que está asignado el usuario de Azure AD. Cuando el usuario de Azure AD abandona la organización, el administrador de la base de datos debe borrar el esquema de base de datos para que no se deje una cuenta no utilizada en la base de datos. El uso de los roles de aplicación de base de datos permite al administrador de Azure AD controlar el acceso y los roles mediante la asignación de usuarios a roles de aplicación asignados a esquemas y roles globales. De esta forma, el acceso de los usuarios a la base de datos lo gestionan los administradores de Azure AD y los administradores de bases de datos no necesitan crear, gestionar y borrar esquemas para cada usuario.

Un usuario de Azure AD se puede asignar a un esquema de base de datos (usuario) de forma exclusiva o mediante un rol de aplicación.

  • Creación de una asignación exclusiva entre un usuario de Azure AD y un esquema de Oracle Database. En este tipo de asignación, se debe crear el esquema de base de datos para el usuario de Azure AD. Los privilegios y roles de base de datos que necesita el usuario de Azure AD se deben otorgar al esquema de base de datos. El esquema de base de datos no solo se debe crear cuando el usuario de Azure AD está autorizado a la base de datos, sino que los privilegios y roles otorgados se deben modificar a medida que cambian los roles y las tareas de Azure AD. Por último, el esquema de base de datos se debe borrar cuando el usuario de Azure AD abandona la organización.
  • Creación de una asignación compartida entre un rol de aplicación Azure AD y un esquema de Oracle Database. Este tipo de asignación, que es más común que las asignaciones exclusivas, es para los usuarios de Azure AD que se han asignado directamente al rol de aplicación o que son miembros de un grupo de Azure AD asignado al rol de aplicación. El rol de aplicación se asigna a un esquema de Oracle Database (asignación de esquema compartido). La asignación de esquema compartido permite que varios usuarios de Azure AD compartan el mismo esquema de Oracle Database, por lo que no es necesario crear un nuevo esquema de base de datos cada vez que un nuevo usuario se una a la organización. Esta eficiencia operativa permite a los administradores de bases de datos centrarse en las tareas de mantenimiento, rendimiento y ajuste de aplicaciones de la base de datos, en lugar de configurar nuevos usuarios, actualizar privilegios y roles y eliminar cuentas.

Además de otorgar directamente roles y privilegios de base de datos al esquema global asignado, se pueden otorgar roles y privilegios adicionales mediante roles globales asignados. Los distintos usuarios de Azure AD asignados al mismo esquema global compartido pueden necesitar diferentes privilegios y roles. Los roles de la aplicación Azure se pueden asignar a roles globales de Oracle Database. A los usuarios de Azure AD asignados al rol de aplicación o que sean miembros de un grupo de Azure AD asignado al rol de aplicación se les otorgará el rol global de Oracle Database cuando accedan a la base de datos.

En el siguiente diagrama se ilustran los diferentes tipos de asignaciones que están disponibles.

A continuación se muestra la descripción de azure_mappings.png

Estas asignaciones son las siguientes:

  • Un usuario de Azure AD se puede asignar directamente a un esquema global (usuario) de Oracle Database.
  • Se asigna un usuario de Azure AD, un grupo de Azure AD o una aplicación a un rol de aplicación que, a continuación, se asigna a un esquema (usuario) global de Oracle Database o a un rol global.

Casos de uso para conectarse a una instancia de Oracle Database mediante Azure AD

Oracle Database soporta varios casos de uso para conectarse a la base de datos.

  • Flujo de código de autorización OAuth2: este es el flujo más común para los usuarios humanos. El cliente dirige al usuario de Azure AD a Azure AD para obtener el código de autorización. Este código se utiliza para obtener el token de acceso a la base de datos. Consulte el artículo de Microsoft Azure Plataforma de identidad y flujo de código de autorización de OAuth 2.0.
  • Credenciales de contraseña de propietario de recurso (ROPC): este flujo no se recomienda para los servidores de producción. Es útil para el software de prueba que no puede funcionar con una ventana de autenticación emergente. Se utiliza en entornos de interfaz de usuario no gráficos cuando no se puede utilizar una ventana emergente para autenticar un usuario.
  • Credenciales de cliente: este flujo se utiliza para que las aplicaciones se conecten a la base de datos. La aplicación debe registrarse con el registro de la aplicación Azure AD y necesita un ID de cliente y una contraseña de cliente. Estas credenciales de cliente se deben utilizar para obtener el token de acceso a la base de datos de Azure AD cuando la aplicación se conecta a la base de datos. La aplicación puede transferir el token a través del sistema de archivos o a través de la API de cliente de base de datos.
  • Token en segundo plano (OBO): una aplicación Azure solicita un token OBO para un usuario conectado. El token OBO también será un token de acceso para la base de datos con la identidad de usuario de Azure AD y los roles de aplicación asignados para la base de datos. Esto permite al usuario de Azure AD conectarse a la base de datos como usuario y no a la aplicación. Solo una aplicación puede solicitar un token de OBO para su usuario de Azure AD y transferirlo al cliente de base de datos a través de la API.