Database Reference
In-Depth Information
C H A P T E R 10
Application Authorization
Every Oracle application connects to one or more Oracle database instance, perhaps as one or more
user. We have already seen how we can accomplish this with security and encryption for one application
at a time. Our first application attached as the appusr account and had access to data in the HR schema
via the hr_view role.
For that application, and any similar one, the developer will develop a procedure for a secure
application role, like our p_check_hrview_access . But for all our security, there is one aspect that we
haven't addressed: developers are still required to hard-code application user passwords into their code
(or find another mechanism.) What if we provide a secure password store for them, one that is not as
susceptible to imposter applications as other solutions?
In this chapter, we are going to build a dynamic Oracle procedure for use in validating all secure
application roles. Individual developers will not have to provide such procedures for their applications.
Instead, they will provide a list of three unique items related to their secure application role: the
application ID (name), the application user, and the secure application role name. We will store those
elements in a table. Then we will provide the dynamic procedure for all secure application roles, and
organize our code around it.
Next we will build out some of our other tables to handle multiple applications per user, keeping
application-specific security data for users separate from security data for that user for other
applications.
We will also have each application send us a representative piece of code—an application-specific
class, provided as an object represented by a byte array. (The details of that will become clearer.) By
examining that object, we will know what application is requesting services, and in return we will
provide that application with a list of the specific connection strings needed by the application. Of
course, all of this is done with encryption and security in mind.
We will store the application connection strings in an Oracle table. Some procedures, functions, and
Java code are required to accomplish this, and a bit more code will be required to update the data once
stored. We will also support multiple versions of an application.
We are storing all the data in Oracle database, and using the security of Oracle database, but recall
that we do not have our application Oracle connections until after we have passed the security checks.
This is a quandary along the lines of, “which came first, the chicken or the egg?” Or in our case, “which
came first, an Oracle connection or our list of Oracle connection strings (passwords)?” The answer is that
we need a connection to Oracle database first, so we will use an alternate Oracle application verification,
the appver user, to provide the necessary initial connection for all applications. The appver user will be a
hardened user with as many restrictions as we can muster. His sole purpose is to guard and provide
application-specific Oracle connection strings.
Because we will want to muster all our security forces before distributing connection strings, we will
have appver determine the specific application, as described previously. He will also provide the single
sign on (SSO) and two-factor Authentication we have discussed in earlier chapters. And he will establish
an initial set of encryption keys for use in distributing and decrypting the connection strings.
 
Search WWH ::




Custom Search