Documentazione dell'infrastruttura Oracle Cloud

Informazioni sull'integrazione di Oracle Autonomous Database con Microsoft Entra ID

È possibile configurare Oracle Autonomous Database e Microsoft Entra ID per consentire agli utenti e alle applicazioni di connettersi al database utilizzando le credenziali Entra ID.

Gli utenti e le applicazioni di Azure possono eseguire il login con le credenziali Entra ID Single Sign On (SSO) per accedere al database. Questa operazione viene eseguita con un token di accesso Entra ID OAuth2 che l'utente o l'applicazione richiede in primo luogo da Entra ID. Questo token di accesso OAuth2 contiene le informazioni sull'identità utente e sull'accesso al database e viene quindi inviato al database. Fare riferimento all'articolo di Microsoft Opzioni di autenticazione senza password per Azure Active Directory per informazioni sulla configurazione dell'autenticazione con più fattori e senza password.

È possibile eseguire questa integrazione nei seguenti ambienti Oracle Database:

  • Oracle Database on-premise release 19.18 e successive, escluso 21c
  • Tutte le piattaforme server di Oracle Database: Linux, Windows, AIX, Solaris e HPUX
  • Oracle Autonomous Database Serverless
  • Oracle Autonomous Database on Dedicated Exadata Infrastructure
  • 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

Le istruzioni per la configurazione di Entra ID utilizzano il termine "Oracle Database" per comprendere questi ambienti.

Questo tipo di integrazione consente all'utente di Azure di accedere a un'istanza di Oracle Autonomous Database. Gli utenti e le applicazioni di Azure possono eseguire il login con le credenziali Entra ID Single Sign On (SSO) per ottenere un token di accesso Entra ID OAuth2 da inviare al database.

L'amministratore Entra ID crea e registra Oracle Autonomous Database con Entra ID. All'interno di Entra ID, questo è chiamato una registrazione di app, che è l'abbreviazione di registrazione della domanda. Queste sono le informazioni digitali che Entra ID deve conoscere sul software che utilizza Entra ID. L'amministratore Entra ID crea anche ruoli applicazione (app) per la registrazione dell'applicazione di database in Entra ID. I ruoli applicazione connettono utenti, gruppi e applicazioni di Azure a schemi e ruoli di database. L'amministratore Entra ID assegna utenti, gruppi o applicazioni di Azure ai ruoli applicazione. Questi ruoli applicazione sono mappati a uno schema globale di database o a un ruolo globale oppure a uno schema e a un ruolo. Un utente, un gruppo o un'applicazione di Azure assegnati a un ruolo applicazione verrà mappato a uno schema globale di database, a un ruolo globale o a uno schema e a un ruolo. Anche uno schema globale Oracle può essere mappato esclusivamente a un utente di Azure. Un utente guest di Azure (utente non organizzazione) o un principal (applicazione) del servizio Entra ID può essere mappato a uno schema globale del database solo tramite un ruolo applicazione Entra ID. Un ruolo globale Oracle può essere mappato solo da un ruolo applicazione Azure e non può essere mappato da un utente Azure.

Gli strumenti di Oracle Autonomous Database, tra cui Oracle APEX, Database Actions, Oracle Graph Studio e Oracle Database API for MongoDB, non sono compatibili con l'uso di token Entra ID per connettersi al database.

Gli strumenti e le applicazioni aggiornati per supportare i token Entra ID possono autenticare gli utenti direttamente con Entra ID e passare il token di accesso al database all'istanza di Oracle Autonomous Database. È possibile configurare strumenti di database esistenti, ad esempio SQL*Plus, in modo che utilizzino un token Entra ID da una posizione file. In questi casi, i token Entra ID possono essere recuperati utilizzando strumenti come l'interfaccia CLI di Microsoft PowerShell o Azure e inseriti in una posizione file. I token di accesso al database Entra ID OAuth2 vengono emessi con un'ora di scadenza. Il driver del client Oracle Database garantirà che il token sia in un formato valido e che non sia scaduto prima di passarlo al database. Il token è definito per il database, il che significa che nel token sono presenti informazioni sul database in cui verrà utilizzato il token. I ruoli applicazione a cui è stato assegnato il principal Entra ID nel database di registrazione dell'applicazione Entra ID sono inclusi come parte del token di accesso. La posizione della directory per il token Entra ID deve disporre solo di autorizzazioni sufficienti per consentire all'utente di scrivere il file token nella posizione e il client del database per recuperare questi file (ad esempio, è sufficiente leggere e scrivere da parte dell'utente). Poiché il token consente l'accesso al database, è necessario proteggerlo all'interno del file system.

Gli utenti di Azure possono richiedere un token da Entra ID utilizzando una serie di metodi per aprire una finestra di login di Azure per immettere le proprie credenziali Entra ID.

Oracle Autonomous Database accetta token che rappresentano i seguenti principal Entra ID:

  • Utente Azure, utente registrato nella tenancy Entra ID
  • Utente guest, registrato come utente guest nella tenancy Entra ID
  • Servizio, ovvero l'applicazione registrata che si connette al database come se fosse con il flusso di credenziali client (caso d'uso del connection pool)

