10 JDBC Client-Side Security Features

This chapter discusses support in the Oracle Java Database Connectivity (JDBC) Oracle Call Interface (OCI) and JDBC Thin drivers for login authentication, data encryption, and data integrity, particularly, with respect to features of the Oracle Advanced Security option.

Oracle Advanced Security, previously known as the Advanced Networking Option (ANO) or Advanced Security Option (ASO), includes features to support data encryption, data integrity, third-party authentication, and authorizations. Oracle JDBC supports most of these features. However, the JDBC Thin driver must be considered separately from the JDBC OCI driver.


This discussion is not relevant to the server-side internal driver, given that all communication through that driver is completely internal to the server.

This chapter contains the following sections:

Support for Oracle Advanced Security

Both the JDBC OCI and the JDBC Thin drivers support at least some of the Oracle Advanced Security features. If you are using the OCI driver, then you can set relevant parameters in the same way that you would in any Oracle client setting. The JDBC Thin driver supports the Oracle Advanced Security features through a set of Java classes included with the JDBC classes in a Java Archive (JAR) file and supports security parameter settings through Java properties objects.

This section covers the following topics:

JDBC OCI Driver Support for Oracle Advanced Security

If you are using the JDBC OCI driver, which presumes you are running from a computer with an Oracle client installation, then support for Oracle Advanced Security and incorporated third-party features is fairly similar to the support provided by in any Oracle client situation. Your use of Advanced Security features is determined by related settings in the SQLNET.ORA file on the client computer.


The key exception to the preceding, with respect to Java, is that the Secure Sockets Layer (SSL) protocol is supported by the Oracle JDBC OCI drivers only if you use native threads in your application. This requires special attention, because green threads are generally the default.

JDBC Thin Driver Support for Oracle Advanced Security

The JDBC Thin driver cannot assume the existence of an Oracle client installation or the presence of the sqlnet.ora file. Therefore, it uses a Java approach to support Oracle Advanced Security.

Java classes that implement Oracle Advanced Security are included in your JDBC classes12.jar or ojdbc14.jar file. Security parameters for encryption and integrity, normally set in SQLNET.ORA, are set in a Java properties file instead.

Support for Login Authentication

Basic login authentication through JDBC consists of user names and passwords, as with any other means of logging in to an Oracle server. Specify the user name and password through a Java properties object or directly through the getConnection method call.

This applies regardless of which client-side Oracle JDBC driver you are using, but is irrelevant if you are using the server-side internal driver, which uses a special direct connection and does not require a user name or password.

The Oracle JDBC Thin driver implements Oracle O3LOGON challenge-response protocol to authenticate the user.


Third-party authentication features supported by Oracle Advanced Security, such as those provided by RADIUS, Kerberos, or SecureID, are not supported by the Oracle JDBC Thin driver. For the Oracle JDBC OCI driver, support is the same as in any Oracle-client situation.

Support for Data Encryption and Integrity

You can use Oracle Advanced Security data encryption and integrity features in your Java database applications, depending on related settings in the server.

When using the JDBC OCI driver, set parameters as you would in any Oracle client situation. When using the Thin driver, set parameters through a Java properties object.

Encryption is enabled or disabled based on a combination of the client-side encryption-level setting and the server-side encryption-level setting.

Similarly, integrity is enabled or disabled based on a combination of the client-side integrity-level setting and the server-side integrity-level setting.

Encryption and integrity support the same setting levels, REJECTED, ACCEPTED, REQUESTED, and REQUIRED. Table 10-1 shows how these possible settings on the client-side and server-side combine to either enable or disable the feature.

Table 10-1 Client/Server Negotiations for Encryption or Integrity

Client Rejected Client Accepted (default) Client Requested Client Required

Server Rejected




connection fails

Server Accepted (default)





Server Requested





Server Required

connection fails




Table 10-1 shows, for example, that if encryption is requested by the client, but rejected by the server, it is disabled. The same is true for integrity. As another example, if encryption is accepted by the client and requested by the server, it is enabled. And, again, the same is true for integrity.


The term checksum still appears in integrity parameter names, but is no longer used otherwise. For all intents and purposes, checksum and integrity are synonymous.

This section covers the following topics:

JDBC OCI Driver Support for Encryption and Integrity

If you are using the JDBC OCI driver, which presumes a Oracle-client setting with an Oracle client installation, then you can enable or disable data encryption or integrity and set related parameters as you would in any Oracle client situation, through settings in the SQLNET.ORA file on the client.

To summarize, the client parameters are shown in Table 10-2:

Table 10-2 OCI Driver Client Parameters for Encryption and Integrity

Parameter Description Parameter Name Possible Settings

Client encryption level



Client encryption selected list


RC4_40, RC4_56, DES, DES40, AES128, AES192, AES256, 3DES112, 3DES168

