Documentation sur Oracle Cloud Infrastructure

Authentification et autorisation des utilisateurs Microsoft Entra ID (MS-EI) pour des bases de données Oracle sur le service Oracle Exadata Database Service on Dedicated Infrastructure

Vous pouvez configurer Oracle Database pour que les utilisateurs Microsoft Azure de Microsoft Entra ID puissent se connecter à l'aide de l'authentification unique.

Rubrique parent : Guides pratiques

À propos de l'autorisation des utilisateurs Microsoft Entra ID (MS-EI) pour des bases de données Oracle sur le service Oracle Exadata Database Service on Dedicated Infrastructure

Les utilisateurs d'Oracle Exadata Database Service on Dedicated Infrastructure peuvent être gérés de manière centralisée dans un service MS-EI.

L'intégration d'Oracle Database à MS-EI est prise en charge pour les bases de données sur place et la plupart des plates-formes Oracle OCI DBaaS.

Les instructions de configuration de MS-EI utilisent le terme Oracle Database pour englober ces environnements.

This type of integration enables the MS-EI user to access an Oracle Exadata Database Service on Dedicated Infrastructure instance. Les utilisateurs et les applications MS-EI peuvent se connecter avec les identifiants d'authentification unique MS-EI (SSO) pour obtenir un jeton d'accès MS-EI OAuth2 à envoyer à la base de données.

L'administrateur crée et configure l'enregistrement d'application (enregistrement d'application) de l'instance Oracle Exadata Database Service on Dedicated Infrastructure avec MS-EI. L'administrateur crée également des rôles d'application pour l'enregistrement de l'application de base de données dans MS-EI et affecte ces rôles aux utilisateurs, groupes et applications MS-EI. Ces rôles d'application seront mappés aux schémas et rôles globaux de la base de données. Un principal MS-EI affecté à un rôle d'application sera mappé à un schéma global de base de données ou à un rôle global de base de données. Un schéma mondial d'Oracle peut également être mappé exclusivement à un utilisateur MS-EI. Lorsque le principal est un utilisateur invité ou un principal de service, ils ne peuvent être mappés au schéma de base de données qu'au moyen d'un rôle d'application MS-EI. Un rôle global Oracle ne peut être mappé à un rôle d'application MS-EI.

Les outils et les applications mis à jour pour prendre en charge les jetons MS-EI peuvent authentifier les utilisateurs directement auprès de MS-EI et transmettre le jeton d'accès à la base de données à l'instance Oracle Exadata Database Service on Dedicated Infrastructure. Vous pouvez configurer des outils de base de données existants tels que SQL*Plus pour utiliser un jeton MS-EI à partir d'un emplacement de fichier ou obtenir le jeton directement à partir de MS-EI. Lorsque vous utilisez un utilitaire pour obtenir le jeton à transmettre au pilote du client de base de données via un emplacement de fichier, les jetons MS-EI 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 OAuth2 MS-EI est un jeton de porteur 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. La portée du jeton est la base de données. Les rôles d'application affectés au principal Azure AD sont inclus dans le jeton d'accès. L'emplacement de répertoire du jeton MS-EI ne doit disposer que des autorisations suffisantes pour que l'utilisateur y écrive le fichier du jeton et pour que le client de base de données récupère ces fichiers (par exemple, lecture et écriture par l'utilisateur du processus). 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 de MS-EI peuvent demander un jeton en tant que client enregistré avec l'enregistrement de l'application MS-EI à l'aide de méthodes telles que :

  • Entrée des données d'identification MS-EI dans un écran d'authentification MS-EI avec ou sans authentification multifacteur

Le service Oracle Exadata Database Service on Dedicated Infrastructure prend en charge les flux d'authentification MS-EI suivants :

  • Flux interactif (code d'autorisation), utilisé lorsqu'un navigateur peut être utilisé pour entrer des données d'identification pour l'utilisateur
  • Données d'identification de client, qui concernent les applications qui se connectent en tant qu'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
  • ROPC est également pris en charge pour les environnements de test et de développement

Le service Oracle Exadata Database Service on Dedicated Infrastructure accepte les jetons représentant les principaux MS-EI suivants :

  • Utilisateur MS-EI, utilisateur enregistré dans la location MS-EI
  • Utilisateur invité, qui est inscrit en tant qu'utilisateur invité dans la location MS-EI
  • 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)

Configuration de l'intégration d'Oracle Database pour Microsoft Entra ID (MS-EI)

