Oracle Cloud Infrastructure-Dokumentation

Oracle Autonomous Database mit Microsoft Entra ID integrieren

Oracle Autonomous Database und Microsoft Entra ID können so konfiguriert werden, dass Benutzer und Anwendungen mit ihren Entra-ID-Zugangsdaten eine Verbindung zur Datenbank herstellen können.

Azure-Benutzer und -Anwendungen können sich mit SSO-Zugangsdaten (Entra ID Single Sign-On) anmelden, um auf die Datenbank zuzugreifen. Dies erfolgt mit einem Entra-ID-Zugriffstoken OAuth2, das der Benutzer oder die Anwendung zuerst von der Entra-ID anfordert. Dieses OAuth2-Zugriffstoken enthält die Benutzeridentitäts- und Datenbankzugriffsinformationen und wird dann an die Datenbank gesendet. Informationen zum Konfigurieren der Multifaktor- und kennwortlosen Authentifizierung finden Sie im Microsoft-Artikel Passwortlose Authentifizierungsoptionen für Azure Active Directory.

Sie können diese Integration in den folgenden Oracle Database-Umgebungen ausführen:

  • On-Premises-Oracle Database-Version 19.18 und höher, ausgenommen 21c
  • Alle Oracle Database-Serverplattformen: Linux, Windows, AIX, Solaris und HPUX
  • Oracle Autonomous Database Serverless
  • Oracle Autonomous Database auf dedizierter Exadata-Infrastruktur
  • 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

Die Anweisungen zum Konfigurieren der Entra-ID verwenden den Begriff "Oracle Database", um diese Umgebungen zu umfassen.

Mit diesem Integrationstyp kann der Azure-Benutzer auf eine Oracle Autonomous Database-Instanz zugreifen. Azure-Benutzer und -Anwendungen können sich mit SSO-(Entra ID Single Sign-On-)Zugangsdaten anmelden, um ein Entra-ID-Zugriffstoken OAuth2 zum Senden an die Datenbank zu erhalten.

Der Entra-ID-Administrator erstellt und registriert Oracle Autonomous Database mit Entra-ID. Innerhalb der Entra-ID wird dies als App-Registrierung bezeichnet, was für die Anwendungsregistrierung kurz ist. Dies sind die digitalen Informationen, die Entra ID über die Software wissen muss, die Entra ID verwendet. Der Entra ID-Administrator erstellt auch Anwendungs-(App-)Rollen für die Datenbank-App-Registrierung in Entra ID. Anwendungsrollen verbinden Azure-Benutzer, -Gruppen und -Anwendungen mit Datenbankschemas und -rollen. Der Entra-ID-Administrator weist den Anwendungsrollen Azure-Benutzer, -Gruppen oder -Anwendungen zu. Diese Anwendungsrollen werden einem globalen Datenbankschema oder einer globalen Rolle oder einem Schema und einer Rolle zugeordnet. Ein Azure-Benutzer, eine Gruppe oder eine Anwendung, die einer Anwendungsrolle zugewiesen ist, wird einem globalen Datenbankschema, einer globalen Rolle oder sowohl einem Schema als auch einer Rolle zugeordnet. Außerdem kann ein globales Oracle-Schema einem Azure-Benutzer exklusiv zugeordnet werden. Ein Azure-Gastbenutzer (Nicht-Organisationsbenutzer) oder ein Entra-ID-Service-Principal (Anwendung) kann nur über eine Entra-ID-Anwendungsrolle einem globalen Datenbankschema zugeordnet werden. Eine globale Oracle-Rolle kann nur von einer Azure-Anwendungsrolle aus zugeordnet werden und kann nicht von einem Azure-Benutzer zugeordnet werden.

Oracle Autonomous Database-Tools wie Oracle APEX, Database Actions, Oracle Graph Studio und die Oracle Database-API für MongoDB sind nicht mit der Verwendung von Entra-ID-Token für die Verbindung mit der Datenbank kompatibel.

