Documentation Oracle Cloud Infrastructure

A propos de l'intégration d'Oracle Autonomous Database à Microsoft Entra ID

Oracle Autonomous Database et Microsoft Entra ID peuvent être configurés pour permettre aux utilisateurs et aux applications de se connecter à la base de données à l'aide de leurs informations d'identification Entra ID.

Les utilisateurs et les applications Azure peuvent se connecter à l'aide des informations d'identification SSO (Single Sign On) d'Intra ID pour accéder à la base de données. Pour ce faire, l'utilisateur ou l'application demande d'abord un jeton d'accès OAuth2 à partir de l'ID Entra. Ce jeton d'accès OAuth2 contient l'identité de l'utilisateur et les informations d'accès à la base de données, puis est envoyé à la base de données. Pour plus d'informations sur la configuration de l'authentification à plusieurs facteurs et sans mot de passe, reportez-vous à l'article Microsoft Options d'authentification sans mot de passe pour Azure Active Directory.

Vous pouvez effectuer cette intégration dans les environnements Oracle Database suivants :

  • Oracle Database sur site version 19.18 et versions ultérieures, à l'exception de 21c
  • Toutes les plates-formes de serveur Oracle Database : Linux, Windows, AIX, Solaris et HPUX
  • Oracle Autonomous Database Serverless
  • Oracle Autonomous Database sur une infrastructure Exadata dédiée
  • Oracle Autonomous Database on Exadata Cloud@Customer
  • Oracle Exadata Database Service on Dedicated Infrastructure
  • Oracle Exadata Database Service on Cloud@Customer
  • Oracle Base Database Service

Les instructions de configuration d'Entra ID utilisent le terme "Oracle Database" pour englober ces environnements.

Ce type d'intégration permet à l'utilisateur Azure d'accéder à une instance Oracle Autonomous Database. Les utilisateurs et les applications Azure peuvent se connecter à l'aide des informations d'identification SSO (accès avec connexion unique) d'Intra ID pour obtenir un jeton d'accès OAuth2 d'Intra ID à envoyer à la base de données.

L'administrateur Entra ID crée et inscrit Oracle Autonomous Database avec l'ID Entra. Dans Entra ID, il s'agit d'une inscription d'application, qui est courte pour l'enregistrement d'une application. Il s'agit des informations numériques que Entra ID doit connaître sur le logiciel qui utilise Entra ID. L'administrateur Entra ID crée également des rôles d'application pour l'inscription de l'application de base de données dans Entra ID. Les rôles d'application connectent les utilisateurs, les groupes et les applications Azure aux schémas et rôles de base de données. L'administrateur Entra ID affecte des utilisateurs, des groupes ou des applications Azure aux rôles d'application. Ces rôles d'application sont mis en correspondance avec un schéma global de base de données ou un rôle global, ou avec un schéma et un rôle. Un utilisateur, un groupe ou une application Azure affecté à un rôle d'application est mis en correspondance avec un schéma global de base de données, un rôle global ou avec un schéma et un rôle. Un schéma global Oracle peut également être mis en correspondance exclusivement avec un utilisateur Azure. Un utilisateur invité Azure (utilisateur non organisationnel) ou un principal de service (application) Entra ID ne peut être mis en correspondance qu'avec un schéma global de base de données via un rôle d'application Entra ID. Un rôle global Oracle peut uniquement être mis en correspondance à partir d'un rôle d'application Azure et ne peut pas être mis en correspondance à partir d'un utilisateur Azure.

Les outils Oracle Autonomous Database, notamment Oracle APEX, Database Actions, Oracle Graph Studio et l'API Oracle Database API for MongoDB, ne sont pas compatibles avec l'utilisation de jetons Entra ID pour la connexion à la base de données.

