Global Roles and Enterprise Roles

With the introduction of Enterprise User Security (EUS), Oracle added another role type to the database. Global roles were created to allow the users defined in the LDAP server to have not only centralized authentication, but also centralized authorization. Global roles are the name given when talking about this from the database’s perspective. That is, the database will create roles that are called global roles.

The roles, when viewed from the LDAP server, are known as enterprise roles. The enterprise roles act as a container for the named global roles for each and every database. In the LDAP server, there is a mapping between the enterprise roles and the global roles for each database within the domain.

When an Enterprise User logs in, either directly or via proxy authentication, the database will check the mapping in the LDAP server for its global roles. If the user’s enterprise role(s) have global roles for the database, then the database will automatically enable the global roles.

This allows users utilizing the shared schema design to maintain different object and system privileges. Normally, since the schema is shared, any privileges granted directly to the schema would be available to all users that are mapped to that schema. This includes all database roles except for global roles. With this new capability, two users with different enterprise roles, which contain different global roles for the same database, will actually have the different global roles when they log in, even though they are in the same schema.

Creating and Assigning Global and Enterprise Roles

While the global role is created in the database and privileges are assigned to the role, the role cannot be granted to any database users or any other database roles. To create the role, add the clause “identified globally” after the role name:

sec_mgr@KNOX10g> -- Create a global role sec_mgr@KNOX10g> CREATE ROLE app_a_global IDENTIFIED GLOBALLY; Role created. sec_mgr@KNOX10g> -- Grant privileges to role as normally done sec_mgr@KNOX10g> GRANT SELECT ON data_owner.t TO app_a_global; Grant succeeded. 

Note that you can’t assign the role to any users or any other database roles:

sec_mgr@KNOX10g> -- Cannot grant role to users sec_mgr@KNOX10g> GRANT app_a_global TO scott; GRANT app_a_global TO scott * ERROR at line 1: ORA-28021: cannot grant global roles sec_mgr@KNOX10g> -- Cannot grant global role to other roles sec_mgr@KNOX10g> GRANT app_a_global TO DBA; GRANT app_a_global TO DBA * ERROR at line 1: ORA-28021: cannot grant global roles

To add the role to the user, you have to use the Enterprise Security Manager. To assign the roles to a user, you have to first create an enterprise role. The enterprise role can be any unique name within the enterprise domain. Next, add the global roles for all your databases to the enterprise role. In Figure 7-5, the enterprise role APPA_EROLE is mapped to several global roles in several databases. The APP_A_GLOBAL role is highlighted for the knox10g database.

Figure 7-5: The Enterprise Security Manager is the tool that allows for the management of enterprise role, global roles, and their mappings to Enterprise Users.

Next, grant the enterprise role to the user. Clicking on the Users tab in the Enterprise Security Manager brings up the screen that allows the administrator to assign the enterprise role to users. Figure 7-6 shows the Enterprise User Knox has been granted the APPA_EROLE. Underneath the covers, the Enterprise Security Manager has created the role mappings for the databases and the user.

Figure 7-6: Role authorizations are assigned by the Enterprise Security Manager.

In the following example, the user Knox logs on. This user maps to a shared schema KNOX_DB. The enterprise role APPA_EROLE was granted to Knox. When Knox logs on, the database reads the enterprise role/global role mapping and automatically enables the global role for the user.

sec_mgr@KNOX10g> conn knox/oracle10g Connected. knox_db@KNOX10g> COL name FORMAT a40 knox_db@KNOX10g> -- Show identity for enterprise user knox_db@KNOX10g> SELECT SYS_CONTEXT ('userenv', 'external_name') name   2    FROM DUAL; NAME ---------------------------------------- cn=Knox,cn=users,dc=iac,dc=oracle,dc=com knox_db@KNOX10g> -- Show roles. knox_db@KNOX10g> SELECT ROLE FROM session_roles; ROLE ------------------------------ APP_A_GLOBAL

Combining Standard and Global/Enterprise Roles

One of the difficulties with enterprise and global roles is reconciling which users have which privileges when the privileges are granted to global roles. Database privileges granted to global roles cannot be seen from the LDAP server (or the Enterprise Security Manager tool). Likewise, the database only knows of the shared schemas; the actual end users are not known to the database because they are centrally managed in the LDAP server. You have to perform a two-step process. First, determine the privileges that have been granted to the global roles. Next, consult with the LDAP server, which will list all the enterprise roles for the user. The administrator has to then look up each enterprise role to determine which global roles are applicable. It’s even hard to describe!

Normally, a code snippet would be provided that would query the LDAP server for the specific user and list all their global roles. Unfortunately, the implementation of enterprise roles is Oracle proprietary and subject to change.

When using the shared schema design, it’s a good idea to also use the global and enterprise roles. However, not all privileges have to be granted to global roles. For privileges that are required for all users of a shared schema, the privileges can be granted to the shared schema itself, either directly or via a standard database role. This will make the task of figuring out who has access to what a little easier.