Tools und Anwendungen, die zur Unterstützung von Entra-ID-Token aktualisiert werden, können Benutzer direkt mit Entra-ID authentifizieren und das Datenbankzugriffstoken an die Oracle Autonomous Database-Instanz übergeben. Sie können vorhandene Datenbank-Tools wie SQL*Plus so konfigurieren, dass ein Entra-ID-Token aus einem Dateispeicherort verwendet wird. In diesen Fällen können Entra-ID-Token mit Tools wie Microsoft PowerShell oder der Azure-CLI abgerufen und in einem Dateispeicherort abgelegt werden. Ein Entra-ID-OAuth2-Datenbankzugriffstoken wird mit einer Ablaufzeit ausgegeben. Der Oracle Database-Clienttreiber stellt sicher, dass das Token ein gültiges Format aufweist und nicht abgelaufen ist, bevor es an die Datenbank übergeben wird. Das Token hat einen Geltungsbereich für die Datenbank, d.h. das Token enthält Informationen über die Datenbank, in der das Token verwendet wird. Die App-Rollen, denen der Entra-ID-Principal in der Entra-ID-App-Registrierung der Datenbank zugewiesen wurde, sind als Teil des Zugriffstokens enthalten. Das Verzeichnis für das Entra-ID-Token darf nur über ausreichende Berechtigungen verfügen, damit der Benutzer die Tokendatei in den Speicherort schreiben und der Datenbankclient diese Dateien abrufen kann (z.B. nur Lese- und Schreibberechtigung für den Benutzer). Da das Token Zugriff auf die Datenbank gewährt, muss es im Dateisystem geschützt werden.

Azure-Benutzer können ein Token von Entra ID mit einer Reihe von Methoden anfordern, um ein Azure-Anmeldefenster zu öffnen und ihre Entra-ID-Zugangsdaten einzugeben.

Oracle Autonomous Database akzeptiert Token, die folgende Entra-ID-Prinzipale darstellen:

  • Azure-Benutzer, der im Entra-ID-Mandanten registrierter Benutzer ist
  • Benutzer, der im Mandanten der Entra-ID als Gastbenutzer registriert ist
  • Service: Hierbei handelt es sich um die registrierte Anwendung, die eigenständig mit dem Clientzugangsdatenfluss eine Verbindung zur Datenbank herstellt (Anwendungsfall für Verbindungspool)

Oracle Autonomous Database unterstützt die folgenden Entra-ID-Authentifizierungsflüsse:

  • Interaktiver Ablauf (auch Autorisierungscodefluss genannt) mit Proof Key for Code Exchange (PKCE), der am häufigsten für menschliche Benutzer (nicht Anwendungen) zur Authentifizierung bei Entra ID in einer Clientumgebung mit einem Browser verwendet wird
  • Clientzugangsdaten: Werden für Datenbankanwendungen verwendet, die sich selbst (nicht als Endbenutzer) anmelden
  • OBO (On-Behalf-Of): Hierbei fordert eine Anwendung ein Zugriffstoken im Namen eines angemeldeten Benutzers an, um es an die Datenbank zu senden
  • Kennwortzugangsdaten des Ressourceneigentümers (ROPC), die nicht für die Verwendung in der Produktion empfohlen werden, aber in Testumgebungen verwendet werden können, in denen eine Popup-Browserbenutzerauthentifizierung schwierig zu integrieren wäre. ROPC benötigt den Entra-ID-Benutzernamen und die Kennwortzugangsdaten, um Teil des Tokenanforderungsaufrufs zu sein.
Hinweis

Die Integration von DBaaS mit der Microsoft Entra-ID unterstützt keine Benutzer mit Administratorberechtigungen (SYSDBA, SYSOPER, SYSBACKUP, SYSDG, SYSKM und SYSRAC).

Themen

Übergeordnetes Thema: Microsoft Entra-ID mit Autonomous Database verwenden

Architektur der Oracle Database-Integration mit Microsoft Entra ID

Microsoft Azure Active Directory-Zugriffstoken folgen dem Standard OAuth 2.0 mit Erweiterungen.

Das Zugriffstoken der Entra-ID wird benötigt, bevor Sie über den Datenbankclient auf die Datenbank zugreifen (z.B. mit SQLPlus oder SQLcl). Die Oracle-Clients (z.B. OCI, JDBC und ODP) können so konfiguriert werden, dass ein Entra-ID-Token aus einem Dateispeicherort abgerufen wird, oder das Token kann über die Datenbankclient-API an den Client übergeben werden. Ein Azure-Benutzer kann ein Skript (in Microsoft verfügbare Beispiele) verwenden, um ein Token abzurufen und es in einem Dateispeicherort für den abzurufenden Datenbankclient abzulegen. Anwendungen können mit dem Azure-SDK ein Zugriffstoken abrufen und das Token über die Datenbankclient-API übergeben. Mit Befehlszeilen-Tools wie Microsoft PowerShell oder der Azure-Befehlszeilenschnittstelle kann das Entra-ID-Token abgerufen werden, wenn die Anwendung das Token nicht direkt abrufen kann.

Das folgende Diagramm zeigt ein allgemeines Flussdiagramm für den Standard OAuth 2.0, der das Token OAuth2 verwendet. Weitere Informationen zu den einzelnen unterstützten Flüssen finden Sie in der Microsoft Entra ID-Dokumentation unter Authentifizierungsflussunterstützung in MSAL.

