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 Entra ID Single Sign-On-(SSO-)Zugangsdaten anmelden, um auf die Datenbank zuzugreifen. Dies geschieht mit einem Entra-ID-Zugriffstoken OAuth2, das der Benutzer oder die Anwendung zuerst von Entra-ID anfordert. Dieses OAuth2-Zugriffstoken enthält die Benutzeridentität und die Datenbankzugriffsinformationen und wird dann an die Datenbank gesendet. Weitere Informationen zum Konfigurieren der Multifaktor- und passwortlosen Authentifizierung finden Sie im Microsoft-Artikel Passwordless Authentication options for 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

In den Anweisungen zum Konfigurieren der Entra-ID wird der Begriff "Oracle Database" verwendet, 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 Entra ID Single Sign-On-(SSO-)Zugangsdaten anmelden, um ein Entra ID OAuth2-Zugriffstoken abzurufen, das an die Datenbank gesendet werden soll.

Der Entra-ID-Administrator erstellt und registriert Oracle Autonomous Database mit Entra-ID. Innerhalb der Entra ID wird dies als App-Registrierung bezeichnet, die für die Anwendungsregistrierung steht. Dies sind die digitalen Informationen, die Entra ID über die Software wissen muss, die Entra ID verwendet. Der Entra ID-Administrator erstellt auch Anwendungsrollen (App) für die Datenbankanwendungsregistrierung 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 Schema der Datenbank, einer globalen Rolle oder einem Schema und einer Rolle zugeordnet. Außerdem kann einem Azure-Benutzer ein globales Oracle-Schema 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 aus einer Azure-Anwendungsrolle zugeordnet und nicht von einem Azure-Benutzer zugeordnet werden.

Oracle Autonomous Database-Tools, einschließlich Oracle APEX, Database Actions, Oracle Graph Studio und Oracle Database API for MongoDB, sind nicht mit Entra-ID-Token kompatibel, um eine Verbindung zur Datenbank herzustellen.

Tools und Anwendungen, die aktualisiert werden, um Entra-ID-Token zu unterstützen, können Benutzer direkt mit Entra-ID authentifizieren und das Datenbankzugriffstoken an die Oracle Autonomous Database-Instanz übergeben. Sie können vorhandene Datenbanktools wie SQL*Plus so konfigurieren, dass ein Entra-ID-Token aus einem Dateispeicherort verwendet werden. In diesen Fällen können Entra-ID-Token mit Tools wie Microsoft PowerShell oder Azure-CLI abgerufen und in einem Dateispeicherort abgelegt werden. Die Zugriffstoken für die Entra-ID OAuth2-Datenbank werden 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. Der Geltungsbereich des Tokens wird für die Datenbank festgelegt. Das bedeutet, dass im Token Informationen zur Datenbank vorhanden sind, in der das Token verwendet wird. Die Anwendungsrollen, denen der Entra-ID-Principal in der Entra-ID-Anwendungsregistrierung der Datenbank zugewiesen wurde, werden als Teil des Zugriffstokens aufgenommen. Für den Verzeichnisspeicherort für das Entra-ID-Token sollten nur minimale Berechtigungen festgelegt werden, sodass der Benutzer lediglich 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 der Entra-ID anfordern, indem sie eine Reihe von Methoden verwenden, um ein Azure-Anmeldefenster zu öffnen und ihre Entra-ID-Zugangsdaten einzugeben.

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

  • Azure-Benutzer, der im Entra-ID-Mandanten registriert ist
  • Gastbenutzer: Ist im Entra-ID-Mandanten als Gastbenutzer registriert
  • 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-Authentifizierungsabläufe:

  • 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 eigenständig (nicht als Endbenutzer) eine Verbindung herstellen
  • OBO (On-Behalf-Of): Hierbei fordert eine Anwendung ein Zugriffstoken im Namen eines angemeldeten Benutzers an, um es an die Datenbank zu senden
  • Resource Owner Password Credential (ROPC), das nicht für die Produktion empfohlen wird, aber in Testumgebungen verwendet werden kann, in denen eine Popup-Browser-Benutzerauthentifizierung nur schwer integriert werden kann. ROPC benötigt den Entra-ID-Benutzernamen und die Kennwortzugangsdaten, um Teil des Tokenanforderungsaufrufs zu sein.
Hinweis

Die Integration 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 OAuth 2.0-Standard mit Erweiterungen.

Das Zugriffstoken für die Entra-ID wird benötigt, bevor Sie vom Datenbankclient aus 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 (von Microsoft verfügbare Beispiele) verwenden, um ein Token abzurufen und es in einen Dateispeicherort zu legen, den der Datenbankclient abrufen kann. Anwendungen können mit dem Azure-SDK ein Zugriffstoken abrufen und das Token über die Datenbankclient-API übergeben. Befehlszeilentools wie Microsoft PowerShell oder die Azure-Befehlszeilenschnittstelle können zum Abrufen des Entra-ID-Tokens verwendet werden, wenn die Anwendung das Token nicht direkt abrufen kann.

