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

The Copy to New Version screen is very simple. It has a text field to enter the previous version
number, from which the connection strings will be copied, and a button labeled Copy Existing Conn
Strings. When that button is selected, the result is a call to the OracleJavaSecure.copyAppConnections()
method, passing the user-entered previous version number.
Limiting Certain Administrators to Certain Applications
Before I end this chapter, let me elaborate on something I have alluded to several times: limiting which
applications an administrator may manage. You will recall in our discussion of the Register New
Application screen, we created a new table to designate an administrator for the new application,
appsec.t_application_admins . We have not done anything with that table yet, except maintain the data
in it.
You may recall from Listing 12-48 that we limited certain privileges on that table of administrators
to just a single user, osadmin . This administrator of administrators job could be extended to more
individuals, but we didn't create a role to handle this. That might be a good future improvement. We do
not limit the insert privilege, because we are inserting the current session user as an initial administrator
for the application from the Register New Application screen.
Virtual Private Database
How will we use this table of application administrators? One way is to use a feature of the Oracle
database that goes by many names. The feature is implemented in a database package named DBMS_RLS,
which stands for “Row Level Security.” I suppose that might be the best name, but this feature is more
often referred to as “Virtual Private Database” (VPD), as in the Oracle Database Security Guide
document. You might also see it called “Dynamic Where Clause” or “Fine-Grained Access Control,”
depending on how it is being used.
It amounts to a dynamic where clause being applied to queries and execute commands on a table,
and it is enforced by a database security policy. The main benefits of this feature are that it is
transparently applied to all specified user interactions with the data table, and there is no way around
the policy for the user.
As an example, let's say I define a policy that says every time a user deals with the HR.EMPLOYEES
table, we will apply the dynamic where clause, “ where employee_id = this_employee_id ” assuming we
have already calculated this_employee_id . Because this policy is applied to the table, even if the
employee with ID 300 is selecting or updating the data through a view or procedure (as AUTHID
CURRENT_USER) , they still can only deal with their own record, for their employee_id, 300 .
 Note Procedures that operate with schema privileges, not AUTHID CURRENT_USER will be restricted to data
available to the schema user, not the current user. However, if the VPD policy is restricting access by a different
aspect of the user's identity, such as a session context parameter, then a user's access through these procedures
is also restricted by the VPD policy.
 Note If you are connected as SYS user or the schema user who owns the table, VPD policies do not apply to
your access to the table. You see it all, unless the VPD function depends on a session context parameter.