Administration of Security - Expert Oracle and Java Security - page 371

appears. Be sure to document this feature for other application security administrators who will be using
this screen to register applications. Might I suggest buying them a copy of this topic?
If the application uses the Login class we developed in this chapter, then creating a representative
class on Oracle is easy. The only change in this inner class from one application to another is the
package in which the Login class is located. We take advantage of that fact in this button. When this
button is selected, a new Java class is created on the Oracle database.
When the user selects the Register button, we do several things. For one thing, we insert the data
from the top three fields on the form into the appsec.v_application_registry view. Also, we add the
current Oracle user as an administrator for this specific application. That data goes into a new table
named appsec.t_application_admins . And third, we enter a value in a new table that associates entries
in the appsec.v_application_registry view with application inner class entries in the
appsec.v_app_conn_registry view. This new table is named appsec.t_app_class_id . We will discuss
these new tables later in this chapter.
There is only one concern when registering a new application. We actually change context from the
OJSAdmin application to that of the new application in order to communicate with Oracle database as
that application and enter the inner class in the appsec.v_app_conn_registry view. For that reason, the
Close button turns into an Exit button after the Register button has been pressed, and instead of
returning to OJSAdmin , the Exit button exits the JVM.
The Application Verification Administrator Role
In Chapter 11, we created a role named appver_admin . It is to that role that we delegated some
administrative tasks, chief among those being the task of executing the procedures and functions in the
appsec.appsec_admin_pkg package. Those procedures and functions include f_set_decrypt_conns ,
p_copy_app_conns , and the procedure we will introduce later in this chapter, p_create_template_class .
These are procedures that handle our stored Oracle connection string lists for various applications, and
they are due extra security measures.
In Chapter 11, we assigned the appver_admin role to a specific user that we have called osadmin in
our example code (probably you.) In this chapter, we are going to change that role to operate more like
one of our standard application roles, being set for persons who are allowed to proxy through an Oracle
application account. You might have caught a hint of this from Table 12-1 and Listing 12-5 where we
associated a new user, avadmin with the appver_admin role. We also saw how we can assign that proxy
user to people in our discussion of the Admin Users functional screen.
Previously, we have defined the appver_admin role on both orcl and apver instances, and we had
designated it to be NOT IDENTIFIED , and we granted the role to osadmin . Here we will revoke that grant
and alter the role to be identified by our secure application role procedure, appsec.p_check_role_access .
We do those tasks, shown in Listing 12-42, as SYS user on both the orcl and apver instances. At the same
time we will create the new proxy user, avadmin , who will set this role. And we grant the right to connect
through avadmin (proxy) to osadmin (you). Be sure to give a very strong password to the avadmin user. Also
shown in Listing 12-42, on the apver instance we will repeat an insert into
appsec.v_application_registry that we have already made on the orcl instance—setting up the
association of the avadmin user and the appver_admin role.
Listing 12-42. Application Verification Administrator
REVOKE appver_admin FROM osadmin;
ALTER ROLE appver_admin IDENTIFIED USING appsec.p_check_role_access;
GRANT create_session_role TO avadmin IDENTIFIED BY password;
ALTER USER osadmin GRANT CONNECT THROUGH avadmin;