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

INSERT INTO appsec.v_app_class_id
(CLASS_NAME, APPLICATION_ID) VALUES
('orajavsec.Login$InnerRevLvlClass','OJSADMIN');

COMMIT;
I mentioned in the introduction to this section that we insert data into these tables when we register
new applications. We enter the current Oracle user as an administrator for the new application, inserting
a record in the appsec.v_application_admins view. Also we enter the application class to application ID
relationship by an insert into the appsec.v_app_class_id view. The insert statements for our existing
applications are shown in Listing 12-47.

Security Table Access Analysis
We are going to take a look at how we get to tables of data in the appsec schema and how we use the
data. This will help us define who should get access and what access grants we need to make to each
Oracle user.
First of all, we need to understand that most of the access to data in the appsec schema is
accomplished by procedures, functions, and packages in the appsec schema, so no additional grants to
the data are required. We have several packages that segregate procedures and functions into these
groups:

APP_SEC_PKG : Procedures and functions that applications need to access. We grant
execute
on this package to application schemas, like HR . Those application schemas have
sensitive data access procedures that call on app_sec_pkg .

•

APPSEC_ONLY_PKG : Procedures and functions that handle the inner workings of our
Oracle and Java Security activities. No grants are made to this package.

•

• APPSEC_PUBLIC_PKG : Procedures that need to be accessible by all Oracle users. This
package is granted execute to PUBLIC. Generally, this provides a jumping-off
point, part of the application verification process, where users are proxying
through appver , but have no roles except the create_session_role . One particular
procedure in this package is the p_get_app_conns procedure, by which a user may
acquire the list of connection strings for the application they are using after SSO,
two-factor authentication and key exchange. Our plan is to secure SELECTs on
this particular procedure so that users can only select applications that they have
been granted.
• APPSEC_ADMIN_PKG : Procedures and functions that are only available to the
application security administrators, those who can proxy through the avadmin user
and acquire the appver_admin role. The execute privilege is granted to
appver_admin for this package.
We also have a group of procedures and functions that do not reside in packages. All those
structures have one of two aspects about them that keep them from working in a package: they either
execute with the current user privileges, AUTHID CURRENT_USER , or they are obfuscated by the Oracle wrap
utility.
We also support some direct access to the application security data from outside the structures of
the appsec schema. In particular, we have queries in this security administration interface application
that select data from three of the views: v_app_class_id , v_application_registry and