Documentation sur Oracle Cloud Infrastructure

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

Oracle Autonomous AI 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 données d'identification Entra ID.

Les utilisateurs et les applications Azure peuvent se connecter avec les données d'identification d'authentification unique (SSO) Entra ID pour accéder à la base de données. Cela se fait avec un jeton d'accès Entra ID OAuth2 que l'utilisateur ou l'application demande d'abord à partir d'Entra ID. 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. Reportez-vous à l'article Microsoft Options d'authentification sans mot de passe pour Azure Active Directory pour plus d'informations sur la configuration de l'authentification multifacteur et sans mot de passe.

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

  • Oracle Database sur place version 19.18 et ultérieure, à l'exclusion de 21c
  • Toutes les plateformes de serveur Oracle Database : Linux, Windows, AIX, Solaris et HPUX
  • Oracle Autonomous AI Database sans serveur
  • Oracle Autonomous AI Database sur infrastructure Exadata dédiée
  • Oracle Autonomous AI Database on Exadata Cloud@Customer
  • Service Oracle Exadata Database sur une infrastructure dédiée
  • Service Oracle Exadata Database sur Cloud@Customer
  • Service de base de données de base Oracle

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 AI Database. Les utilisateurs et les applications Azure peuvent se connecter avec les données d'identification d'authentification unique (SSO) Entra ID pour obtenir un jeton d'accès Entra ID OAuth2 à envoyer à la base de données.

L'administrateur Entra ID crée et enregistre Oracle Autonomous AI Database avec Entra ID. Dans Entra ID, il s'agit d'un enregistrement d'application, qui est abrégé pour l'enregistrement d'application. Il s'agit des informations numériques qu'Entra ID doit connaître sur le logiciel qui utilise Entra ID. L'administrateur Entra ID crée également des rôles d'application (application) pour l'enregistrement 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 aux 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 mappés à un schéma global de base de données ou à un rôle global, ou à un schéma et à un rôle. Un utilisateur, un groupe ou une application Azure affecté à un rôle d'application sera mappé à un schéma global de base de données, à un rôle global ou à un schéma et à un rôle. Un schéma global Oracle peut également être mappé exclusivement à un utilisateur Azure. Un utilisateur invité Azure (utilisateur non organisationnel) ou un principal de service Entra ID (application) ne peut être mappé à un schéma global de base de données qu'au moyen d'un rôle d'application Entra ID. Un rôle global Oracle ne peut être mappé qu'à partir d'un rôle d'application Azure et ne peut pas être mappé à partir d'un utilisateur Azure.

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

Les outils et les 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 AI 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 de 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 Azure et placés dans un emplacement de fichier. Un jeton d'accès à la base de données Entra ID OAuth2 est émis avec un délai d'expiration. Le pilote du client Oracle Database s'assure que le jeton a 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 où le jeton sera utilisé. Les rôles d'application auxquels le principal Entra ID a été affecté dans l'enregistrement de l'application Entra ID de la base de données sont inclus dans le jeton d'accès. L'emplacement de répertoire du jeton d'ID Entra doit disposer de l'autorisation suffisante pour que l'utilisateur puisse y écrire le fichier de jeton et pour que le client de base de données puisse récupérer ces fichiers (par exemple, lecture et écriture par l'utilisateur). Comme 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 d'entrer leurs données d'identification Entra ID.