L'intégration MS-EI à l'instance Oracle Database nécessite que la base de données soit enregistrée auprès de MS-EI afin que la base de données puisse demander la clé publique MS-EI.

Pour plus d'informations sur la configuration de MS-EI, la configuration de la base de données et la configuration du client de base de données, voir :

Parent topic: Authenticating and Authorizing Microsoft Entra ID (MS-EI) Users for Oracle Databases on Oracle Exadata Database Service on Dedicated Infrastructure

Préalables pour l'authentification Microsoft Entra ID (MS-EI)

Vérifiez les préalables à l'intégration d'Oracle Database à MS-EI.

L'intégration MS-EI avec Oracle Database sur Oracle Exadata Database Service on Dedicated Infrastructure nécessite :

  1. Oracle Database version 19.18 ou supérieure.
  2. Connectivité à la base de données sur le port TLS 2484. Les connexions non TLS ne sont pas prises en charge.
  3. Connectivité réseau sortante à MS-EI afin que la base de données puisse demander la clé publique MS-EI.
  4. Oracle Database à enregistrer auprès de MS-EI.
  5. Les utilisateurs et les applications qui doivent demander un jeton MS-EI doivent également être en mesure d'avoir une connectivité réseau avec MS-EI. Vous devrez peut-être configurer un paramètre de mandataire pour la connexion.
  6. Pour les déploiements Oracle Exadata Database Service on Dedicated Infrastructure, les paramètres du mandataire HTTP de votre environnement doivent permettre à la base de données d'utiliser MS-EI.

    These settings are defined by your fleet administrator while creating the Oracle Exadata Database Service on Dedicated Infrastructure infrastructure as described in To create a Cloud Exadata infrastructure resource.

    Note

    La configuration réseau, y compris le mandataire HTTP, ne peut être modifiée que jusqu'à ce que l'infrastructure Exadata ait l'état Activation requise. Une fois activé, vous ne pouvez pas modifier ces paramètres.

    La configuration d'un mandataire HTTP pour une infrastructure Exadata déjà provisionnée nécessite une demande de service dans My Oracle Support. Pour plus de détails, voir Créer une demande de service dans My Oracle Support.

Préalables pour l'authentification Microsoft Entra ID (MS-EI)

Avant d'utiliser l'authentification Azure AD dans les bases de données de l'infrastructure Exadata Cloud, vous devez utiliser le service de réseau pour ajouter une passerelle de service, une règle de routage et une règle de sécurité de trafic sortant au réseau en nuage virtuel et aux sous-réseaux où résident vos ressources de base de données.

  1. Créez une passerelle de service dans le réseau en nuage virtuel où résident vos ressources de base de données autonome en suivant les instructions sous Tâche 1 : Créer la passerelle de service dans la documentation sur OCI.
  2. Après avoir créé la passerelle de service, ajoutez une règle de routage et une règle de sécurité de trafic sortant à chaque sous-réseau (dans le VCN) où résident des ressources de base de données afin que ces ressources puissent utiliser la passerelle pour utiliser l'authentification Azure AD :
    1. Allez à la page Détails du sous-réseau associée au sous-réseau.
    2. Dans l'onglet Informations sur le sous-réseau, cliquez sur le nom de la table de routage du sous-réseau pour afficher la page Détails de la table de routage.
    3. Dans la table des règles de routage existantes, vérifiez s'il existe déjà une règle présentant les caractéristiques suivantes :
      • Destination : 0.0.0.0/0
      • Type de cible : Passerelle NAT
      • Cible : Nom de la passerelle NAT que vous venez de créer dans le VCN

      Si une telle règle n'existe pas, cliquez sur Ajouter des règles de routage et ajoutez une règle de routage avec ces caractéristiques.

    4. Retournez à la page Détails du sous-réseau.
    5. Dans la table Listes de sécurité du sous-réseau, cliquez sur le nom de la liste de sécurité du sous-réseau pour afficher la page Détails de la liste de sécurité.
    6. Dans le menu latéral, sous Ressources, cliquez sur Règles de trafic sortant.
    7. Dans la table des règles de trafic sortant existantes, vérifiez s'il existe déjà une règle présentant les caractéristiques suivantes :
      • Type de destination : CIDR
      • Destination : 0.0.0.0/0
      • Protocole IP : TCP
      • Intervalle de ports sources : 443
      • Intervalle de ports de destination : Tout
    8. Si une telle règle n'existe pas, cliquez sur Ajouter des règles de trafic sortant et ajoutez une règle de trafic sortant avec ces caractéristiques.