Beschreibung von azure-authentication.eps folgt
Beschreibung der Abbildung azure-authentication.eps

Der Autorisierungscodeablauf ist ein OAuth2-Standard und wird im Detail als Teil der Standards beschrieben. Der Ablauf umfasst zwei Schritte. Im ersten Schritt wird der Benutzer authentifiziert und der Autorisierungscode abgerufen. Im zweiten Schritt wird der Autorisierungscode verwendet, um das Datenbankzugriffstoken abzurufen.

  1. Der Azure-Benutzer fordert Zugriff auf die Ressource, die Oracle Database-Instanz, an.
  2. Der Datenbankclient oder die Anwendung fordert einen Autorisierungscode von der Entra-ID an.
  3. Entra ID authentifiziert den Azure-Benutzer und gibt den Autorisierungscode zurück.
  4. Das Helper-Tool oder die Anwendung verwendet den Autorisierungscode mit der Entra-ID, um ihn gegen das OAuth2-Token einzutauschen.
  5. Der Datenbankclient sendet das OAuth2-Zugriffstoken an die Oracle-Datenbank. Das Token enthält die Datenbankanwendungsrollen, denen der Benutzer bei der Registrierung der Entra-ID-App für die Datenbank zugewiesen wurde.
  6. Die Oracle Database-Instanz verwendet den öffentlichen Schlüssel der Entra-ID, um zu prüfen, ob das Zugriffstoken von der Entra-ID erstellt wurde.

Der Datenbankclient und der Datenbankserver müssen mit dem Feature App-Registrierungen im Abschnitt "Azure Active Directory" des Azure-Portals registriert sein. Der Datenbankclient muss bei der Registrierung der Entra-ID-App registriert sein. Außerdem muss die Berechtigung erteilt werden, damit der Datenbankclient ein Zugriffstoken für die Datenbank abrufen kann.

Azure-Benutzer einem Oracle Database-Schema und Rollen zuordnen

Microsoft Azure-Benutzer müssen einem Oracle Database-Schema zugeordnet sein und (mithilfe von Rollen) über die erforderlichen Berechtigungen verfügen, bevor sie sich bei der Oracle Database-Instanz authentifizieren können.

In Microsoft Azure kann ein Entra-ID-Administrator den Datenbank-Anwendungsrollen Benutzer, Gruppen und Anwendungen zuweisen.

Wenn Sie einen Entra-ID-Benutzer ausschließlich einem Datenbankschema zuordnen, muss der Datenbankadministrator ein Datenbankschema für den Lebenszyklus des Benutzers erstellen und verwalten (anschließen, verschieben, verlassen). Der Datenbankadministrator muss das Schema erstellen, wenn der Benutzer der Organisation beitritt. Der Datenbankadministrator muss außerdem die Berechtigungen und Rollen ändern, die dem Datenbankschema erteilt werden, um sie an den Aufgaben auszurichten, denen der Azure-Benutzer zugewiesen ist. Wenn der Azure-Benutzer die Organisation verlässt, muss der Datenbankadministrator das Datenbankschema löschen, damit kein nicht verwendeter Account in der Datenbank verbleibt. Mit den Datenbankanwendungsrollen kann der Entra-ID-Administrator den Zugriff und die Rollen kontrollieren, indem er Benutzern Anwendungsrollen zuweist, die globalen Schemas und globalen Rollen zugeordnet sind. Auf diese Weise wird der Benutzerzugriff auf die Datenbank von Entra ID-Administratoren verwaltet, und Datenbankadministratoren müssen keine Schemas für jeden Benutzer erstellen, verwalten und löschen.

Ein Azure-Benutzer kann einem Datenbankschema (Benutzer) exklusiv oder über eine Anwendungsrolle zugeordnet werden.

  • Exklusive Zuordnung zwischen einem Azure-Benutzer und einem Oracle Database-Schema erstellen. Bei diesem Zuordnungstyp muss das Datenbankschema für den Azure-Benutzer erstellt werden. Datenbankberechtigungen und -rollen, die vom Azure-Benutzer benötigt werden, müssen dem Datenbankschema erteilt werden. Das Datenbankschema muss nicht nur erstellt werden, wenn der Azure-Benutzer für die Datenbank autorisiert ist, sondern die erteilten Berechtigungen und Rollen müssen geändert werden, wenn sich die Entra-ID-Rollen und -Aufgaben ändern. Schließlich muss das Datenbankschema gelöscht werden, wenn der Azure-Benutzer die Organisation verlässt.
  • Gemeinsame Zuordnung zwischen einer Entra-ID-App-Rolle und einem Oracle Database-Schema erstellen. Dieser Zuordnungstyp, der häufiger als exklusive Zuordnungen verwendet wird, ist für Azure-Benutzer bestimmt, die der Anwendungsrolle direkt zugewiesen wurden oder Mitglied einer Entra-ID-Gruppe sind, die der Anwendungsrolle zugewiesen ist. Die Anwendungsrolle ist einem Oracle Database-Schema (gemeinsame Schemazuordnung) zugeordnet. Die gemeinsame Schemazuordnung ermöglicht es mehreren Azure-Benutzern, dasselbe Oracle Database-Schema gemeinsam zu verwenden, damit nicht jedes Mal ein neues Datenbankschema erstellt werden muss, wenn ein neuer Benutzer der Organisation beitritt. Dank dieser betrieblichen Effizienz können Datenbankadministratoren sich auf Wartungs-, Performance- und Optimierungsaufgaben für Datenbankanwendungen konzentrieren, anstatt ständig neue Benutzer zu konfigurieren, Berechtigungen und Rollen zu aktualisieren und Accounts zu entfernen.

