4 Managing User Privileges

4.5.2.1 Step 1: Create a Security Administrator Account

For greater security, you should apply separation of duty concepts when you assign responsibilities to the system administrators on your staff. For the examples used in this guide, you will create and use a security administrator account called sec_admin.

To create the sec_admin security administrator account:

1. Start Database Control.

   See Oracle Database 2 Day DBA for instructions about how to start Database Control.

2. Enter an administrator user name (for example, SYSTEM) and password, and then click Login.

   The Database Home page appears.

3. Click Server to display the Server subpage.

4. Under Security, select Users.

   The Users page appears.

5. Click Create.

   The Create User page appears.

6. Enter the following information:

   • Name: sec_admin

   • Profile: Default

   • Authentication: Password

   • Enter Password and Confirm Password: fussy2all

   • Default Tablespace: SYSTEM

   • Temporary Tablespace: TEMP

   • Status: Unlocked

7. Click System Privileges to display the System Privileges subpage.

8. Click Edit List.

   The Modify System Privileges page appears.

9. In the Available System Privileges list, select the following privileges and then click Move to move each one to the Selected System Privileges list. (Hold down the Control key to select multiple privileges.)

   • CREATE PROCEDURE

   • CREATE ROLE

   • CREATE SESSION

   • DROP ANY PROCEDURE

   • DROP ANY ROLE

   • SELECT ANY DICTIONARY

10. Click OK.

11. Under Admin Option, do not select the check boxes.

12. Click OK.

4.5.2.2 Step 2: Create User Accounts for This Example

Matthew and Winston both are sample employees in the HR.EMPLOYEES schema, which provides columns for the manager ID and e-mail address of the employees, among other information. You must create user accounts for these two employees so that they can later test the secure application role.

To create the user accounts:

1. In Database Control, select the Database Instance link to display the Database Home page.

   If you are not logged in to Database Control, see Oracle Database 2 Day DBA for instructions about how to start Database Control. In the Login page, enter an administrator user name (for example, SYSTEM) and password, and then click Login.

2. Click Server to display the Server subpage.

3. Under Security, select Users.

   The Users page appears.

4. Click Create.

   The Create User page appears.

5. Enter the following information:

   • Name: mweiss (to create the user account for Matthew Weiss)

   • Profile: DEFAULT

   • Authentication: Password

   • Enter Password and Confirm Password: mw2work_now

   • Default Tablespace: USERS

   • Temporary Tablespace: TEMP

   • Status: Unlocked

6. Click System Privileges to display the System Privileges subpage.

7. Click Edit List.

   The Modify System Privileges page appears.

8. In the Available System Privileges lists, select the CREATE SESSION privilege, and then click Move to move it to the Selected System Privileges list.

9. Click OK.

   The Create User page appears, with CREATE SESSION listed as the system privilege for user mweiss.

10. Ensure that the Admin Option for CREATE SESSION is not selected, and then click OK.

    The Users page appears.

11. Select MWEISS from the list of users, and then from the Actions list, select Create Like. Then, click Go.

12. In the Create User page, enter the following information to create the user account for Winston, which will be almost identical to the user account for Matthew:

    • Name: wtaylor

    • Enter Password and Confirm Password: wt4today_always

13. Click OK.

    You do not need to grant wtaylor the CREATE SESSION privilege, because the Create Like action has done of this for you.

14. Exit Database Control.

Now both Matthew Weiss and Winston Taylor have user accounts that have identical privileges.

4.5.2.3 Step 3: Create the Secure Application Role

Now, you are ready to create the employee_role secure application role. To do so, you need to log on as the security administrator sec_admin. "Step 1: Create a Security Administrator Account" explains how to create the sec_admin account.

To create the secure application role:

1. Start SQL*Plus and log on as the security administrator sec_admin.

   SQLPLUS sec_admin
   Enter password: fussy2all
   

   SQL*Plus starts, connects to the default database, and then displays a prompt.

   SQL> 
   

   For detailed information about starting SQL*Plus, see Oracle Database 2 Day DBA.

2. Create the following secure application role:

   CREATE ROLE employee_role IDENTIFIED USING sec_roles;
   

   The IDENTIFIED USING clause sets the role to be enabled (or disabled) only within the associated PL/SQL package, in this case, sec_roles. At this stage, the sec_roles PL/SQL package does not need to exist.

3. Connect as user OE.

   CONNECT oe
   Enter password: password
   

   If you receive an error message saying that OE is locked, then you can unlock the OE account and reset its password by entering the following statements. The password ready2go is an example, but you can enter any password that is secure, according to the password guidelines described in "Requirements for Creating Passwords".

   CONNECT system
   Enter password: sys_password
   ALTER USER OE ACCOUNT UNLOCK IDENTIFIED BY ready2go; 
   CONNECT oe
   Enter password: ready2go
   