Configurer TLS pour utiliser des jetons Microsoft Entra ID (MS-EI)

Lors de l'envoi de jetons MS-EI du client de base de données au serveur de base de données, une connexion TLS doit être établie.

Le portefeuille TLS doté du certificat de base de données pour l'instance de service ExaDB-D doit être stocké dans l'emplacement WALLET_ROOT. Créez un répertoire tls qui ressemble à : WALLET_ROOT/<PDB GUID>/tls.

Lors de la configuration de TLS entre le client et le serveur de base de données, plusieurs options sont à prendre en compte.

  • Utilisation d'un certificat de serveur de base de données auto-signé ou d'un certificat de serveur de base de données signé par une autorité de certification connue
  • Authentification TLS unidirectionnelle (TLS) ou authentification TLS mutuelle ou bidirectionnelle (mTLS)
  • Client avec ou sans portefeuille

Certificat auto-signé

L'utilisation d'un certificat auto-signé est une pratique commune pour les ressources informatiques en interne, car vous pouvez les créer vous-même et gratuitement. La ressource (ici, le serveur de base de données) aura un certificat auto-signé pour s'authentifier auprès du client de base de données. Le certificat auto-signé et le certificat racine seront stockés dans le portefeuille du serveur de base de données. Pour que le client de base de données puisse reconnaître le certificat du serveur de base de données, une copie du certificat racine sera également nécessaire sur le client. Ce certificat racine créé automatiquement peut être stocké dans un portefeuille côté client ou installé dans le magasin de certificats par défaut du système client (Windows et Linux uniquement). Lorsque la session est établie, le client de base de données vérifie que le certificat envoyé par le serveur de base de données a été signé par le même certificat racine.

Autorité de certification bien connue

L'utilisation d'une autorité de certification racine connue présente certains avantages dans la mesure où le certificat racine est probablement déjà stocké dans le magasin de certificats par défaut du système client. Aucune étape supplémentaire n'est requise pour le client pour le stockage du certificat racine si celui-ci est un certificat racine commun. L'inconvénient est que généralement, cela représente un coût.

Authentification TLS unidirectionnelle

Dans la session TLS standard, seul le serveur fournit un certificat au client pour lui permettre de s'authentifier. Le client n'a pas besoin de disposer d'un certificat client distinct pour s'authentifier auprès du serveur (comme pour l'établissement des sessions HTTPS). Alors que la base de données nécessite un portefeuille pour stocker le certificat du serveur, la seule chose dont le client a besoin est le certificat racine utilisé pour signer le certificat du serveur.

Authentification TLS bidirectionnelle (également appelée authentification TLS mutuelle, mTLS)

Dans mTLS, le client et le serveur disposent tous deux de certificats d'identité qui sont présentés l'un à l'autre. Dans la plupart des cas, le même certificat racine aura signé ces deux certificats de sorte que le même certificat racine puisse être utilisé avec le serveur et le client de base de données pour authentifier l'autre certificat. mTLS est parfois utilisé pour authentifier l'utilisateur puisque l'identité de l'utilisateur est authentifiée par le serveur de base de données au moyen du certificat. Bien que non nécessaire, cela peut être utilisé lors de la transmission de jetons GIA.

Client avec un portefeuille

Un portefeuille de client est obligatoire lors de l'utilisation de mTLS pour stocker le certificat de client. Toutefois, le certificat racine peut être stocké dans le même portefeuille ou dans le magasin de certificats par défaut du système.

Client sans portefeuille

Les clients peuvent être configurés sans portefeuille lors de l'utilisation de TLS dans les conditions suivantes : 1) L'authentification TLS unidirectionnelle est configurée lorsque le client ne dispose pas de son propre certificat et 2) Le certificat racine qui a signé le certificat du serveur de base de données est stocké dans le magasin de certificats par défaut du système. Le certificat racine est probablement déjà présent si le certificat du serveur est signé par une autorité de certification commune. S'il s'agit d'un certificat auto-signé, le certificat racine doit être installé dans le magasin de certificats par défaut du système pour éviter l'utilisation d'un portefeuille de client.

Pour plus de détails sur la configuration de TLS entre le client de base de données et le serveur de base de données, notamment les options décrites ci-dessus, voir :

Si vous choisissez d'utiliser des certificats auto-signés et pour d'autres tâches liées au portefeuille, voir :