Das folgende Diagramm ist ein generalisiertes Ablaufdiagramm für den Standard OAuth 2.0 mit dem Token OAuth2. Weitere Informationen zu den einzelnen unterstützten Abläufen finden Sie in der Dokumentation zu Microsoft Entra ID unter Authentifizierungsablaufunterstützung in MSAL.

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

Der Autorisierungscodefluss ist ein OAuth2-Standard und wird im Detail als Teil der Standards beschrieben. Es gibt zwei Schritte im Ablauf. Im ersten Schritt wird der Benutzer authentifiziert und der Autorisierungscode abgerufen. Im zweiten Schritt wird der Autorisierungscode zum Abrufen des Datenbankzugriffstokens verwendet.

  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 Entra-ID, um ihn gegen das Token OAuth2 auszutauschen.
  5. Der Datenbankclient sendet das Zugriffstoken OAuth2 an die Oracle-Datenbank. Das Token enthält die Datenbankanwendungsrollen, denen der Benutzer in der Entra-ID-App-Registrierung für die Datenbank zugewiesen wurde.
  6. Die Oracle Database-Instanz verwendet den öffentlichen Schlüssel für die Entra-ID, um zu prüfen, ob das Zugriffstoken von der Entra-ID erstellt wurde.

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

Zuordnung von Azure-Benutzern zu einem Oracle Database-Schema und -Rollen

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

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

Um einen Entra-ID-Benutzer exklusiv einem Datenbankschema zuzuordnen, muss der Datenbankadministrator ein Datenbankschema für den Lebenszyklus des Benutzers erstellen und verwalten (zusammenschließen, verschieben, verlassen). Der Datenbankadministrator muss das Schema erstellen, wenn der Benutzer der Organisation beitritt. Der Datenbankadministrator muss auch 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. Durch die Verwendung der Datenbankanwendungsrollen kann der Entra-ID-Administrator den Zugriff und die Rollen kontrollieren, indem Benutzer Anwendungsrollen zugewiesen werden, 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.

  • Eine 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 auch die erteilten Berechtigungen und Rollen 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-Anwendungsrolle und einem Oracle Database-Schema erstellen. Dieser Zuordnungstyp, der häufiger als exklusive Zuordnungen verwenden wird, ist für Azure-Benutzer gedacht, die der App-Rolle direkt zugewiesen wurden oder Mitglied einer Entra-ID-Gruppe sind, die der App-Rolle zugewiesen ist. Die Anwendungsrolle ist einem Oracle Database-Schema (gemeinsame Schemazuordnung) zugeordnet. Durch die gemeinsame Schemazuordnung können mehrere Azure-Benutzer dasselbe Oracle Database-Schema gemeinsam verwenden, sodass 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 wurden, können zusätzliche Rollen und Berechtigungen über zugeordnete globale Rollen erteilt wird. Verschiedene Azure-Benutzer, die demselben gemeinsamen globalen Schema zugeordnet sind, benötigen möglicherweise unterschiedliche Berechtigungen und Rollen. Azure-Anwendungsrollen können globalen Oracle Database-Rollen zugeordnet werden. Azure-Benutzer, die der App-Rolle zugewiesen sind oder Mitglied einer Entra-ID-Gruppe sind und der App-Rolle zugewiesen sind, 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.
  • einem Azure-Benutzer, einer Entra-ID-Gruppe oder einer Anwendung eine Anwendungsrolle zugewiesen wird, die dann einem globalen Oracle Database-Schema (Benutzer) oder einer globalen Rolle zugeordnet wird.

Anwendungsfälle für Verbindungen zu Oracle Database mit Entra ID

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

  • OAuth2-Autorisierungscodefluss: Dies ist der häufigste Ablauf für Benutzer. Der Client weist den Azure-Benutzer zur Entra-ID an, um den Autorisierungscode abzurufen. Dieser Code wird zum Abrufen des Datenbankzugriffstokens verwendet. Weitere Informationen finden Sie im Microsoft Azure-Artikel Microsoft identity platform and OAuth 2.0 authorization code flow.
  • Resource Owner Password Credentials (ROPC): Dieser Datenfluss wird für Produktionsserver nicht empfohlen. Es ist nützlich für Testsoftware, die nicht mit einem Popup-Authentifizierungsfenster arbeiten kann. Wird in nicht grafische Benutzeroberflächenumgebungen verwendet, wenn ein Popup-Fenster zur Authentifizierung eines Benutzers nicht verwendet werden kann.
  • Clientzugangsdaten: Dieser Ablauf wird für Anwendungen verwendet, um eine Verbindung zur Datenbank herzustellen. Die Anwendung muss sich bei der Entra ID-App-Registrierung registrieren und benötigt eine Client-ID und ein Clientkennwort. 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 über 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 der zugewiesenen Anwendungsrollen für die Datenbank. Dadurch kann sich der Azure-Benutzer bei der Datenbank als Benutzer und nicht bei der Anwendung anmelden. Nur eine Anwendung kann ein OBO-Token für die zugehörigen Azure-Benutzer anfordern und über die API an den Datenbankclient übergeben.