4. Enter the following statement to grant the EMPLOYEE_ROLE role SELECT privileges on the OE.ORDERS table.

   GRANT SELECT ON oe.orders TO employee_role;
   

   Do not grant the role directly to the user. The PL/SQL package will do that for you, assuming the user passes its security policies. If your site requires that you directly grant users the role, then you must disable the role for that user. This is because the role needs to be initially disabled before the security policies in the package can begin performing their checks. For example, to disable the role for user wsmith (assuming wsmith was granted the role in the first place), enter the following statement:

   ALTER USER wsmith DEFAULT ROLE NONE;
   

4.5.2.4 Step 4: Create a Lookup Table

You are almost ready to create the procedure that determines who is granted the employee_role role. The procedure will grant the employee_role only to managers who report to Steven King, whose employee ID is 100. This information is located in the HR.EMPLOYEES table. However, you should not use that table in this procedure, because it contains sensitive data such as salary information, and for it to be used, everyone will need access to it. To get around this problem, you can create a lookup table that only contains the employee names, employee IDs, and their manager IDs.

To create the HR.HR_VERIFY lookup table:

1. In SQL*Plus, connect as user HR.

   CONNECT hr
   Enter password: password
   

   If you receive an error message saying that HR is locked, then you can unlock the account and reset its password by entering the following statements. Enter any password that is secure, according to the password guidelines described in "Requirements for Creating Passwords".

   CONNECT SYSTEM
   Enter password: sys_password
   ALTER USER HR ACCOUNT UNLOCK IDENTIFIED BY password;
   CONNECT hr
   Enter password: password
   

2. Enter the following CREATE TABLE SQL statement to create the lookup table:

   CREATE table hr_verify AS 
   SELECT employee_id, first_name, last_name, email, manager_id 
   FROM employees;
   /
   

3. Grant EXECUTE privileges for this table to mweiss and wtaylor by entering the following SQL statements:

   GRANT SELECT ON hr.hr_verify TO mweiss;
   GRANT SELECT ON hr.hr_verify TO wtaylor;
   GRANT SELECT ON hr.hr_verify TO sec_admin;
   

4.5.2.5 Step 5: Create the PL/SQL Package to Set the Secure Application Role

Now, you are ready to create the secure application role procedure. In most cases, you create a package to hold the procedure, but because this is a simple example that requires only one secure application role test (as defined in the procedure), you will create a procedure by itself. If you want to have a series of procedures to test for the role, create them in a package.

A PL/SQL package defines a simple, clear interface to a set of related procedures and types that can be accessed by SQL statements. Packages also make code more reusable and easier to maintain. The advantage here for secure application roles is that you can create a group of security policies that, used together, present a solid security strategy designed to protect your applications. For users (or potential intruders) who fail the security policies, you can add auditing checks to the package to record the failure.

To create the secure application role procedure:

1. In SQL*Plus, connect as user sec_admin, whose password is fussy2all.

   CONNECT sec_admin
   Enter password: fussy2all
   

2. Enter the following CREATE PROCEDURE statement to create the secure application role procedure:

   SQL> CREATE OR REPLACE procedure sec_roles AUTHID CURRENT_USER
     2 AS
     3 v_user varchar2(50);
     4 v_manager_id number :=1;
     5  BEGIN
     6   v_user := lower((sys_context ('userenv','session_user')));
     7   SELECT manager_id 
     8      INTO v_manager_id FROM hr.hr_verify WHERE lower(email)=v_user;
     9    IF v_manager_id = 100
    10     THEN
    11     DBMS_SESSION.SET_ROLE('employee_role');
    12     ELSE NULL;
    13    END IF;
    14   EXCEPTION
    15   WHEN NO_DATA_FOUND THEN v_manager_id:=0;
    16  DBMS_OUTPUT.PUT_LINE(v_manager_id);
    17 END;
    18 /
   

   In this example:

   • Line 1: Appends the AUTHID CURRENT_USER clause to the CREATE PROCEDURE statement, which creates the procedure using invoker's rights. The AUTHID CURRENT_USER clause creates the package using invoker's rights, using the privileges of the current user.

     You must create the package using invoker's rights for the package to work. Invoker's rights allow the user to have EXECUTE privileges on all objects that the package accesses.

     Roles that are enabled inside an invoker's right procedure remain in effect even after the procedure exits, but after the user exits the session, he or she no longer has the privileges associated with the secure application role. In this case, you can have a dedicated procedure that enables the role for the rest of the session.

     Because users cannot change the security domain inside definer's rights procedures, secure application roles can only be enabled inside invoker's rights procedures.

     See "About Secure Application Roles" for information about the importance of creating the procedure using invoker's rights.

   • Line3: Declares the v_user variable, which will store the user session information.

   • Line 4: Declares the v_manager_id variable, which will store the manager's ID of the v_user user.

   • Line 6: Retrieves the user session information for the user logging on, in this case, Matthew or Winston. To retrieve user session information, use the SYS_CONTEXT SQL function with the USERENV namespace attributes ('userenv', session_attribute), and the write this information to the v_user variable.

     The information returned by this function indicates the way in which the user was authenticated, the IP address of the client, and whether the user connected through a proxy. See Oracle Database SQL Language Reference for more information about SYS_CONTEXT.

   • Lines 7–8: Get the manager's ID of the current user. The SELECT statement copies the manager ID into the v_manager_id variable, and then checking the HR.HR_VERIFY table for the manager ID of the current user.

   • Lines 9–13: Use an IF condition to test whether or not the user should be granted the sec_roles role. In this case, the test condition is whether the user reports to Matthew's manager, Steven King, whose employee number is 100. If the user reports to King, as Matthew does, then the secure application role is granted to the user. Otherwise, the role is not granted.

     The result is that the secure application role will grant Matthew Weiss the role because he is a direct report of Steven King, but will deny the role to Winston, because he is not a direct report of Steven King.

   • Lines 10–12: Within the IF condition, the THEN condition grants the role by using DBMS_SESSION.SET_ROLE. Otherwise, its ELSE condition denies the grant.

   • Lines 14–15: Use an EXCEPTION statement to set v_manager_id to 0 if no data is found.

   • Line 16: Copies the manager's ID into a buffer so that it is readily available.