(see Note)

Client integrity level



Client integrity selected list




For the Oracle Advanced Security domestic edition only, settings of RC4_128 and RC4_256 are also possible.

JDBC Thin Driver Support for Encryption and Integrity

The JDBC Thin driver support for data encryption and integrity parameter settings parallels the JDBC OCI driver support discussed in the preceding section. Corresponding parameters can be set through a Java properties object that you would then be used when opening a database connection.

Table 10-3 lists the parameter information for the JDBC Thin driver.

Table 10-3 Thin Driver Client Parameters for Encryption and Integrity

Parameter Name Parameter Type Parameter Class Possible Settings








RC4_40 RC4_56 DES40C DES56C 3DES112 3DES168










  • Because Oracle Advanced Security support for the Thin driver is incorporated directly into the JDBC classes JAR file, there is only one version, not separate domestic and export editions. Only parameter settings that would be suitable for an export edition are possible.

  • The letter C in DES40C and DES56C refers to Cipher Block Chaining (CBC) mode.

Setting Encryption and Integrity Parameters in Java

Use a Java properties object, that is, an instance of java.util.Properties, to set the data encryption and integrity parameters supported by the JDBC Thin driver.

The following example instantiates a Java properties object, uses it to set each of the parameters in Table 10-3, and then uses the properties object in opening a connection to the database:

Properties prop = new Properties();
prop.put("oracle.net.encryption_client", "REQUIRED");
prop.put("oracle.net.encryption_types_client", "( DES40 )");
prop.put("oracle.net.crypto_checksum_client", "REQUESTED");
prop.put("oracle.net.crypto_checksum_types_client", "( MD5 )");

OracleDataSource ods = new OracleDataSource();
Connection conn = ods.getConnection();

The parentheses around the parameter values in the encryption_types_client and crypto_checksum_types_client settings allow for lists of values. Currently, the JDBC Thin driver supports only one possible value in each case. However, in the future, when multiple values are supported, specifying a list will result in a negotiation between the server and the client that determines which value is actually used.


Example 10-1 is a complete class that sets data encryption and integrity parameters before connecting to a database to perform a query.


In the example, the string "REQUIRED" is retrieved dynamically through functionality of the AnoServices and Service classes. You have the option of retrieving the strings in this manner or hardcoding them as in the previous examples

Before running this example, you must turn on encryption in the sqlnet.ora file. For example, the following four lines will turn on DES40, DES, 2-DES-112 and 3-DES168 for the encryption and MD5 and SHA1 for the checksum:

  SQLNET.CRYPTO_SEED = 12345678901234567890

Example 10-1 Setting Data Encryption and Integrity Parameters

import java.sql.*;
import java.sql.*;
import java.io.*;
import java.util.*;
import oracle.net.ns.*;
import oracle.net.ano.*;
import oracle.jdbc.*;
import oracle.jdbc.pool.*;

class Employee
  public static void main (String args [])
    throws Exception

    Properties props = new Properties();

    try {
      FileInputStream defaultStream = new FileInputStream(args[0]);

      int level = AnoServices.REQUIRED;
      props.put("oracle.net.encryption_client", Service.getLevelString(level));
      props.put("oracle.net.encryption_types_client", "( 3DES168 )");
      props.put("oracle.net.crypto_checksum_types_client", "( MD5 )");
    } catch (Exception e) { e.printStackTrace(); }

    // You can put a database name after the @ sign in the connection URL.
    OracleDataSource ods = new OracleDataSource();
    Connection conn = ods.getConnection();

    // Create a Statement
    Statement stmt = conn.createStatement ();

    // Select the ENAME column from the EMP table
    ResultSet rset = stmt.executeQuery ("select ENAME from EMP");

    // Iterate through the result and print the employee names
    while (rset.next ())
       System.out.println (rset.getString (1));



Secure External Password Store

As an alternative for large-scale deployments where applications use password credentials to connect to databases, it is possible to store such credentials in a client-side Oracle wallet. An Oracle wallet is a secure software container that is used to store authentication and signing credentials.

Storing database password credentials in a client-side Oracle wallet eliminates the need to embed user names and passwords in application code, batch jobs, or scripts. This reduces the risk of exposing passwords in the clear in scripts and application code, and simplifies maintenance because you need not change your code each time user names and passwords change. In addition, not having to change application code also makes it easier to enforce password management policies for these user accounts.

When you configure a client to use the external password store, applications can use the following syntax to connect to databases that use password authentication:

CONNECT /@database_alias

Note that you need not specify database login credentials in this CONNECT statement. Instead your system looks for database login credentials in the client wallet.

See Also:

Oracle Database Security Guide for information about configuring your client to use secure external password store and for information about managing credentials in it