Oracle Autonomous AI Database accepte les jetons représentant les principaux Entra ID suivants :

  • Utilisateur Azure, qui est inscrit dans la location Entra ID
  • Utilisateur invité : en tant qu'utilisateur invité dans la location Entra ID
  • Service : application enregistrée qui se connecte à la base de données en tant qu'elle-même avec le flux de données d'identification de client (cas d'utilisation de la réserve de connexions)

Oracle Autonomous AI Database prend en charge les flux d'authentification intra-ID suivants :

  • Flux interactif (également appelé flux de code d'autorisation) à l'aide de la clé de vérification pour l'échange de code (PKCE), le plus couramment utilisé par les utilisateurs humains (et non par les applications) pour s'authentifier auprès d'Entra ID dans un environnement client avec un navigateur
  • Données d'identification de client, qui concernent les applications de base de données qui se connectent elles-mêmes (et non l'utilisateur final)
  • OBO (au nom de), où une application demande un jeton d'accès au nom d'un utilisateur connecté pour l'envoyer à la base de données
  • Données d'identification de mot de passe du responsable de la ressource (ROPC), qui ne sont pas recommandées pour une utilisation en production, mais peuvent être utilisées dans des environnements de test où une authentification de l'utilisateur dans un navigateur contextuel serait difficile à intégrer. ROPC a besoin du nom d'utilisateur et des données d'identification de mot de passe Entra ID pour faire partie de l'appel de demande de jeton.
Note

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

Rubriques connexes

Rubrique parent : Utiliser Microsoft Entra ID avec Autonomous AI 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 que vous accédiez à 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 au moyen de 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 pour le client de base de données à extraire. Les applications peuvent utiliser la trousse SDK Azure pour obtenir un jeton d'accès et le transmettre au moyen de l'API client de base de données. Les 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. Voir Prise en charge des flux d'authentification dans MSAL dans la documentation Microsoft Entra ID pour plus de détails sur chaque flux pris en charge.

Description de l'azur-authentication.eps
Description de l'illustration 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, l'instance Oracle Database.
  2. Le client ou l'application de base de données demande un code d'autorisation à partir d'Entra ID.
  3. Entra ID authentifie l'utilisateur Azure et retourne le code d'autorisation.
  4. L'outil ou l'application d'aide 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'enregistrement 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 enregistrés avec la fonction Enregistrements d'application dans la section Azure Active Directory du portail Azure. Le client de base de données doit être enregistré avec l'enregistrement de l'application Entra ID. Une autorisation doit également être accordée pour permettre au client de base de données d'obtenir un jeton d'accès pour la base de données.

Mappage des utilisateurs Azure à un schéma et à des rôles Oracle Database

Les utilisateurs Microsoft Azure doivent être mappés à un schéma Oracle Database et disposer des privilèges nécessaires (par des rôles) pour pouvoir s'identifier à l'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.

Le mappage exclusif d'un utilisateur Entra ID à 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 joint 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'un compte inutilisé ne reste pas 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 l'accès et les rôles en affectant des utilisateurs aux rôles d'application mappés aux schémas globaux et aux rôles globaux. De cette façon, 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 mappé à un schéma de base de données (utilisateur) uniquement ou au moyen d'un rôle d'application.

  • Création d'un mappage exclusif entre un utilisateur Azure et un schéma Oracle Database. Dans ce type de mappage, le schéma de base de données doit être créé pour l'utilisateur Azure. Les privilèges et les 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é à la base de données, mais les privilèges et les rôles accordés doivent être modifiés à mesure que les rôles et 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'un mappage partagé entre un rôle d'application Entra ID et un schéma Oracle Database. Ce type de mappage, plus commun que les mappages exclusifs, est destiné aux utilisateurs Azure qui ont été affectés directement au rôle d'application ou qui sont membres d'un groupe Entra ID affecté au rôle d'application. Le rôle d'application est mappé à un schéma Oracle Database (mappage de schéma partagé). Le mappage de schéma partagé permet à plusieurs utilisateurs Azure de partager le même schéma Oracle Database, de sorte qu'il n'est pas nécessaire de créer un nouveau schéma de base de données 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 de maintenance, de performance et de réglage des applications de base de données au lieu de configurer de nouveaux utilisateurs, de mettre à jour les privilèges et les rôles et de supprimer des comptes.

En plus des rôles de base de données et des privilèges accordés directement au schéma global mappé, des rôles et privilèges supplémentaires peuvent être accordés via des rôles globaux mappés. Différents utilisateurs Azure mappés au même schéma global partagé peuvent avoir besoin de privilèges et de rôles différents. Les rôles d'application Azure peuvent être mappés à des rôles globaux Oracle Database. Les utilisateurs Azure qui sont affectés au rôle d'application ou qui sont membres d'un groupe Entra ID 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 diagramme suivant illustre les différents types d'affectations et de mappages disponibles.

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

Ces mappages sont les suivants :

  • Un utilisateur Azure peut être mappé directement à un schéma global (utilisateur) d'Oracle Database.
  • Un utilisateur Azure, un groupe Entra ID ou une application est affecté à un rôle d'application, qui est ensuite mappé à un schéma global (utilisateur) d'Oracle Database ou à un rôle global.

Cas d'utilisation pour la connexion à une base de données Oracle Database à l'aide d'Entra ID

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. Voir l'article Microsoft Azure Plate-forme d'identités Microsoft et flux de code d'autorisation OAuth 2.0.
  • Données d'identification par mot de passe du responsable de la ressource (ROPC) : 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. Utilisé dans des environnements d'interface utilisateur non graphique lorsqu'une fenêtre contextuelle ne peut pas être utilisée pour authentifier un utilisateur.
  • Données d'identification du client : Ce flux est utilisé pour les applications qui se connectent à la base de données. L'application doit s'inscrire avec l'enregistrement de l'application Entra ID et nécessite un ID client et un mot de passe client. Ces données d'identification de client doivent être utilisées pour obtenir le jeton d'accès à la base de données à partir de l'ID Entra lorsque l'application se connecte à la base de données. L'application peut transmettre le jeton au moyen du système de fichiers ou de l'API client de base de données.
  • Demi-jeton (OBO) : 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é de l'utilisateur Azure et les rôles d'application affectés pour 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 qu'utilisateur. Seule une application peut demander un jeton OBO pour son utilisateur Azure et le transmettre au client de base de données au moyen de l'API.