Enhancing Security - Expert Oracle and Java Security - page 278

java -cp %CLASSPATH%;%ORACLE_HOME%\jlib\oraclepki.jar TestWallet
In the TestWallet.java file, you'll find a main() method with the code shown in Listing 11-12. You
may need to modify this code to run the test.
Listing 11-12. Configure Java to Use Client Wallet
System.setProperty("oracle.net.tns_admin",
"C:/app/oracle/product/11.2.0/client_1/NETWORK/ADMIN");
Properties info = new Properties();
String username = System.getProperty( "user.name" );
info.put("oracle.net.wallet_location",
"(SOURCE=(METHOD=file)(METHOD_DATA=(DIRECTORY=C:/Users/" +
username + "/" + username + ")))");
We set the tns_admin system property so that we can find the tnsnames.ora file, and the connect
identifier, orcl_appusr inside that file. We instantiate a Properties object that we will pass when we get
the Connection . One of the properties we need to set is the wallet_location property. You'll recall that
we created or copied the wallet files into the user's home directory in a directory by the same name as
the user. In order to set that wallet property, we get the user.name System property, and concatenate a
directory location from that value.
We use an OracleDataSource class to get our connection as shown in Listing 11-13. We saw
OracleDataSource in Chapter 8 when we looked at single sign on with one of the varieties of pooled
connections. In this case, we set the connection URL to use our wallet connect identifier, orcl_appusr .
We also pass in the Properties class we instantiated earlier, and we call the getConnection() method.
Listing 11-13. Get a Connection in Java Using Client Wallet
OracleDataSource ds = new OracleDataSource();
ds.setURL("jdbc:oracle:thin:@ orcl_appusr ");
ds.setConnectionProperties(info);
Connection c = ds.getConnection();
In TestWallet.java , we also set up a proxy connection, identical to what we are using in
OracleJavaSecure . For that reason, only OS users who can do SSO (who have matching Oracle users) can
run TestWallet .
Administer Wallet Security
A client wallet might be the perfect solution for protecting our application verification appver user
password. I would encourage you to use it in this one instance, except for my reservations.
True, the wallet protects the password from being read by hackers, probably better than anything
we have developed so far in this topic. It works as described—once you get it working. It is easy to copy
around to each person's home directory for his or her use. Additionally, we have already portrayed the
appver password as little more than data: a gatekeeper or bouncer for the real application accounts.
Yet some of the positives of the wallet have their dark side. Anyone who has the wallet files can
connect to Oracle database as the user specified. That connection doesn't have to happen through your
application; it can happen through a SQL*Plus session, as we saw. With the appver user, that is not much
of a concern—but with most any other Oracle database user, it is a big problem. Don't only think of
legitimate computer users, but also (for example) those users who get access to your offsite backup
repositories and glean the wallet files from there. It is assumed that protection of the wallet files is