4.5.2.6 Step 6: Grant EXECUTE Privileges for the Procedure to Matthew and Winston

At this stage, Matthew and Winston can try to access the OE.ORDERS table, but they are not able to, even if they should. The next step is to grant them EXECUTE privileges on the sec_roles procedure, so that the sec_roles procedure can execute, and then grant or deny access, when they try to select from the OE.ORDERS table.

To grant EXECUTE privileges for the sec_roles procedure:

• In SQL*Plus, as user sec_admin, enter the following GRANT SQL statements:

  GRANT EXECUTE ON sec_admin.sec_roles TO mweiss;
  GRANT EXECUTE ON sec_admin.sec_roles TO wtaylor;
  

4.5.2.7 Step 7: Test the EMPLOYEE_ROLE Secure Application Role

You are ready to test the employee_role secure application role by logging on as Matthew and Winston and trying to access the OE.ORDERS table. When Matthew and Winston log on, and before they issue a SELECT statement on the OE.ORDERS table, the sec_roles procedure must be executed for the role verification to take place.

To test the employee_role secure application role, as user MWEISS:

1. Connect as user mweiss, whose password is mw2work_now.

   CONNECT mweiss
   Enter password: mw2work_now
   

2. Enter the following SQL statement to run the sec_roles procedure:

   EXEC sec_admin.sec_roles;
   

   This statement executes the sec_roles procedure for the current session.

3. Perform the following SELECT statement on the OE.ORDERS table:

   SELECT count(*) FROM oe.orders;
   

   Matthew has access to the OE.ORDERS table:

   COUNT(*)
   ----------
          105
   

Now, Winston will try to access the secure application.

To test the employee_role secure application role as user WTAYLOR:

1. In SQL*Plus, connect as user wtaylor, whose password is wt4today_always.

   CONNECT wtaylor
   Enter password: wt4today_always
   

2. Enter the following SQL statement to run the sec_roles procedure:

   EXEC sec_admin.sec_roles;
   

   This statement executes the sec_roles procedure for the current session.

3. Perform the following SELECT statement on the OE.ORDERS table:

   SELECT count(*) FROM oe.orders;
   

   Because Winston does not report directly to Steven King, he does not have access to the OE.ORDERS table. He will never learn the true number of orders in the ORDERS table, at least not by performing a SELECT statement on it.

   ERROR at line 1:
   ORA-00942: table or view does not exist
   

4.5.2.8 Step 8: Optionally, Remove the Components for This Example

Remove the components that you created for this example.

To remove the components:

1. In SQL*Plus, connect as SYSTEM.

   CONNECT SYSTEM
   Enter password: password
   

2. As user SYSTEM, enter the following DROP statements:

   DROP USER mweiss CASCADE;
   DROP USER wtaylor CASCADE;
   

   Do not drop user sec_admin. You will need this user for other examples in this guide.

3. In SQL*Plus, connect as user sec_admin.

   CONNECT sec_admin
   Enter password: fussy2all
   

4. Enter the following DROP SQL statements:

   DROP ROLE employee_role;
   DROP PROCEDURE sec_roles;
   

5. Connect as user HR, and then drop the HR_VERIFY table.

   CONNECT HR
   Enter password: hr
   DROP TABLE HR_VERIFY;
   

6. Exit SQL*Plus.

   EXIT