In recent months, I've helped many customers understand Oracle's two new cloud native architectures for centralizing authentication including multi-factor, authorization, and user life cycle management of Oracle database users. These two new architectures enable integration with identity providers Oracle Cloud Infrastructure Identity and Access Management (OCI IAM) and Microsoft's Entra ID.
The interactive SAML flow of this architecture outsources authentication to the identity provider by popping up a browser to the identity provider. Once the authentication browser with the identity provider is complete, an authorization code is returned to the database client. The client then securely sends the access token to the database server over a TLS encrypted connection between the database client and database server. Finally, the database confirms the validity of the access token from the public key that it retrieves from the identity provider. The following diagram illustrates this interactive flow with Entra ID.
The configuration options for the TLS configuration for a standalone database is covered in the following previous blog posts:
When a database client connects to the RAC cluster through SCAN listener, the SCAN listener re-directs the client to the local listener specified by
LOCAL_LISTENER of the RAC node to which he database client is then connected. The LOCAL_LISTENER is managed by RAC to take into consideration fail-overs and fall-backs which is most easily accomplished by using IP addresses rather than host names.
Given that the client connects via TLS to both the SCAN listener hostname and then to the IP address of the RAC node, the certificate(s) will need to either use a single host cert for all of the RAC nodes and SCAN listener, or a
Subject Alternative Name (SAN) certificate that includes the SCAN listener name and all possible RAC node names and the RAC node IP addresses or use a wildcard certificate.
Most customers avoid wildcard certificates like the plague because it of the security risk that it represents by not having unique certificates per host. Therefore, we will distill the RAC certificate options down to the following three options.
Option 1: Single Host Certificate
This option is possible because the database client can validate the certificate by the SSL_SERVER_CERT_DN alone rather than matching the host value to the CN value of the certificate subject or one of the certificate Subject Alternative Name (SAN) entries. Let's consider the following TNS entry:
Let's start with looking up the certificate subject from database server with orapki:
$ orapki wallet display -complete -wallet $WALLET_ROOT/tls -pwd Oracle123|egrep "Certificates:|Subject:"
Requested Certificates:
User Certificates:
Subject: C=US,ST=Texas,L=Austin,O=MyCo,CN=scan.myco.com
Trusted Certificates:
Subject: CN=Certificate Authority,O=Company,L=Austin,ST=Texas,C=US
Alternatively, you can retrieve the certificate subject with openssl form a UNIX/Linux host:
echo | openssl s_client -connect scan.myco.com:2484 2>&1 | openssl x509 -noout -text | egrep "DNS:|IP:|Subject:"
Subject: C=US,ST=Texas,L=Austin,O=MyCo,CN=scan.myco.com
The client TNS entry would look like the following where key TLS properties are highlighted in blue and the SSL_SERVER_CERT_DN is set to the exact subject DN of the certificate.
PDB1 =
(DESCRIPTION=
(ADDRESS_LIST=
(ADDRESS=(PROTOCOL=TCPS)(HOST=scan.myco.com)(PORT=2484))
)
(SECURITY=
(SSL_SERVER_DN_MATCH=TRUE)
(SSL_SERVER_CERT_DN="C=US,ST=Texas,L=Austin,O=MyCo,CN=scan.myco.com")
(WALLET_LOCATION=SYSTEM)
(TOKEN_AUTH=AZURE_INTERACTIVE)
(TENANT_ID=7f4c6e3e-a1e0-43fe-14c5-c2f051a0a3a1)
(CLIENT_ID=e5124a85-ac3e-14a4-f2ca-1ad635cf781a)
(AZURE_DB_APP_ID_URI=https://dbauthdemo.com/16736175-ca41-8f33-af0d-4616ade17621)
)
(CONNECT_DATA=
(SERVICE_NAME=pdb1)
)
)
Option 2: Single SAN Certificate
The single Subject Alternative Name (SAN) certificate is slightly more secure because you incorporate all of the possible names and IP address of the RAC cluster into the SAN entries of a single certificate where the subject of the certificate includes the SCAN listener host name for it's canonical name (CN) value.
Let's start with looking up the certificate subject from database server with orapki:
$ orapki wallet display -complete -wallet $WALLET_ROOT/tls -pwd Oracle123|egrep "Certificates:|Subject:"
Requested Certificates:
User Certificates:
Subject: C=US,ST=Texas,L=Austin,O=MyCo,CN=scan.myco.com
Trusted Certificates:
Subject: CN=Certificate Authority,O=Company,L=Austin,ST=Texas,C=US
Alternatively, you can retrieve the certificate subject and SAN entries with openssl form a UNIX/Linux host:
echo | openssl s_client -connect scan.myco.com:2484 2>&1 | openssl x509 -noout -text | egrep "DNS:|IP:|Alternative|Subject:"
Subject: C=US,ST=Texas,L=Austin,O=MyCo,CN=scan.myco.com
X509v3 Subject Alternative Name:
DNS:node1.myco.com, DNS:node2.myco.com, DNS: node1, DNS: node2 IP: 10.0.0.10, IP 10.0.0.20
Note in the above openssl output, that the DNS and IP SAN entries are listed as well and that they include the fully qualified host names, unqualified host names and IP addresses of the RAC nodes. This is important because clients can sometimes connect directly to a RAC node rather than through the SCAN listener. In this case, you wan the certificate to find a match in the SAN entries to complete the TLS connection.
The client TNS entry would look like the following where key TLS properties are highlighted in blue and the SSL_SERVER_CERT_DN is not present because the DN matching is just looking to find a match of ADDRESS HOST value with the CN value of the certificate subject name or any of the SAN entries.
PDB1 =
(DESCRIPTION=
(ADDRESS_LIST=
(ADDRESS=(PROTOCOL=TCPS)(HOST=scan.myco.com)(PORT=2484))
)
(SECURITY=
(SSL_SERVER_DN_MATCH=TRUE)
(WALLET_LOCATION=SYSTEM)
(TOKEN_AUTH=AZURE_INTERACTIVE)
(TENANT_ID=7f4c6e3e-a1e0-43fe-14c5-c2f051a0a3a1)
(CLIENT_ID=e5124a85-ac3e-14a4-f2ca-1ad635cf781a)
(AZURE_DB_APP_ID_URI=https://dbauthdemo.com/16736175-ca41-8f33-af0d-4616ade17621)
)
(CONNECT_DATA=
(SERVICE_NAME=pdb1)
)
)
Option 3: Individual SAN Certificates Per RAC Node
The individual SAN certificate is again more secure because you specify a host-specific set of SAN entries for that host's names and IP address.
Let's start with looking up the certificate subject and SAN entries from the first RAC node with openssl from a UNIX/Linux host:
echo | openssl s_client -connect node1.myco.com:2484 2>&1 | openssl x509 -noout -text | egrep "DNS:|IP:|Alternative|Subject:"
Subject: C=US,ST=Texas,L=Austin,O=MyCo,CN=scan.myco.com
X509v3 Subject Alternative Name:
DNS:node1.myco.com, DNS: node1, IP: 10.0.0.10
Next, lets lookup the certificate subject and SAN entries from the second RAC node with openssl from a UNIX/Linux host:
echo | openssl s_client -connect node1.myco.com:2484 2>&1 | openssl x509 -noout -text | egrep "DNS:|IP:|Alternative|Subject:"
Subject: C=US,ST=Texas,L=Austin,O=MyCo,CN=scan.myco.com
X509v3 Subject Alternative Name:
DNS:node2.myco.com, DNS: node2, IP: 10.0.0.20
Note in the above openssl output, that the DNS and IP SAN entries are listed as well and that they include the fully qualified host names, unqualified host names and IP addresses of the just the local RAC node rather than all RAC nodes.
A similar RAC node specific certificate would be created and installed on each respective RAC node and respective listener.
The client TNS entry would be the same as the Option 2 because the difference in the two options is the contents of the certificate.
If you encounter issues with any of these configurations or EntraID integration, check out my blog posts on troubleshooting these areas:
Those are the three certificate options for RAC clusters.
I hope you found this information useful.
Blessings!
Brad
No comments:
Post a Comment