Database Reference
In-Depth Information
and retrieve new secret password key artifacts in return, then an update (which doesn't exchange keys)
will fail. This is what we will test.
Note that it is unlikely that we will accidentally reset our keys, and calling the
getLocRSAPubMod()
method or other methods of
OracleJavaSecure
multiple times will not create new keys if they already
exist, but rather will return the existing keys. The keys are
static
, so they will not disappear on their own
as long as the Java Virtual Machine continues to run. So, this test is really just for fun: answering a “what
if” question.
Testing Failure with New Oracle Connection
Another test that we can demonstrate is the scenario wherein we close the
Connection
to Oracle database
and establish a new one. The server-side keys will disappear—both the client public key and the secret
password key. We can reset the
Connection
and prepare to call our encryption procedures by setting our
Secure Application Role to
HRVIEW_ROLE
as in Listing 7-29.
Listing 7-29.
Reset Connection and Re-Set Secure Application Role
if ( null != conn ) conn.close();
conn = DriverManager.getConnection( appusrConnString );
OracleJavaSecure.setConnection( conn );
stmt = ( OracleCallableStatement )conn.prepareCall(
"CALL appsec.p_check_hrview_access()" );
stmt.executeUpdate();
Again, in the case of doing an encrypted Oracle update, we will see a failure because Oracle database
has neither the public key nor the secret password key. This code is initially commented.
Some Closing Remarks
I've covered all the big demonstrations and tests in the preceding sections. Now, it's your turn to modify
the tests and try some of your own. Feel free to comment and uncomment those sections of test code
that we just described. When you recompile and run those sections of
TestOracleJavaSecure
you will see
a message on an attempted data update that indicates we have “Failed where expected—OK.”
If You Need To Close/Open Your Connection
Resetting your Oracle connection poses another potential problem when we do a select of encrypted
data, for certainly we will pass our public key to Oracle database, and the database will build the secret
password key and hand it back. However, we still retain an old copy of the secret password key on the
client and will run into problems decrypting the data. We can remedy that after getting and decrypting
the secret password key artifacts on the client with an immediate call to the
OracleJavaSecure.makeDESKey()
method, before we try to decrypt the data.
I think the best rule of thumb, and an examination on your code review checklist, is to retain the
Oracle connection for the duration of your queries and updates. If there are long pauses and you need to
close the Oracle connection, when you open a new connection, pass your public key artifacts to Oracle
database via the
p_get_shared_passphrase
procedure (described in the following) and build a
replacement secret password key on the client by calling the
makeDESKey()
method.
