Database Reference
In-Depth Information
Security Administrator User
Let's go ahead and start defining our security administrator. The security administrator is going to be a
separate non-person user; that is, an account and password that can be delegated to various people who
rotate into and out of the job responsibility. The security administrator will be doing tasks that would
typically be done by a DBA or even by SYS , but we are going to limit the privileges we give to the security
administrator to just those aspects related to application security.
First, as SYS we will create the user secadm and grant him the create_session_role , in one step.
Substitute a real password for “password” in this command:
GRANT create_session_role TO secadm IDENTIFIED BY password;
Caution Be sure to give a very complex password to this user; it will be powerful enough to be dangerous in
the wrong hands. This warning goes for the SYS and SYSTEM accounts as well.
Security Administrator Role
Next, we will create the security administrator role, secadm_role . It will be the role that is granted all the
privileges needed to do security administration. We can then grant this role to any user, but we will limit
it to just one user, secadm .
At the outset, I want to set some requirements regarding how and when this role can be used, so I
will not use the NOT IDENTIFIED keywords that we saw with create_session_role . Rather, I will have it be
identified (verified) by a procedure. You can see the name of the verification procedure,
sys.p_check_secadm_access in this command:
CREATE ROLE secadm_role IDENTIFIED USING sys.p_check_secadm_access;
A role that is identified by a procedure is called a secure application role.
Security Administration Role Verification
As I mentioned, all the privileges that the security administrator needs will be granted to secadm_role , so
we are going out of our way to protect it. The keywords IDENTIFIED USING sys.p_check_secadm_access
indicate that when a user attempts to acquire secadm_role , he will have to get it from the procedure
named p_check_secadm_access , which exists in the SYS schema.
A stored procedure (procedure) is a named block of Procedural Language/Structured Query
Language (PL/SQL) code that is stored and run (executed) on the Oracle database. Generally, a
procedure takes parameters and does work. It can also return information through its parameters. In
Oracle there are also stored functions (functions), which are very similar to procedures except that they
usually take values; do research or calculations; and then return a single value as the result. We will be
using both procedures and functions.
The specific procedure used for verifying secadm_role , p_check_secadm_access does not take any
parameters (arguments or values passed to the procedure for evaluation), and does not return any
results. Most procedures do take parameters, but they don't have to.
In the Listing 2-1, we are creating the procedure to be used for acquiring the security administrator
role. Note that the simple goal I have for this procedure is to require that the security administrator be
 
Search WWH ::




Custom Search