Database Reference
In-Depth Information
Get It from a Second Source/Server
Well, if we don't want the password in our code, and we can't get it from Oracle database (without a
password), perhaps we need to store it and retrieve it from a secondary server. At the end of the day, I'm
going to promote the idea of just sticking with Oracle database as our server. Supporting and securing
one server well beats distributing your security roles across many platforms, primarily because it's easier
to account for and easier to keep an eye on.
From a Port Server
Where I work, we have a port server (a multithreaded application that opens a
ServerSocket
and listens
on a network port) that performs some of the same activities as the
appver
structures we described in
Chapter 10 and returns connection strings. That was a brilliant solution, and one I can't take credit for—
my associate conceived it. That server does just what it is intended to do, and delivers the connection
strings securely. It was homegrown before J2EE.
We could implement some additional security in our port server, like SSO and two-factor
authentication, things that are not there at present. However, the primary faults of this server are
twofold: first, there is less-than-Oracle-quality security of the storage of the connection strings. Now,
instead of an Oracle account to get access, there is an operating system account or group that gives
access. And second, managing another kind of server with its unique configuration and code means
potentially greater support requirements and unique knowledge.
From RMI
Remote Method Invocation (RMI) is a system for separating Java functionality in half. Some Java code
runs on the client, and some on the RMI Server. Using RMI, you could retrieve your connection strings
from a Java RMI service.
This approach has very much the same strengths and weaknesses as the port server described
previously. Its one advantage is that it is an industry-standard approach rather than a home-grown port
server, so perhaps there is less concern with unique requirements for support.
From a URLClassLoader
If you have ever run an Applet in a browser, you have seen the
URLClassLoader
in action. With this
approach, some of your application code, perhaps that which retrieves and delivers your connection
strings, is not stored on the client computer. This is a separation of code, but not a separation of
processing. When needed, the local application pulls down jar files or class files from an HTTP (web)
server and runs the code in those files. Your application is running stand-alone on the client computer,
and provides no server-side authentication. Additionally, if an application can read the files from a URL,
so can any other web client on the local machine.
Briefly, if we were running in a browser, we might have server-side authentication. There can be
realm authentication from a browser to certain document/application realms, which generally means
another username/password prompt to access the URL. Or in a browser, there might also be SSO if the
web page or server directs the browser to authenticate the logged-in user to active directory (or similar)
before returning the jar file (still talking about the URLClassLoader). But in the present discussion, let's
stick to client applications.
Perhaps we could modify the standard behavior of the
URLClassLoader
and read code from a secure
repository, and hence get our connection strings securely. Well, we're talking about pretty much a
