Database Reference
In-Depth Information
For this first phase of testing, we will accomplish all these steps in the
main()
method of
OracleJavaSecure
.
We are going to run through this test code at least twice. The first time, we will not have a valid two-
factor authentication code, so we will exit the program at a certain point. In short, the point we will exit
is just after we know a two-factor code has been sent to us, and before we try to use connection strings
associated with this application.
Set the Application Context
If we have a two-factor authentication code, we should pass it to the application on the command line as
an argument to the application. Alternatively, if you are running this test from an IDE, it may be easier to
embed the two-factor code, once received, into this class. You can do that where shown, then recompile
and execute it. See Listing 10-48. Remember that each two-factor code is only good for 10 minutes!
Listing 10-48.
Application Authentication Testing, Phase 1, main()
public static void main( String[] args ) {
OracleCallableStatement stmt = null;
Statement mStmt = null;
ResultSet rSet;
try {
// Submit two-factor auth code on command line, once received
String twoFactorAuth = "";
if( args.length != 0 && args[0] != null )
twoFactorAuth = args[0]
;
// You may place two-factor auth code here for testing from IDE
// Remember, it's only good for 10 minutes from creation
//twoFactorAuth
= "1234-5678-9012";
We call the
setAppContext()
method in Listing 10-49 to set our context for this application. In this
case, our application ID is
HRVIEW
, the only application we have configured so far; the one that can get
encrypted data from the
HR
schema. Recall that there is a user,
appusr
and a secure application role,
hrview_role
associated with this application ID.
Listing 10-49.
Testing Call to setAppContext()
String applicationID = "HRVIEW";
Object appClass = new InnerRevLvlClass();
setAppContext
( applicationID, appClass, twoFactorAuth );
Multiple Java applications can gain access through that application ID. They will all get the same
application user and role. Each Java application will be identified by a specific, representative
application inner class that it will hand to Oracle database for validation. If the currently authenticated
user (for whom the two-factor code was distributed) has been granted to proxy connect through the
application verification,
appver
user, and the application class that he hands Oracle database is valid,
then he will receive the connection strings associated with the application class. If the current user has
also been granted proxy connect through the Oracle application user embedded in the connection
string, then he will be free to use the connection to work with Oracle data.
There is another layer of control that you might consider applying, but which seems superfluous.
You might control which users have access to which applications. In my mind, you have already granted
the user access to data through whatever application interface they care to use by granting them proxy
