Oracle® Database JDBC Developer's Guide and Reference 10g Release 2 (10.2) Part Number B14355-02 |
|
|
View PDF |
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.
Note: 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:
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:
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.
Note: 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. |
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.
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.
Note: 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. |
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 |
OFF |
OFF |
OFF |
connection fails |
Server Accepted (default) |
OFF |
OFF |
ON |
ON |
Server Requested |
OFF |
ON |
ON |
ON |
Server Required |
connection fails |
ON |
ON |
ON |
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.
Note: 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:
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 |
|
(see Note) |
Client integrity level |
|
|
Client integrity selected list |
|
|
Note: For the Oracle Advanced Security domestic edition only, settings ofRC4_128 and RC4_256 are also possible. |
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 |
---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Notes:
|
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();ods.setProperties(prop);ods.setURL("jdbc:oracle:thin:@localhost:1521:main");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.
Note: In the example, the string "REQUIRED" is retrieved dynamically through functionality of theAnoServices 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.ENCRYPTION_SERVER = ACCEPTED SQLNET.CRYPTO_CHECKSUM_SERVER = ACCEPTED SQLNET.CRYPTO_CHECKSUM_TYPES_SERVER= (MD5, SHA1) SQLNET.ENCRYPTION_TYPES_SERVER= (DES40, DES, 3DES112, 3DES168) 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]); props.load(defaultStream); 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_client", Service.getLevelString(level)); 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(); ods.setURL("jdbc:oracle:thin:@//host.example.com:1521/main.example.com"); ods.setConnectionProperties(props); 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)); conn.close(); } }
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 |