Database Reference
In-Depth Information
Chapter Review
So, what have we got working so far? This whirlwind description will attempt to cover the secure
programming ground traversed by this test application,
TestOracleJavaSecure
.
We call the
TestOracleJavaSecure
class without a two-factor authentication code for starts. The test
application sets its application context in
OracleJavaSecure
by passing its inner class and application ID.
Then (in a standard run mode) the test app calls
OracleJavaSecure.getAAConnRole()
.
Behind the scenes, in
OracleJavaSecure
, we proxy connect to Oracle Database as the OS user,
proxying through the Oracle
appver
user. Initially, the login trigger for the
appver
schema checks to
assure that the OS user is a valid Oracle user.
Once connected to Oracle database as
appver
, we test if the user passes our SSO tests. Then, because
we didn't provide a two-factor authentication code, Oracle database generates a code and sends it to the
devices and accounts registered for the OS user.
Once we receive the two-factor authentication code, we call
TestOracleJavaSecure
again, passing
the two-factor code. The two-factor code gets passed to
OracleJavaSecure
when
TestOracleJavaSecure
sets the application context. Now when we call Oracle database as
appver
and pass SSO, we check the
two-factor code; and if it passes, and the inner class from our app context matches something in Oracle,
we return the list of encrypted connection strings that has been stored for this application.
Another behind-the-scenes process that occurred is our key exchange for application verification
processes. The client sent his RSA public key to Oracle, and Oracle database generated a shared
password key, encrypted it with the RSA key, and returned it to the client. The connection strings are
encrypted with the shared password key.
Continuing the behind-the-scenes activity of the
getAAConnRole()
method, we decrypt the
requested connection string and connect to Oracle database with it. We connect in order to request the
secure application role needed by the application in order to read data from Oracle database. In an effort
to acquire the secure application role, we once again assure that we pass SSO (perhaps on a different
Oracle instance from
appver
), but we do not do two-factor authentication again for this connection.
OracleJavaSecure.getAAConnRole()
will return an
OracleConnection
, which the developer can use to
call one of his application procedures in order to get encrypted application data. When he makes that
call, he will exchange encryption keys for the new connection, and will retrieve data encrypted with a
new shared password key. We decrypt the aspects of the shared password key and build that key, and
then we decrypt the data using that key.
Figures 10-1 and 10-2 illustrate this process. In Figure 10-1 we see the process of getting a list of
application Oracle connection strings from Oracle database. This is a two-phase process, with phase one
being the first connection when requesting a two-factor authentication code, and phase two being the
user's return with a two-factor authentication code in hand. The two outlined boxes illustrate the
activities of each of those phases.
At the outset (top) of Figure 10-1, we call the
setAppContext()
method, which simply stages data for
the particular client application in the static class member variables of
OracleJavaSecure
. After that, the
client application makes one additional call to
getAppConnections()
. Near the end of the second phase of
that process, note that the list of connection strings is not returned to the client application, but rather is
held in escrow within the client-side
OracleJavaSecure
class. The list is a private class member of
OracleJavaSecure
. You can also see within the second phase that before the connection strings are
returned, they are encrypted with secret password key, and they are returned in encrypted form.
Along with the list of encrypted Oracle connection strings for the application, the encrypted artifacts
of the DES shared password key are also returned from Oracle database.
OracleJavaSecure
on the client
builds an equivalent shared password key for use in decrypting the application connection strings. After
building the DES shared password key and storing the key for later use in clone or new static members,
the
resetKeys()
method is called so that further Oracle connections as application users may be made.