Les outils et applications mis à jour pour prendre en charge les jetons Entra ID peuvent authentifier les utilisateurs directement avec Entra ID et transmettre le jeton d'accès à la base de données à l'instance Oracle Autonomous Database. Vous pouvez configurer des outils de base de données existants tels que SQL*Plus pour utiliser un jeton Entra ID à partir d'un emplacement du fichier. Dans ces cas, les jetons Entra ID peuvent être extraits à l'aide d'outils tels que Microsoft PowerShell ou l'interface de ligne de commande d'Azure, puis placés dans un emplacement de fichier. Les jetons d'accès à la base de données OAuth2 avec l'ID Entra sont émis avec un délai d'expiration. Le pilote client Oracle Database vérifie que le jeton est dans un format valide et qu'il n'a pas expiré avant de le transmettre à la base de données. Le jeton est ciblé pour la base de données, ce qui signifie qu'il contient des informations sur la base de données dans laquelle le jeton sera utilisé. Les rôles d'application auxquels le principal d'ID Entra a été affecté dans l'inscription d'application d'ID Entra de la base de données sont inclus dans le jeton d'accès. Les droits d'accès de l'emplacement du répertoire de jeton Entra ID doivent être suffisants pour que l'utilisateur puisse écrire le fichier de jeton dans l'emplacement et le client de base de données puissent extraire ces fichiers (par exemple, l'utilisateur doit simplement disposer de droits d'accès en lecture et En écriture). Etant donné que le jeton autorise l'accès à la base de données, il doit être protégé dans le système de fichiers.

Les utilisateurs Azure peuvent demander un jeton à partir d'Entra ID à l'aide d'un certain nombre de méthodes pour ouvrir une fenêtre de connexion Azure afin de saisir leurs informations d'identification Entra ID.

Oracle Autonomous Database accepte les jetons représentant les principaux d'ID d'intra suivants :

  • Utilisateur Azure inscrit dans la location Entra ID
  • un utilisateur invité, inscrit comme utilisateur invité dans la location Entra ID ;
  • un service, soit l'application inscrite se connectant à la base de données en son nom avec le flux d'informations d'identification client (cas d'emploi de pool de connexions).

