recursive.codes


The Personal Blog of Todd Sharp

Securely Connecting to Autonomous DB Without a Wallet (Using TLS)

Posted By: Todd Sharp on 10/6/2021 8:00 GMT
Tagged: Cloud, Java

I talk to a lot of developers in my job as a Developer Advocate. Sometimes they've been using the products in the Oracle Cloud for a long time, and sometimes they have very little (or no) experience with Oracle Cloud. Out of all the developers I've talked to about Autonomous DB (ADB), approximately 100% of them have voiced displeasure, general unhappiness, and/or aggravation about using a Wallet to connect to the cloud DB service. In fact, that's probably the only complaint I've really ever heard about the otherwise excellent and easy-to-use ADB. But today - today I have good news! Today is the day that we can connect to Autonomous DB without a wallet! To celebrate, I've decided to have a conversation with myself to help clarify certain things. Here's a quick overview of the conversation that I had with myself:

But How?

I knew you'd ask that question. The answer is...complicated. Kinda. Before today, ADB used mTLS (mutual TLS) as an extra secure way to establish the client-server connection. mTLS means that both the client and the server have an extra special secret key and they show that key to each other to verify that they are who they say they are. Going forward, you can configure ADB to use TLS instead of mTLS which means that only the server needs the extra special secret key and the client trusts that the server's key is valid. 

Is TLS Less Secure Than mTLS? 

Maybe. Certainly having both the client and server exchange credentials leaves less chance for invalid or improper connections. But it also requires you to download and install your wallet on the server that is connecting to ADB. This means that if someone can obtain access to the server, they likely have access to the wallet as well. Also, we can mitigate the risk with other security practices as we'll talk about later.

So, It's Less Secure...

I didn't say that! Besides, as I said just a second ago - there are other things we can do to mitigate any potential security risks. For example, to enable TLS on an ADB instance with a public endpoint exposed, you must have an Access Control List (ACL) in place. The ACL is an "allow" list that limits access to only the IP addresses or Virtual Cloud Networks (VCN) that have been added to it. If you're using a private endpoint that restricts connections, you can also use TLS instead of mTLS. Since traffic outside of the VCN is blocked, you can have confidence that your connection is secured.

Do I Have to use TLS?

Of course not. If you're happy using mTLS and a wallet, there is no reason to change anything. TLS connections are opt-in, so you don't have to worry about turning anything off or changing anything. Just keep querying!

Can I Enable Both TLS and mTLS?

Sure can! Just enable TLS and disable the mTLS requirement.

OK, How Do I Enable and Connect With TLS?

Glad you asked. Let's look at a quick example. This'll use Micronaut because I find it quite easy, but the same concepts apply to any JDBC-based connection. 

Enable TLS

Log in to the Oracle Cloud console and select your ADB instance to view the instance details. In the details, find the section titled 'Network' and click on 'Edit' next to 'Access Control List'.

In the 'Edit Access Control List' dialog, choose the type of entry that you'd like to make and enter the appropriate value. You can add entries by IP Address (I added my local IP), CIDR Block (maybe your office has a range of IPs assigned to developers), and VCN (by name or OCID). Add as many as necessary.

Remember!  The ACL is an "allow list", not a "deny list". That means it blocks all traffic except for the exceptions listed.  

Disable mTLS

To use either TLS or mTLS, you must disable the requirement for mTLS. Kinda confusing, but think about it like this: If mTLS is enabled, you can only connect with mTLS. If it's disabled, you can connect with either mTLS or TLS. 

Now uncheck 'Require mutual TLS (mTLS) authentication' and click 'Save Changes'.

Obtain Connection String

Since we no longer have a tnsnames.ora file that tells the OJDBC driver how to connect to ADB, we need to grab a connection string that we can plug into our JDBC URL in the Java app. In the instance details, click on 'DB Connection'.

In the DB connection dialog, under 'Connection Strings', select TLS from the dropdown menu. Then, copy the appropriate Connection String based on your application's requirements.

Configure Java Application

In my Micronaut application, I set the following values in my configuration file (application.yml).

I also made sure I had the latest OJDBC driver per the docs and launched the application. 

Launch the Application!

And that's it. That's all the changes I needed to make. No more wallets, no more secrets storing wallet values, no more headaches! Just a secure, encrypted connection between my app and ADB!

I Want to Read All the Docs!

Here you go:

Summary

We made our Java application connect to ADB using TLS instead of mTLS for secure, encrypted communications without a wallet.



Related Posts

Send and Receive Messages via REST with Advanced Queuing and ORDS

Send and Receive Messages via REST with Advanced Queuing and ORDS

A while back, I blogged about using Oracle Advanced Queuing (AQ) for messaging within your applications. It's a great option for durable and reliable...

Enterprise Messaging via Oracle Advanced Queuing with Autonomous DB & Micronaut

Enterprise Messaging via Oracle Advanced Queuing with Autonomous DB & Micronaut

I’ve written about messaging many, many times on this blog. And for good reason, too. It’s a popular subject that developers can’t seem to get enough of...

How to Securely Connect to Private Resources (for Free!) via the OCI Bastion Service

How to Securely Connect to Private Resources (for Free!) via the OCI Bastion Service

When working in the cloud, there are often times when your servers and services are not exposed to the public internet. Private virtual cloud networks ...

Note: Comments are currently closed on this blog. Disqus is simply too bloated to justify its use with the low volume of comments on this blog. Please visit my contact page if you have something to say!