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

Se necesitará el token de acceso Entra ID 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 Entra ID de 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 Entra ID 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 Authentication flow support in MSAL en la documentación de Microsoft Entra ID para obtener más información sobre cada flujo soportado.

Descripción de la ilustración azure-authentication.eps

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 solicita acceso al recurso, la instancia de Oracle Database.
2. El cliente o la aplicación de la base de datos solicitan un código de autorización de Entra ID.
3. Entra ID autentica el usuario de Azure y devuelve el código de autorización.
4. La herramienta auxiliar o la aplicación utiliza el código de autorización con el ID de Entra 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 la aplicación de base de datos a los que se asignó el usuario en el registro de la aplicación Entra ID para la base de datos.
6. La instancia de Oracle Database utiliza la clave pública Entra ID para verificar que el token de acceso ha sido creado por Entra ID.

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 con el registro de la aplicación Entra ID. 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.

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 Entra ID puede asignar usuarios, grupos y aplicaciones a los roles de aplicación de base de datos.

La asignación exclusiva de un usuario de Entra ID a un esquema de base de datos requiere que el administrador de la base de datos cree y gestione un esquema de base de datos para el ciclo de vida del usuario (unión, movimiento, abandono). El administrador de la base de datos debe crear el esquema cuando el usuario se une a la organización. El administrador de la base de datos también debe modificar los privilegios y roles que se otorgan al esquema de base de datos para alinearlos con las tareas a las que está asignado el usuario de Azure. Cuando el usuario de Azure abandona la organización, el administrador de la base de datos debe borrar el esquema de base de datos para que no quede 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 Entra ID controlar el acceso y los roles mediante la asignación de usuarios a roles de aplicación que están asignados a esquemas y roles globales. De esta forma, los administradores de Entra ID gestionan el acceso de usuario a la base de datos y los administradores de la base de datos no necesitan crear, gestionar ni borrar esquemas para cada usuario.

Un usuario de Azure 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 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. Los privilegios y roles de base de datos que necesita el usuario de Azure 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 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 Entra ID. Por último, el esquema de base de datos se debe borrar cuando el usuario de Azure abandona la organización.
• Creación de una asignación compartida entre un rol de aplicación Entra ID 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 que se han asignado directamente al rol de aplicación o que son miembros de un grupo de Entra ID 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 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 diferentes usuarios de Azure 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 asignados al rol de aplicación o que sean miembros de un grupo de ID de Entra 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.

Descripción de la ilustración azure_mappings.eps

Estas asignaciones son las siguientes:

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

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

• Flujo de código de autorización OAuth2: es el flujo más común para usuarios humanos. El cliente dirige al usuario de Azure a Entra ID 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 Entra ID 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 del ID de Entra 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 On-behalf-of (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 y los roles de aplicación asignados para la base de datos. Esto permite al usuario de Azure 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 y transferirlo al cliente de base de datos a través de la API.