Oracle Autonomous Database supporta i flussi di autenticazione Entra ID riportati di seguito.

  • Flusso interattivo (chiamato anche flusso di codice di autorizzazione) che utilizza la chiave di prova per lo scambio di codice (PKCE), più comunemente utilizzata per gli utenti umani (non le applicazioni) per l'autenticazione a Entra ID in un ambiente client con un browser
  • Credenziali client, che sono per le applicazioni di database che si connettono come se stessi (e non l'utente finale)
  • On-Behalf-Of (OBO), in cui un'applicazione richiede un token di accesso per conto di un utente che ha eseguito il login per l'invio al database
  • La credenziale ROPC (Resource Owner Password Credential), che non è consigliata per l'uso in produzione, ma può essere utilizzata in ambienti di test in cui sarebbe difficile incorporare un'autenticazione utente del browser popup. ROPC richiede che il nome utente e la credenziale password Entra ID facciano parte della chiamata di richiesta del token.
Nota

L'integrazione DBaaS con Microsoft Entra ID non supporta gli utenti con privilegi amministrativi (SYSDBA, SYSOPER, SYSBACKUP, SYSDG, SYSKM e SYSRAC).

Argomenti

Argomento padre: Utilizzare Microsoft Entra ID con Autonomous Database

Architettura dell'integrazione di Oracle Database con Microsoft Entra ID

I token di accesso a Microsoft Azure Active Directory seguono lo standard OAuth 2.0 con le estensioni.

Il token di accesso Entra ID sarà necessario prima di accedere al database dal client del database (ad esempio, con SQLPlus o SQLcl). I client Oracle (ad esempio, OCI, JDBC e ODP) possono essere configurati per prelevare un token Entra ID da una posizione file oppure il token può essere passato al client tramite l'API del client di database. Un utente di Azure può utilizzare uno script (esempi disponibili da Microsoft) per recuperare un token e inserirlo in una posizione file che il client del database può recuperare. Le applicazioni possono utilizzare l'SDK di Azure per ottenere un token di accesso e passare il token tramite l'API del client di database. Gli strumenti della riga di comando come Microsoft PowerShell o l'interfaccia della riga di comando di Azure possono essere utilizzati per recuperare il token Entra ID se l'applicazione non è in grado di ottenere direttamente il token.

Il seguente diagramma è un diagramma di flusso generalizzato per lo standard OAuth 2.0, utilizzando il token OAuth2. Per ulteriori dettagli su ciascun flusso supportato, vedere Supporto del flusso di autenticazione in MSAL nella documentazione di Microsoft Entra ID.

Segue la descrizione dell'immagine azure-authentication.eps
Descrizione dell'immagine azure-authentication.eps

Il flusso del codice di autorizzazione è uno standard OAuth2 ed è descritto in dettaglio come parte degli standard. Ci sono due passaggi nel flusso. Il primo passo esegue l'autenticazione dell'utente e recupera il codice di autorizzazione. Il secondo passo utilizza il codice di autorizzazione per ottenere il token di accesso al database.

  1. L'utente di Azure richiede l'accesso alla risorsa, l'istanza di Oracle Database.
  2. Il client o l'applicazione di database richiede un codice di autorizzazione da Entra ID.
  3. Entra ID autentica l'utente di Azure e restituisce il codice di autorizzazione.
  4. Lo strumento o l'applicazione helper utilizza il codice di autorizzazione con Entra ID per scambiarlo con il token OAuth2.
  5. Il client di database invia il token di accesso OAuth2 al database Oracle. Il token include i ruoli applicazione del database a cui è stato assegnato l'utente nella registrazione dell'applicazione Entra ID per il database.
  6. L'istanza di Oracle Database utilizza la chiave pubblica Entra ID per verificare che il token di accesso sia stato creato da Entra ID.

Sia il client di database che il database server devono essere registrati con la funzione Registrazioni applicazioni nella sezione Azure Active Directory del portale di Azure. Il client di database deve essere registrato con la registrazione dell'applicazione Entra ID. È inoltre necessario concedere l'autorizzazione per consentire al client di database di ottenere un token di accesso per il database.

Mapping degli utenti di Azure a uno schema e ruoli di Oracle Database

Gli utenti Microsoft Azure devono essere mappati a uno schema Oracle Database e disporre dei privilegi necessari (tramite i ruoli) prima di poter eseguire l'autenticazione nell'istanza di Oracle Database.

In Microsoft Azure, un amministratore Entra ID può assegnare utenti, gruppi e applicazioni ai ruoli applicazione del database.

Il mapping esclusivo di un utente Entra ID a uno schema di database richiede all'amministratore di database di creare e gestire uno schema di database per il ciclo di vita dell'utente (unione, spostamento, uscita). L'amministratore del database deve creare lo schema quando l'utente entra nell'organizzazione. L'amministratore del database deve inoltre modificare i privilegi e i ruoli concessi allo schema di database per allinearli ai task a cui è assegnato l'utente di Azure. Quando l'utente di Azure lascia l'organizzazione, l'amministratore del database deve eliminare lo schema del database in modo che non venga lasciato un account inutilizzato nel database. L'uso dei ruoli applicazione del database consente all'amministratore Entra ID di controllare l'accesso e i ruoli assegnando gli utenti ai ruoli applicazione mappati agli schemi globali e ai ruoli globali. In questo modo, l'accesso degli utenti al database viene gestito dagli amministratori di Entra ID e gli amministratori di database non devono creare, gestire ed eliminare gli schemi per ogni utente.

Un utente di Azure può essere mappato a uno schema di database (utente) in modo esclusivo o tramite un ruolo applicazione.

  • Creazione di un mapping esclusivo tra un utente Azure e uno schema Oracle Database. In questo tipo di mapping, è necessario creare lo schema di database per l'utente di Azure. I privilegi e i ruoli di database necessari per l'utente di Azure devono essere concessi allo schema di database. Lo schema di database non deve essere creato solo quando l'utente di Azure è autorizzato al database, ma i privilegi e i ruoli concessi devono essere modificati man mano che i ruoli e i task Entra ID cambiano. Infine, lo schema di database deve essere eliminato quando l'utente di Azure lascia l'organizzazione.
  • Creazione di un mapping condiviso tra un ruolo applicazione Entra ID e uno schema Oracle Database. Questo tipo di mapping, che è più comune dei mapping esclusivi, è destinato agli utenti di Azure che sono stati assegnati direttamente al ruolo applicazione oppure è membro di un gruppo Entra ID assegnato al ruolo applicazione. Il ruolo applicazione è mappato a uno schema di Oracle Database (mapping dello schema condiviso). Il mapping dello schema condiviso consente a più utenti di Azure di condividere lo stesso schema di Oracle Database in modo che non sia necessario creare un nuovo schema di database ogni volta che un nuovo utente entra nell'organizzazione. Questa efficienza operativa consente agli amministratori di database di concentrarsi sui task di manutenzione, prestazioni e tuning delle applicazioni di database invece di configurare nuovi utenti, aggiornare privilegi e ruoli e rimuovere gli account.

Oltre ai ruoli e ai privilegi di database concessi direttamente allo schema globale mappato, è possibile concedere ruoli e privilegi aggiuntivi tramite ruoli globali mappati. Gli utenti di Azure diversi mappati allo stesso schema globale condiviso possono richiedere privilegi e ruoli diversi. I ruoli applicazione di Azure possono essere mappati ai ruoli globali di Oracle Database. Agli utenti di Azure assegnati al ruolo applicazione o membri di un gruppo Entra ID assegnato al ruolo applicazione verrà concesso il ruolo globale di Oracle Database quando accedono al database.

Il diagramma seguente illustra i diversi tipi di assegnazioni e mapping disponibili.

Segue la descrizione di azure_mappings.eps
Descrizione dell'immagine azure_mappings.eps

Di seguito sono riportati i mapping.

  • Un utente di Azure può essere mappato direttamente a uno schema globale (utente) di Oracle Database.
  • Un utente di Azure, un gruppo Entra ID o un'applicazione viene assegnato a un ruolo applicazione, che viene quindi mappato a uno schema globale (utente) di Oracle Database o a un ruolo globale.

Casi d'uso per la connessione a un'istanza di Oracle Database mediante Entra ID

Oracle Database supporta diversi casi d'uso per la connessione al database.

  • OAuth2 Flusso di codici di autorizzazione: questo è il flusso più comune per gli utenti umani. Il client indirizza l'utente di Azure a Entra ID per ottenere il codice di autorizzazione. Questo codice viene utilizzato per ottenere il token di accesso al database. Consulta l'articolo di Microsoft Azure sulla piattaforma di identità Microsoft e il flusso di codici di autorizzazione OAuth 2.0.
  • Credenziali di password del proprietario della risorsa (ROPC): questo flusso non è consigliato per i server di produzione. È utile per il software di test che non può funzionare con una finestra di autenticazione popup. Viene utilizzato in ambienti di interfaccia utente non di tipo grafico quando non è possibile utilizzare una finestra popup per autenticare un utente.
  • Credenziali client: questo flusso viene utilizzato per consentire alle applicazioni di connettersi al database. L'applicazione deve registrarsi con la registrazione dell'applicazione Entra ID e richiede un ID client e una password client. Queste credenziali client devono essere utilizzate per ottenere il token di accesso al database da Entra ID quando l'applicazione si connette al database. L'applicazione può passare il token tramite il file system o l'API del client di database.
  • Token OBO (On-behalf-of): un'applicazione Azure richiede un token OBO per un utente connesso. Il token OBO sarà anche un token di accesso per il database con l'identità utente di Azure e i ruoli applicazione assegnati per il database. Ciò consente all'utente di Azure di eseguire il login al database come utente e non come applicazione. Solo un'applicazione può richiedere un token OBO per il proprio utente di Azure e passarlo al client di database tramite l'API.