About Real Application Security Session Privilege Scoping Through ACL
This section describes session privilege scoping through an ACL allowing per principal session privilege grants through an ACL set on the principal, where the principal can be either an application user or a dynamic role.
In Oracle Database 12c Release 1 (12.1), Real Application Security session privileges are granted through GRANT_SYSTEM_PRIVILEGE procedure or revoked through REVOKE_SYSTEM_PRIVILEGE procedure in the XS_ADMIN_UTIL package. These grants are applicable system wide and allow the grantee to exercise the grants for session operations on any Real Application Security principal. This is implemented using a seeded system ACL – SESSIONACL. All session privilege checks are done in this ACL. For a database running multiple applications with multiple user communities this approach becomes cumbersome to administer Real Application Security session administration appropriately.
Session privilege scoping addresses two issues. The first issue is who can create, attach, detach, or destroy a user’s session. The second issue is who can enable a dynamic role for a user session. Because a dynamic role can never be granted and can only be dynamically enabled, session privilege scoping through an ACL is needed. Because regular roles are granted to application users, an ACL is not needed on them.
Beginning with Oracle Database 12c Release 2 (12.2), Real Application Security supports session privilege scoping through an ACL. This feature allows per principal session privilege grants through an ACL set on the principal. The ACL containing the session privilege grant can be set on a regular Real Application Security application user or a dynamic role, but it cannot be set on a regular Real Application Security role or external principal. Because Real Application Security session scoping can be enforced per the ACL set on the application user or dynamic role involved in a session operation, you can more finely restrict session operations to specific user communities. For example, you can set up a session operation for a separate user community that can be managed by separate session managers (dispatchers), so users belonging to the same user community will have the same ACL set on them. In addition, enabling and disabling of a dynamic role can be restricted to appropriate dispatchers with the addition of a new privilege ENABLE_DYNAMIC_ROLE to restrict enablement and disablement of dynamic roles. This privilege is enforced even for enabling existing session scope dynamic roles from previous attach. With these features, the Real Application Security session administrator can provide a scoping for session privileges that allows a user to create or attach or modify sessions for one Real Application Security user community or a group of Real Application Security user communities for which it has been granted privilege.
The ACL can be set on the principal at creation time using the Real Application Security least system privilege PROVISION, which can create, modify, or drop application users and application roles. In addition, you can also use the CREATE_USER procedure and CREATE_DYNAMIC_ROLE procedure and this requires the caller to have ALTER USER or ALTER ROLE privilege depending on the principal being created; or the ACL can be created after principal creation using the SET_ACL procedure, which requires the caller to have the same privilege as previously mentioned depending on whether the principal is an application user or dynamic role. Both the application user or dynamic role and ACL must already exist before setting the ACL using the SET_ACL procedure and the ACL must have been created in the SYS schema.
Session operations require either specific session privileges to be granted to the session manager depending on the session operation by either a system-wide ACL or an ACL attached to the affected user or role. The ADMINISTER_SESSION privilege aggregates all specific session privileges. Like all session privileges, this privilege can be granted to the session manager by either a system-wide ACL or principal specific ACL. The use of new privileges is audited like other system privileges. An ACL set on a user or dynamic role overrides the system-wide ACL.
The DBA_XS_USERS and DBA_XS_DYNAMIC_ROLES views are enhanced to show an additional column for the ACL that is set on the Real Application Security application user or dynamic role.
System level session privilege grants can coexist with the principal specific ACL, but the principal specific ACL grants have precedence. This precedence is important as Real Application Security principal specific ACLs can have negative grants. Note that the negative grant can only appear in principal specific ACLs not for the system ACL.
The following table describes the behavior of a session privilege check comparing the principal specific ACL (column 1) with the System ACL (column 2) and showing the result of the session privilege check (column 3) as being either True or False. For example, when the checked privilege is neither granted or denied in a principal specific ACL, then the System ACL is checked for the privilege.
Session Privilege Checking
| Principal Specific ACL | System ACL | Session Privilege Check Result |
|---|---|---|
| Grant | Deny, grant, or not specified | True |
| Deny | Deny, grant, or not specified | False |
| Not specified or ACL does not exist | Grant | True |
| Not specified or ACL does not exist | Not specified. | False |
Enforcing Session Privilege According to the ACL Set on the Principal
Session privilege is enforced according to the ACL set on the Real Application Security application user in the session operation. A privilege to enable a dynamic role is enforced according to the ACL set on the dynamic role. For example, a create session operation requires the caller to have the CREATE_SESSION privilege in the ACL set on the Real Application Security application user. Similarly, the attach operation with dynamic role requires the ENABLE_DYNAMIC_ROLES privilege in the ACLs set on the dynamic roles. Any existing system level session privilege grants as mentioned previously can still coexist, but the principal specific ACL grants gets precedence.
Privilege check is first done in the ACL associated with the principal (if at all there are such settings). If the ACL check succeeds the operation will go through. If the check finds deny, the operation fails with insufficient privilege error. If neither grant nor deny is found, the check is done in system ACL associated with SESSION_SC security class and operation fails or succeeds based on this privilege check result.
The following table lists Real Application Security session operations and the required session privileges to perform that operation. This information is useful for creating ACLs on principals for specific session operations. Note that the ADMINISTER_SESSION privilege aggregates all session privileges listed in this table.
Session Privilege Operations and the Required Privileges to Perform Them
| Session Operations | Required Session Privilege |
|---|---|
| Create Session | CREATE_SESSION privilege in the ACL set on the Real Application Security application user (that is used for creating the session) or in the System ACL. If there is a negative grant in the principal specific ACL, the operation fails. |
| Attach Session | ATTACH_SESSION privilege in the ACL set on the Real Application Security application user (that is used for creating the session) or in the System ACL. ENABLE_DYNAMIC_ROLE privilege in the ACL set on the dynamic roles (that is used for creating the session) or in the System ACL. If there is a negative grant in the principal specific ACL, the operation fails. |
| Assign User | ASSIGN_SESSION privilege in the ACL set on the named Real Application Security application user to be assigned or in the System ACL. ENABLE_DYNAMIC_ROLE privilege in the ACL set on the dynamic roles (that is used for creating the session) or in the System ACL. So if there are dynamic roles enabled, these privileges are checked. If there is a negative grant in the principal specific ACL, the operation fails. |
| Switch User | No session privilege check, as per proxy configuration. |
| Enable Role | No session privilege check. |
| Disable Role | No session privilege check. |
| Namespace Operation (Create Namespace, delete namespace, create attribute, set attribute, reset attribute, delete attribute) | No session privilege check, only namespace privilege checks. |
| Save Session, Detach Session | No session privilege check. |
| Destroy Session | TERMINATE_SESSION privilege in the ACL set on the Real Application Security application user (that is used for creating the session) or in the System ACL. |
| Set Session Cookie | MODIFY_SESSION privilege in the ACL set on the Real Application Security application user (that is used for creating the session) or in the System ACL. |
| Set Inactivity Timeout | MODIFY_SESSION privilege in the ACL set on the Real Application Security application user (that is used for creating the session) or in the System ACL. |
| Reauthorize Session | MODIFY_SESSION privilege in the ACL set on the Real Application Security application user (that is used for creating the session) or in the System ACL. |
| Get SID from Cookie | No session privilege check. |
| Global Callback Configuration (Add global callback, delete global callback, enable global callback) | No session privilege check, only callback privilege checks. |
See Also:
Granting Session Privileges on a Principal Using an ACL
Describes how to grant session privileges on a principal using an ACL while creating the user and after the user is already created.
The following examples show how to grant session privileges to principals through an ACL, USER_ACL while creating the user and after the user is already created.
First, create the ACL USER_ACL and grant the privilege ADMINISTER_SESSION to user lwuser3 and grant the privileges CREATE_SESSION, MODIFY_SESSION, and ATTACH_SESSION to user lwuser4 and grant the privileges CREATE_SESSION and MODIFY_SESSION to user lwuser5.
sqlplus /nolog
SQL> CONNECT SYS/password as SYSDBA
SQL> GRANT CREATE SESSION, XS_SESSION_ADMIN TO SEC_MGR IDENTIFIED BY password;
SQL> EXEC SYS.XS_ADMIN_UTIL.GRANT_SYSTEM_PRIVILEGE('PROVISION', 'sec_mgr', SYS.XS_ADMIN_UTIL.PTYPE_DB);CONNECT SEC_MGR
Enter password: password
Connected.DECLARE
ace_list XS$ACE_LIST;
BEGIN
ace_list := XS$ACE_LIST(
XS$ACE_TYPE(privilege_list=>XS$NAME_LIST('"ADMINISTER_SESSION"'),
granted=>true,
principal_name=>'lwuser3'),
XS$ACE_TYPE(privilege_list=>XS$NAME_LIST('"CREATE_SESSION"','"MODIFY_SESSION"','"ATTACH_SESSION"'),
granted=>true,
principal_name=>'lwuser4'),
XS$ACE_TYPE(privilege_list=>XS$NAME_LIST('"CREATE_SESSION"','"MODIFY_SESSION"'),
granted=>true,
principal_name=>'lwuser5'));
sys.xs_acl.create_acl(name=>'USER_ACL',
ace_list=>ace_list,
sec_class=>'SESSIONPRIVS',
description=>'Session management');
END;
/Next, create users lwuser3 and lwuser4 and grant these users the ACL, USER_ACL.
BEGIN
SYS.XS_PRINCIPAL.CREATE_USER(name=>'lwuser3',
schema=>'HR',
acl=>'USER_ACL';
END;
/
EXEC SYS.XS_PRINCIPAL.SET_PASSWORD('lwuser3', 'password');BEGIN
SYS.XS_PRINCIPAL.CREATE_USER(name=>'lwuser4',
schema=>'HR',
acl=>'USER_ACL';
END;
/
EXEC SYS.XS_PRINCIPAL.SET_PASSWORD('lwuser4', 'password');Next, create user lwuser5 and set the ACL, USER_ACL, for this user using the SET_ACL procedure.
sqlplus SEC_MGR
Enter password: password
Connected.BEGIN
SYS.XS_PRINCIPAL.CREATE_USER(name=>'lwuser5',
schema=>'HR');
END;
/
EXEC SYS.XS_PRINCIPAL.SET_ACL('lwuser5','USER_ACL');