Documentazione di Oracle Cloud Infrastructure

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

Oracle Autonomous Database e l'ID Entra Microsoft possono essere configurati per consentire a utenti e applicazioni di connettersi al database utilizzando le proprie credenziali di Entra ID.

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

È possibile eseguire questa integrazione nei seguenti ambienti Oracle Database:

  • Oracle Database on-premise release 19.18 e successive, escluso 21c
  • Tutte le piattaforme server 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 di Entra ID crea e registra Oracle Autonomous Database con l'ID Entra. All'interno di Entra ID, questa è chiamata registrazione dell'app, che è breve per la registrazione dell'applicazione. Queste sono le informazioni digitali che Entra ID deve conoscere sul software che utilizza Entra ID. L'amministratore di Entra ID crea inoltre ruoli applicazione (app) per la registrazione dell'applicazione di database nell'ID Entra. I ruoli applicazione connettono utenti, gruppi e applicazioni di Azure agli schemi e ai ruoli del database. L'amministratore di Entra ID assegna utenti, gruppi o applicazioni di Azure ai ruoli applicazione. Questi ruoli applicazione vengono mappati a uno schema globale del database o a un ruolo globale oppure a uno schema e a un ruolo. Un utente, un gruppo o un'applicazione Azure assegnato a un ruolo applicazione verrà mappato a uno schema globale del database, a un ruolo globale o a uno schema e a un ruolo. Uno schema globale Oracle può anche essere mappato esclusivamente a un utente di Azure. Un utente guest di Azure (utente non organizzazione) o un principal del servizio Entra ID (applicazione) 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 per MongoDB non sono compatibili con l'uso dei token Entra ID per la connessione 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 gli strumenti di database esistenti, ad esempio SQL*Plus, per utilizzare un token Entra ID da una posizione file. In questi casi, i token Entra ID possono essere recuperati utilizzando strumenti come Microsoft PowerShell o Azure CLI e inseriti in una posizione file. I token di accesso al database OAuth2 con ID Entra vengono emessi con un'ora di scadenza. Il driver client Oracle Database verificherà che il token sia in un formato valido e che non sia scaduto prima di passarlo al database. Il token viene 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 ID Entra nella registrazione dell'app Entra ID del database sono inclusi come parte del token di accesso. La posizione della directory per il token ID Entra deve disporre solo dell'autorizzazione sufficiente per consentire all'utente di scrivere il file token nella posizione e al client del database per recuperare questi file (ad esempio, solo lettura e scrittura 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 di Entra ID.

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

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

Oracle Autonomous Database supporta i seguenti flussi di autenticazione Entra ID:

  • Flusso interattivo (detto anche flusso di codici di autorizzazione) che utilizza la chiave di prova per lo scambio di codice (PKCE), più comunemente utilizzata dagli utenti umani (non dalle applicazioni) per l'autenticazione all'ID Entra in un ambiente client con un browser
  • Credenziali client, che si riferiscono alle applicazioni di database che si connettono come se stesse (e non all'utente finale)
  • Operazioni di base (OBO), in cui un'applicazione richiede un token di accesso per conto di un utente collegato da inviare al database
  • Credenziale della password del proprietario della risorsa (ROPC), che non è consigliata per l'uso in produzione, ma può essere utilizzata in ambienti di test in cui l'autenticazione utente di un browser popup sarebbe difficile da incorporare. ROPC richiede che il nome utente e la password dell'ID Entra facciano parte della chiamata di richiesta del token.
Nota

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

Argomenti

Argomento padre: usare l'ID di Microsoft Entra con Autonomous Database

Architettura di Oracle Database Integration con ID Entra Microsoft

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

Il token di accesso dell'ID Entra 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 ID Entra da una posizione file oppure il token può essere passato al client tramite l'API client del database. Un utente di Azure può utilizzare uno script (esempi disponibili da Microsoft) per recuperare un token e inserirlo in una posizione file da recuperare per il client del database. Le applicazioni possono utilizzare l'SDK di Azure per ottenere un token di accesso e passare il token tramite l'API client del 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 informazioni su ciascun flusso supportato, vedere Supporto del flusso di autenticazione in MSAL nella documentazione ID di Microsoft Entra.

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

Il flusso del codice di autorizzazione è uno standard OAuth2 e viene descritto in dettaglio come parte degli standard. Nel flusso sono presenti due passi. Il primo passo consente di autenticare l'utente e recuperare 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 del database richiede un codice di autorizzazione dall'ID Entra.
  3. Entra ID autentica l'utente di Azure e restituisce il codice di autorizzazione.
  4. Lo strumento o l'applicazione di supporto utilizza il codice di autorizzazione con l'ID Entra per scambiarlo con il token OAuth2.
  5. Il client del database invia il token di accesso OAuth2 al database Oracle. Il token include i ruoli applicazione del database a cui l'utente è stato assegnato nella registrazione dell'applicazione ID Entra 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 dall'ID Entra.

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

Mapping di utenti Azure a uno schema e a 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 ID Entra 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 che l'amministratore del database crei e gestisca 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 a far parte dell'organizzazione. L'amministratore del database deve inoltre modificare i privilegi e i ruoli concessi allo schema del 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 un account non utilizzato non venga lasciato nel database. L'uso dei ruoli applicazione database consente all'amministratore di 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 ID Entra e gli amministratori del 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 di Azure e uno schema di Oracle Database. In questo tipo di mapping, è necessario creare lo schema di database per l'utente di Azure. I privilegi e i ruoli del database necessari per l'utente di Azure devono essere concessi allo schema del database. Lo schema di database deve essere creato non 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 le attività dell'ID Entra 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 ID Entra e uno schema Oracle Database. Questo tipo di mapping, più comune dei mapping esclusivi, è per gli utenti di Azure che sono stati assegnati direttamente al ruolo applicazione o sono membri di un gruppo di ID Entra assegnato al ruolo applicazione. Il ruolo applicazione è mappato a uno schema di Oracle Database (mapping di schema condiviso). Il mapping di schemi condivisi 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 a far parte dell'organizzazione. Questa efficienza operativa consente agli amministratori del database di concentrarsi sulle attività di manutenzione, prestazioni e ottimizzazione delle applicazioni del database invece di configurare nuovi utenti, aggiornare privilegi e ruoli e rimuovere account.

Oltre ai ruoli e ai privilegi del 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 ID Entra assegnato al ruolo applicazione verrà concesso il ruolo globale di Oracle Database quando accedono al database.

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

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

Questi mapping sono i seguenti:

  • Un utente di Azure può essere mappato direttamente a uno schema globale (utente) di Oracle Database.
  • Un utente di Azure, un gruppo di ID Entra 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 Oracle Database mediante l'ID Entra

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 all'ID Entra per ottenere il codice di autorizzazione. Questo codice viene utilizzato per ottenere il token di accesso al database. Consulta l'articolo di Microsoft Azure Piattaforma di identità Microsoft e il flusso di codici di autorizzazione OAuth 2.0.
  • Credenziali della 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 grafici 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'app 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 dall'ID Entra quando l'applicazione si connette al database. L'applicazione può passare il token tramite il file system o l'API client del database.
  • Token OBO (On-behalf-of): un'applicazione Azure richiede un token OBO per un utente collegato. 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 Azure e passarlo al client del database tramite l'API.