Use Azure Active Directory Authentication with Base Database Service

You can configure the Oracle Database in the Base Database Service to use Microsoft Azure Active Database authentication and authorization to allow Azure AD users to access the database with Azure AD credentials.

Related Topics

About Integrating Azure AD with Base Database Service

An Oracle Database in an Base Database Service instance can be configured for Microsoft Azure Active Directory (Azure AD) users to connect using Azure OAuth2 access tokens.

For more information about authorizing Azure AD users, architecture, user mappings, use cases, and the integration process, see Introduction to Authorizing Microsoft Azure AD Users for an Oracle Database section in the Oracle Database Security Guide.

Prerequisites

The following prerequisites are required for Azure AD authentication on Base Database Service.

Each of these are described in detail in the following topics.

Network Settings

Before using Azure AD authentication on databases, you must use the Networking service to add a service gateway, a route rule, and an egress security rule to the Virtual Cloud Network (VCN) and subnets where your database resources reside. Perform the following steps to configure outbound connectivity to Azure AD using a NAT gateway.

  1. Create a NAT gateway in the VCN where your database resources reside by following the instructions in Create the service gateway.
  2. After creating the service gateway, add a route rule and an egress security rule to each subnet (in the VCN) where the database resources reside so that these resources can use the gateway to obtain a public key from your Azure AD instance to use Azure AD authentication:
    1. Go to the Subnet Details page for the subnet.
    2. In the Subnet Information tab, click the name of the subnet's Route Table to display its Route Table Details page.
    3. In the table of existing Route Rules, check whether there is already a rule with the following characteristics:
      • Destination: 0.0.0.0/0
      • Target Type: NAT Gateway
      • Target: The name of the service gateway you just created in the VCN

      If such a rule does not exist, click Add Route Rules and add a route rule with these characteristics.

    4. Return to the Subnet Details page for the subnet.
    5. In the subnet's Security Lists table, click the name of the subnet's security list to display its Security List Details page.
    6. In the side menu, under Resources, click Egress Rules.
    7. In the table of existing Egress Rules, check whether there is already a rule with the following characteristics:
      • Destination Type: CIDR
      • Destination: 0.0.0.0/0
      • IP Protocol: TCP
      • Source Port Range: 443
      • Destination Port Range: All
    8. If such a rule does not exist, click Add Egress Rules and add an egress rule with these characteristics.

TLS Configuration

When sending Azure AD tokens from the database client to the database server, a TLS connection must be established. The TLS wallet with the database certificate for the Base Database Service instance must be stored under the WALLET_ROOT location. Create a tls directory so it looks like: WALLET_ROOT/<PDB GUID>/tls

When configuring TLS between the database client and server there are several options to consider.

  • Using a self-signed database server certificate vs a database server certificate signed by a commonly known certificate authority.
  • One-way TLS (TLS) vs Mutual or two-way TLS (mTLS).
  • Client with or without a wallet.

Self-signed certificate: Using a self-signed certificate is a common practice for internally facing IT resources since you can create these yourself and it's free. The resource (in our case, the database server) will have a self-signed certificate to authenticate itself to the database client. The self-signed certificate and root certificate will be stored in the database server wallet. For the database client to be able to recognize the database server certificate, a copy of the root certificate will also be needed on the client. This self-created root certificate can be stored in a client-side wallet or installed in the client system default certificate store (Windows and Linux only). When the session is established, the database client will check to see that the certificate sent over by the database server has been signed by the same root certificate.

A well-known certificate authority: Using a commonly known root certificate authority has some advantages in that the root certificate is most likely already stored in the client system default certificate store. There is no extra step for the client to store the root certificate if it is a common root certificate. The disadvantage is that this normally has a cost associated with it.

One-way TLS: In the standard TLS session, only the server provides a certificate to the client to authenticate itself. The client doesn't need to have a separate client certificate to authenticate itself to the server (similar to how HTTPS sessions are established). While the database requires a wallet to store the server certificate, the only thing the client needs to have is the root certificate used to sign the server certificate.

Two-way TLS (also called Mutual TLS, mTLS): In mTLS, both the client and server have identity certificates that are presented to each other. In most cases, the same root certificate will have signed both of these certificates so the same root certificate can be used with the database server and client to authenticate the other certificate. mTLS is sometimes used to authenticate the user since the user identity is authenticated by the database server through the certificate. This is not necessary for passing Azure AD tokens but can be used when passing Azure AD tokens.

Client with a wallet: A client wallet is mandatory when using mTLS to store the client certificate. However, the root certificate can be stored either in the same wallet or in the system default certificate store.

A client without a wallet: Clients can be configured without a wallet when using TLS under these conditions:
  1. One-way TLS is being configured where the client does not have its own certificate, and
  2. the root certificate that signed the database server certificate is stored in the system default certificate store. The root certificate would most likely already be there if the server certificate is signed by a common certificate authority. If it's a self-signed certificate, then the root certificate would need to be installed in the system default certificate store to avoid using a client wallet.

For details on how to configure TLS between the database client and database server including the options described above, see Configuring Transport Layer Security Authentication.

If you choose to use self-signed certificates and for additional wallet related tasks, refer to the orapki command line interface (CLI) reference guide in the Database Security Guide. See Managing Public Key Infrastructure (PKI) Elements.

Configure Base Database Service for Integration with Azure AD

The Base Database Service integration with the Azure AD requires the database to be registered with Azure AD so that the database can request the Azure AD public key.

To configure the Base Database Service for integration with the Azure AD, you must first complete the prerequisites in the Prerequisites section and then follow the instructions in the Configuring the Oracle Database for Microsoft Azure AD Integration section of the Oracle Database Security Guide.

Map Oracle Database Schemas and Roles

Azure AD users will be mapped to one database schema and optionally to one or more database roles.

For more information on the options for mapping Oracle Database schemas and roles to Azure AD users, see Mapping Oracle Database Schemas and Roles section in the Oracle Database Security Guide.

Configure Client Connections to Azure ADs

There are numerous ways that you can configure a client to connect with a Base Database Service instance using Azure AD tokens.

For more information about configuring Azure AD client connections, see Configuring Azure AD Client Connections to the Oracle Database section in the Oracle Database Security Guide.

Trace Files Used for Troubleshooting Connections

You can use trace files to troubleshoot Base Database Service client connections with Azure AD connections.

For more information about trace files and setting client tracing for token authentication, see Trace Files for Troubleshooting Oracle Database Client Connections with Azure AD section in the Oracle Database Security Guide.