Zusätzlich zu Datenbankrollen und Berechtigungen, die direkt dem zugeordneten globalen Schema erteilt werden, können zusätzliche Rollen und Berechtigungen über zugeordnete globale Rollen erteilt werden. Verschiedene Azure-Benutzer, die demselben gemeinsamen globalen Schema zugeordnet sind, benötigen möglicherweise verschiedene Berechtigungen und Rollen. Azure-Anwendungsrollen können globalen Oracle Database-Rollen zugeordnet werden. Azure-Benutzer, die der Anwendungsrolle zugewiesen sind oder Mitglied einer Entra-ID-Gruppe sind, die der Anwendungsrolle zugewiesen ist, erhalten beim Zugriff auf die Datenbank die globale Oracle Database-Rolle.

Das folgende Diagramm veranschaulicht die verschiedenen verfügbaren Zuweisungs- und Zuordnungstypen.

Beschreibung von azure_mappings.eps folgt
Beschreibung der Abbildung azure_mappings.eps

Folgende Zuordnungen stehen zur Verfügung:

  • Ein Azure-Benutzer kann direkt einem globalen Oracle Database-Schema (Benutzer) zugeordnet werden.
  • Ein Azure-Benutzer, eine Entra-ID-Gruppe oder eine Anwendung wird einer Anwendungsrolle zugewiesen, die dann einem globalen Oracle Database-Schema (Benutzer) oder einer globalen Rolle zugeordnet wird.

Anwendungsfälle für die Verbindung zu Oracle Database mit Entra-ID

Oracle Database unterstützt mehrere Anwendungsfälle für die Anmeldung bei der Datenbank.

  • OAuth2-Autorisierungscodefluss: Dies ist der häufigste Ablauf für menschliche Benutzer. Der Client weist den Azure-Benutzer an Entra ID, um den Autorisierungscode abzurufen. Mit diesem Code wird das Datenbankzugriffstoken abgerufen. Weitere Informationen finden Sie im Microsoft Azure-Artikel Microsoft identity platform and OAuth 2.0 authorization code flow.
  • Kennwortzugangsdaten des Ressourceneigentümers (ROPC): Dieser Ablauf wird für Produktionsserver nicht empfohlen. Es ist nützlich für Testsoftware, die nicht mit einem Popup-Authentifizierungsfenster arbeiten kann. Er wird in nicht grafischen Benutzeroberflächenumgebungen verwendet, wenn kein Popup-Fenster zur Authentifizierung eines Benutzers verwendet werden kann.
  • Clientzugangsdaten: Mit diesem Ablauf können sich Anwendungen bei der Datenbank anmelden. Die Anwendung muss sich bei der Registrierung der Entra ID-App registrieren und benötigt eine Client-ID und ein Clientpasswort. Diese Clientzugangsdaten müssen verwendet werden, um das Datenbankzugriffstoken aus der Entra-ID abzurufen, wenn sich die Anwendung bei der Datenbank anmeldet. Die Anwendung kann das Token über das Dateisystem oder die Datenbankclient-API übergeben.
  • On-behalf-of-(OBO-)Token: Eine Azure-Anwendung fordert ein OBO-Token für einen angemeldeten Benutzer an. Das OBO-Token dient auch als Zugriffstoken für die Datenbank mit der Azure-Benutzeridentität und den zugewiesenen Anwendungsrollen für die Datenbank. Dadurch kann sich der Azure-Benutzer bei der Datenbank als Benutzer und nicht als Anwendung anmelden. Nur eine Anwendung kann ein OBO-Token für den zugehörigen Azure-Benutzer anfordern und über die API an den Datenbankclient übergeben.