Database Reference
In-Depth Information
Subject: Response for HRVIEW
1234-5678-9012 for HRVIEW
Application Authorization Overview
We are going to implement this entirely with Oracle database as the backend, of course running with the
Oracle JVM. That means we have to deal with one important security aspect. To talk to Oracle database
at all, we need to connect with a user and password. We will spend significant time addressing that issue.
In a nutshell, here is how we will do Application Authorization, which we will also refer to as
Application Verification:
1.
We will first connect to Oracle, proxying through a new user, appver.
2.
As in the past, we will need to pass the SSO and two-factor authentication
requirements.
3.
Once we have attained two-factor authentication, we exchange encryption
keys.
4.
We also retrieve an encrypted list of connection strings that we can use in our
current application.
5. When we use one of those application connection strings, we again assure our
SSO and we exchange additional encryption keys to query encrypted data, as
before; however, we do not re-do our two-factor authentication.
All of this looks well and good, but the question arises: how do we know what application is being
used? Well, we certainly don't want to merely take the application's word for it. A standard assumption
in secure computing is that given an opportunity, a hacker's code will lie—a sort of application identity
theft. We are distributing a list of connection strings, including user names and passwords, to known
applications. They are encrypted, but we don't want to hand them to just anyone.
In order to assure an application is who it says it is, we are going to ask the application to give us a
piece of itself, one which we have already received and registered. We will compare what the application
provides with what we have registered, and if they are “equal,” then we recognize the application.
The piece of an application that we demand be presented is an inner class. This class must have the
same name as the one we registered. We may register multiple versions of the same inner class, to
handle application upgrades, but connection strings need to be recreated or duplicated to the new
version.
When I say that we assure that the inner classes are “equal,” that is the litmus test. The default
equality test, which we do not override, is that the classes are equivalent; they reside at the same
memory address and are the same class. We can also say class1 == class2 .
In a JVM, classes are modeled in memory, but only a single place in memory is required to model a
specific class. There can be multiple instances, but they all use the same model. When we say
class1.equals( class2 ) , the class has to be the same model. I'll give you more insight: if these classes
(the one the application provides and the one we have registered) claim to be the same—same package
and same class name—but are not, then even before we get to the .equals() method, we will see an
exception. When we attempt to deserialize a Class based on the serialized object in hand, if it is not the
same as one we've already instantiated, then it looks like a square peg trying to fit in a round hole.
Specifically, an InvalidClassException is thrown. A JVM only has room for one name to class instance
image relationship. Try to introduce another, different class as the same name and the JVM will reject it.
Let me be subtle and say that you will probably find ways that this will need to be improved. One
obvious way to improve it would be to run our applications on a server, perhaps as web applications, so
 
Search WWH ::




Custom Search