Enhancing Security - Expert Oracle and Java Security - page 288

stmt.getBytes(1) ) );
Object currentConns = oins.readObject ();
Manage Connection Strings for Applications
We have already seen, and have been using the functionality to add and update connection strings in
our list, and to save them in Oracle database. Recall that those are two separate steps. The first step,
adding or updating connection strings in our list, happens on the client and only affects the list currently
being used by the client application. It is only when we save the list to Oracle database that we make the
new or replacement connection string available to all future application users.
In the same way, we will need to remove connection strings from the list. Again, we will make the
removal permanent by saving the list to Oracle database in a separate step.
Finally, we will want to be able to replicate the list of connection strings for use by a new version of
our application. This replication process must be application-specific, so a poser application can't grab
our list of connection strings for her illicit use.
Be forewarned that anyone who gains access to the application security, appsec user has access to
copy connection strings from one application to another. Fortunately, we have taken care of that issue
by making the f_mask and f_unmask functions both application and version specific. Another application
may lay hold of our list of connection strings, but they won't be able to decrypt them. That means,
though, that when we replicate our list of connection strings to a new version of the application, we will
have to f_unmask them with the old version and f_mask them with the new version.
Create an Application Administrative User
Up to this point, we have described an application user named OSUSER whom I suggested was probably
you (your OS user ID). This is an ordinary application user who was granted access to see sensitive data
in the HR schema by way of having been granted CONNECT THROUGH appusr .
Now it has come time for us to differentiate between regular application users and administrative
application users. We need a second user, whom I am going to call OSADMIN . The difference between
these users will come in the next section through a single role grant. The reason for that additional role
will be to manage the update of connection string lists for applications on the Oracle database.
For now, let's create a second application user. First of all, you will need to have an additional OS
user account named osadmin in our example. As a Windows administrative user, you can create that
account through the Control Panel/User Accounts utility. Once that exists, run the commands in Listing
11-25 to create the OSADMIN user (substitute the OS user ID of the OS user you just created) and grant him
the same access to sensitive data in the HR schema that we have given to OSUSER . We do this so we can
test just the difference that is made by the new administrative role.
Listing 11-25. Create the OSADMIN Oracle User
CREATE USER osadmin IDENTIFIED EXTERNALLY;
GRANT create_session_role TO osadmin;
ALTER USER osadmin GRANT CONNECT THROUGH appusr ;
INSERT INTO hr.employees
(EMPLOYEE_ID, FIRST_NAME, LAST_NAME, EMAIL , PHONE_NUMBER, HIRE_DATE,
JOB_ID, SALARY, COMMISSION_PCT, MANAGER_ID, DEPARTMENT_ID)
VALUES
( EMPLOYEES_SEQ.NEXTVAL , 'First', 'Last', ' OSADMIN.MAIL ',