Database Reference
In-Depth Information
Listing 12-15. Script to Associate Application Users to Roles
INSERT INTO appsec.v_application_registry
(application_id, app_user, app_role) VALUES
('OJSADMIN','APPUSR','HRVIEW_ROLE');
INSERT INTO appsec.v_application_registry
(application_id, app_user, app_role) VALUES
('OJSADMIN','OJSAADM','OJS_ADM_ADMIN');
INSERT INTO appsec.v_application_registry
(application_id, app_user, app_role) VALUES
('OJSADMIN','AVADMIN','APPVER_ADMIN');
Note This script can be found in the file Chapter12/OrclAppSec.sql
During the call to the Login class associated with the OJSAdmin application in Listing 12-6, we
designated OJSADMIN as the application ID. For that application ID and the specific application inner
class, ojsadmin.Login$InnerRevLvlClass , there is (or will be) a list of connection strings stored in the
v_app_conn_registry view. It is this list that we got from the processing in Login . Using connection
strings from the list, we can connect as the different users required for the various security
administration functions. The current function, Add/Modify User, requires that we have a connection to
orcl as appusr with the hrview_role .
There is a lot of code in AddUser to make the GUI operate like it should, depending on user
selections and entries. I will leave most of those details for you to explore and discover in the code, but I
will mention a few important aspects. For instance, if the user is creating a new employee, they cannot
enter data for the OS user identity until they have saved the employee and selected her from the drop-
down combo box list. In the first constructor in Listing 12-13, we added a ButtonGroup and added our
two radio buttons, existingEmpRadioButton and newEmpRadioButton as members. The button group
assures that only one of the radio buttons is selected at a time. We also assure that personal data that
was previously shown in the screen is blanked out when creating a new employee and/or user. Keeping
track of what all is available and what becomes invalid as users click around on a GUI interface makes
the programmer into a “bean counter” accountant.
Initialize the Data Selection Components
From the default constructor, shown second in Listing 12-13, after getting a new Oracle connection and
resetting our encryption keys, we call a method to populate the drop-down combo box lists, dataInit() .
The dataInit() method in Listing 12-16 has several static Oracle queries to non-sensitive views in the HR
schema. Although the data is non-sensitive, we have not granted PUBLIC access to the data; rather, we
granted access to the hrview_role , which we acquire and use in this Add/Modify User functional screen.
The applicationID is OJSADMIN and the application user is appusr , so the corresponding role that we
acquire from v_application_registry is the hrview_role according to Table 12-1 and Listing 12-15.
Using that Oracle role, we can select the list of employees from the public view,
hr.v_employees_public . We created that view in Chapter 2, in the Chapter2/HR.sql script file. We order
 
Search WWH ::




Custom Search