Oracle Autonomous Database prend en charge les flux d'authentification Entra ID suivants :

  • Flux interactif (également appelé flux de code d'autorisation) utilisant la clé de vérification pour l'échange de code (PKCE), le plus couramment utilisé pour les utilisateurs humains (et non les applications) afin de s'authentifier auprès d'Entra ID dans un environnement client avec un navigateur
  • les informations d'identification client, destinées aux applications qui se connectent en tant qu'utilisateur final (et non en tant qu'utilisateur final) ;
  • l'authentification OBO (au nom de), soit quand une application demande un jeton d'accès au nom d'un utilisateur connecté pour l'envoyer à la base de données.
  • Les informations d'identification par mot de passe du propriétaire de la ressource (ROPC), qui ne sont pas recommandées pour une utilisation en production, peuvent être utilisées dans des environnements de test où il serait difficile d'intégrer une authentification utilisateur via un navigateur contextuel. ROPC a besoin du nom utilisateur et des informations d'identification de mot de passe Entra ID pour faire partie de l'appel de demande de jeton.
Remarque

L'intégration DBaaS avec Microsoft Entra ID ne prend pas en charge les utilisateurs disposant de privilèges d'administration (SYSDBA, SYSOPER, SYSBACKUP, SYSDG, SYSKM et SYSRAC).

Sujets

Rubrique parent : Utilisation de Microsoft Entra ID avec Autonomous Database

Architecture de l'intégration d'Oracle Database avec Microsoft Entra ID

Les jetons d'accès Microsoft Azure Active Directory suivent la norme OAuth 2.0 avec des extensions.

Le jeton d'accès Entra ID sera nécessaire avant d'accéder à la base de données à partir du client de base de données (par exemple, avec SQLPlus ou SQLcl). Les clients Oracle (par exemple, OCI, JDBC et ODP) peuvent être configurés pour récupérer un jeton Entra ID à partir d'un emplacement de fichier ou le jeton peut être transmis au client via l'API client de base de données. Un utilisateur Azure peut utiliser un script (exemples disponibles auprès de Microsoft) pour extraire un jeton et le placer dans un emplacement de fichier que le client de base de données doit extraire. Les applications peuvent utiliser le kit SDK Azure pour obtenir un jeton d'accès et le transmettre via l'API client de base de données. Des outils de ligne de commande tels que Microsoft PowerShell ou l'interface de ligne de commande Azure peuvent être utilisés pour extraire le jeton Entra ID si l'application ne peut pas obtenir directement le jeton.

Le diagramme suivant est un diagramme de flux généralisé pour la norme OAuth 2.0, à l'aide du jeton OAuth2. Pour plus d'informations sur chaque flux pris en charge, reportez-vous à Prise en charge des flux d'authentification dans MSAL dans la documentation Microsoft Entra ID.

Description de l'image azure-authentication.eps
Description de l'image azure-authentication.eps

Le flux de code d'autorisation est une norme OAuth2 et est décrit en détail dans le cadre des normes. Il y a deux étapes dans le flux. La première étape authentifie l'utilisateur et extrait le code d'autorisation. La deuxième étape utilise le code d'autorisation pour obtenir le jeton d'accès à la base de données.

  1. L'utilisateur Azure demande l'accès à la ressource, à savoir l'instance Oracle Database.
  2. Le client ou l'application de base de données demande un code d'autorisation à partir de l'ID Entra.
  3. Entra ID authentifie l'utilisateur Azure et renvoie le code d'autorisation.
  4. L'outil d'aide ou l'application utilise le code d'autorisation avec l'ID Entra pour l'échanger contre le jeton OAuth2.
  5. Le client de base de données envoie le jeton d'accès OAuth2 à la base de données Oracle. Le jeton inclut les rôles d'application de base de données auxquels l'utilisateur a été affecté dans l'inscription de l'application Entra ID pour la base de données.
  6. L'instance Oracle Database utilise la clé publique Entra ID pour vérifier que le jeton d'accès a été créé par Entra ID.

Le client de base de données et le serveur de base de données doivent être inscrits auprès de la fonctionnalité Enregistrements d'application dans la section Azure Active Directory du portail Azure. Le client de base de données doit être inscrit auprès de l'inscription de l'application Entra ID. Un droit d'accès doit également être accordé pour permettre au client de base de données d'obtenir un jeton d'accès pour la base de données.

Mise en correspondance des utilisateurs Azure avec un schéma et des rôles Oracle Database

Les utilisateurs Microsoft Azure doivent être mis en correspondance avec un schéma Oracle Database et disposer des privilèges nécessaires (via un rôle) pour pouvoir s'authentifier auprès d'instance Oracle Database.

Dans Microsoft Azure, un administrateur Entra ID peut affecter des utilisateurs, des groupes et des applications aux rôles d'application de base de données.

La mise en correspondance exclusive d'un utilisateur Entra ID avec un schéma de base de données nécessite que l'administrateur de base de données crée et gère un schéma de base de données pour le cycle de vie de l'utilisateur (jointure, déplacement, départ). L'administrateur de base de données doit créer le schéma lorsque l'utilisateur rejoint l'organisation. L'administrateur de base de données doit également modifier les privilèges et les rôles accordés au schéma de base de données pour les aligner sur les tâches auxquelles l'utilisateur Azure est affecté. Lorsque l'utilisateur Azure quitte l'organisation, l'administrateur de base de données doit supprimer le schéma de base de données afin qu'aucun compte inutilisé ne soit laissé dans la base de données. L'utilisation des rôles d'application de base de données permet à l'administrateur Entra ID de contrôler les accès et les rôles en affectant des utilisateurs à des rôles d'application mappés avec des schémas globaux et des rôles globaux. Ainsi, l'accès utilisateur à la base de données est géré par les administrateurs Entra ID et les administrateurs de base de données n'ont pas besoin de créer, de gérer et de supprimer des schémas pour chaque utilisateur.

Un utilisateur Azure peut être mis en correspondance avec un schéma de base de données (utilisateur) exclusivement ou via un rôle d'application.

  • Création d'une mise en correspondance exclusive entre un utilisateur Azure et un schéma Oracle Database. Dans ce type de mise en correspondance, le schéma de base de données doit être créé pour l'utilisateur Azure. Les privilèges et rôles de base de données requis par l'utilisateur Azure doivent être accordés au schéma de base de données. Le schéma de base de données doit non seulement être créé lorsque l'utilisateur Azure est autorisé à accéder à la base de données, mais les privilèges et rôles accordés doivent être modifiés à mesure que les rôles et les tâches Entra ID changent. Enfin, le schéma de base de données doit être supprimé lorsque l'utilisateur Azure quitte l'organisation.
  • Création d'une mise en correspondance partagée entre un rôle d'application Entra ID et un schéma Oracle Database. Ce type de mise en correspondance, plus commun que les mises à correspondance exclusives, est destiné aux utilisateurs Azure auxquels le rôle d'application a été directement affecté ou qui est membre d'un groupe d'ID d'entrée auquel le rôle d'application est affecté. Le rôle d'application est mis en correspondance avec un schéma Oracle Database (mise en correspondance de schéma partagée). La correspondance de schéma partagée permet à plusieurs utilisateurs Azure de partager le même schéma Oracle Database, de sorte qu'il n'est pas nécessaire d'en créer un à chaque fois qu'un nouvel utilisateur rejoint l'organisation. Cette efficacité opérationnelle permet aux administrateurs de base de données de se concentrer sur les tâches liées à la maintenance, aux performances et au réglage de l'application de base de données au lieu d'avoir à configurer de nouveaux utilisateurs, à mettre à jour les privilèges et les rôles, et à enlever des comptes.

En plus des rôles et privilèges de base de données accordés directement au schéma global mis en correspondance, des rôles et privilèges supplémentaires peuvent être accordés via des rôles globaux mis en correspondance. Différents utilisateurs Azure mis en correspondance avec le même schéma global partagé peuvent avoir besoin d'autres privilèges et rôles. Les rôles d'application Azure peuvent être mis en correspondance avec les rôles globaux Oracle Database. Les utilisateurs Azure qui sont affectés au rôle d'application ou qui sont membres d'un groupe d'ID d'entrée affecté au rôle d'application se verront accorder le rôle global Oracle Database lorsqu'ils accèdent à la base de données.

Le schéma suivant illustre les différents types d'affectation et de mise en correspondance disponibles.

Description de l'image azure_mappings.eps
Description de l'illustration azure_mappings.eps

Ces mises en correspondance sont les suivantes :

  • Un utilisateur Azure peut être mis en correspondance directement avec un schéma global Oracle Database (utilisateur).
  • Un utilisateur Azure, un groupe Entra ID ou une application est affecté à un rôle d'application, puis ce rôle est mis en correspondance avec un schéma global Oracle Database (utilisateur) ou un rôle global.

Cas d'emploi de la connexion à Oracle Database à l'aide de l'ID d'emplacement

Oracle Database prend en charge plusieurs cas d'utilisation pour la connexion à la base de données.

  • Flux de code d'autorisation OAuth2 : il s'agit du flux le plus courant pour les utilisateurs humains. Le client dirige l'utilisateur Azure vers Entra ID pour obtenir le code d'autorisation. Ce code est utilisé pour obtenir le jeton d'accès à la base de données. Reportez-vous à l'article Microsoft Azure Plateforme d'identité Microsoft et flux de code d'autorisation OAuth 2.0.
  • Informations d'identification de mot de passe du propriétaire de ressource : ce flux n'est pas recommandé pour les serveurs de production. Il est utile pour les logiciels de test qui ne peuvent pas fonctionner avec une fenêtre d'authentification contextuelle. Il est utilisé dans les environnements d'interface utilisateur non graphiques lorsqu'une fenêtre instantanée ne peut pas être utilisée pour authentifier un utilisateur.
  • Informations d'identification client : ce flux permet aux applications de se connecter à la base de données. L'application doit s'inscrire auprès de l'inscription de l'application Entra ID et nécessite un ID client et un mot de passe client. Ces informations d'identification client doivent être utilisées pour obtenir le jeton d'accès à la base de données à partir d'Entra ID lorsque l'application se connecte à la base de données. L'application peut transmettre le jeton via le système de fichiers ou via l'API client de base de données.
  • Jeton Au nom de : une application Azure demande un jeton OBO pour un utilisateur connecté. Le jeton OBO sera également un jeton d'accès pour la base de données avec l'identité utilisateur Azure et les rôles d'application affectés de la base de données. Cela permet à l'utilisateur Azure de se connecter à la base de données en tant qu'utilisateur et non en tant que l'application. Seule une application peut demander un jeton OBO pour son utilisateur Azure et le transmettre au client de base de données via l'API.