Application Authorization - Expert Oracle and Java Security - page 246

sessionSecretDESKey to null because, by experimentation, we have determined that doing so invalidates
the appAuthSessionSecretDESKey . For that reason, we are going to modify several methods to test
sessionSecretDESPassPhraseChars for null , instead of testing sessionSecretDESKey for null :
getCryptData() , getDecryptData() and the set of methods getCryptSessionSecretDESPassPhrase() /
Algorithm / Salt / IterationCount . I know some would prefer I not elaborate on gotcha's and tests and
alternate scenarios, but the goal here is not just to develop an application, but also to develop an
understanding. If we don't explore these issues here, you will be left to find them out on your own, which
is not bad, but can be time-consuming.
Get the List of Connection Strings
From the RAW bytes returned as the application connsHash object, we generate the object by passing the
bytes through a ByteArrayInputStream and an ObjectInputStream . If the resultant object is not null, we
cast the object as a HashMap<String, RAW> , as shown in Listing 10-44. This is where our compiler reports
an “unchecked” warning. If, however, the object we got from Oracle database is null, we assume that no
connsHash has been stored yet for this registered application, and we set connsHash to a new, empty
HashMap<String, RAW> . After one of those scenarios, we are then free to put new connection strings into
connsHash via the putAppConnString() method, and to store them in the v_app_conn_registry view via
the putAppConnections() method.
Listing 10-44. Cast Connections List Object from Oracle Database as a HashMap
if( classObject != null ) {
connsHash = (HashMap<String, RAW>)classObject ;
} else {
connsHash = new HashMap<String, RAW>();
}
Establish a Connection for Application Verification Processes
I have reservations about the form of the setAppVerConnection() method that we have in this chapter—
see Listing 10-45. I have already intimated that it is our plan to have this connection available to all, like a
bouncer in a night club, treating his user name and password as little more than data, but that is not how
I want to leave it.
It's just that this chapter is already quite weighty in scope, and I have a number of rather lengthy
considerations in this regard that I feel will be best delayed until the next chapter. Please continue on to
the next chapter for that discussion.
Listing 10-45. Method to Set Application Verification Connection, setAppVerConnection()
private static void setAppVerConnection() {
setConnection( "jdbc:oracle:thin:appver/password@localhost:1521:orcl" );
appVerConn = conn;
}
For now, ignore the man behind the curtain. This is reminiscent of passwords embedded in our
application code; something we hope to get away from.
Notice also the last line of Listing 10-45. We set a static class member (see also Listing 10-42) to
retain the application verification connection.