About Configuring Access Control Lists

This section contains the following topics:

• About ACLs and ACEs

• Creating ACLs and ACEs

• About Validating Access Control Lists

• Updating Access Control Lists

• About Checking ACLs for a Privilege

• About Using Multilevel Authentication

• Principal Types

• Access Resolution Results

• ACE Evaluation Order

• ACL Inheritance

• About ACL Catalog Views

• About Security Class Catalog Views

About ACLs and ACEs

Real Application Security encompasses access control lists (ACLs) and supports grants, denials, and various conflict resolution methods. ACLs are extended to support application-defined privileges, enabling applications to control privileges that are meaningful to it. Authorization queries are of the form: “Is the application user authorized for privilege p in ACL a?” Application-defined privileges are implemented through APIs supported both in the middle tier and in the database. These APIs enable the application to protect sensitive operations, such as approval of purchase orders.

Before performing a sensitive operation, the application must determine the required application privileges. For example, if the application requires the approvePO application privilege, it must locate the ACL associated with the desired purchase order, a1, and issue a query to determine if the Real Application Security session is authorized for application privilege approvePO in a1. Note that the application must be trusted to properly carry out authorization. Data security improves this by providing a declarative method of associating ACLs with rows in a table; a data security policy allows an administrator or developer to identify a set of rows in a table using an SQL predicate and associates the set with the ACL that is used to control access to its member rows.

The data security system provides a SQL operator that returns the ACLs associated with a row. This SQL operator performs an authorization check using the ACL references associated with the row. By default, a query returns all rows the user is allowed to view; these ACL references may be used in the middle tier to determine appropriate access for a particular row, as arguments in a WHERE clause that limits the result set. Thus, the result set may be further restricted to display only those rows for some specific operations, such as approvePO, based on the user’s authorization.

The Real Application Security system provides native enforcement for SQL operations in the database, limiting the scope for damage due to security errors in the application. Thus, a SQL injection attack in one part of the application will not provide access to tables outside of that component.

An ACL protects a resource by specifying application privileges of the principals on the resource. An ACL is a list of access control entries (ACEs) where each ACE maintains the mapping from a principal to a granted or denied application privileges for the resource. A principal may be a database user or Real Application Security application user or application role.

Access Control Entry or ACE

An access control entry, or ACE, represents an application privilege grant, and an ACL represents a set of application privilege grants that are bound to a resource. Here, the resource can be a database table, a column in a table, or a set of rows in a table selected using a SQL predicate. Hence when a resource is accessed, only the ACLs associated with the resource are checked for the access right.

An ACE either grants or denies access to some application function or other database data for a particular principal. The ACE does not, itself, specify which data to protect; that is done outside the ACE and the ACL, by associating the ACL with target data.

XS$ACE_TYPE type is provided to construct each ACE entry for the ACL. An XS$ACE_LIST object consists of a list of privileges and the principal to whom the privileges are granted or denied. ACEs related information can be accessed through DBA_XS_ACES view.

Creating ACLs and ACEs

Example: Creating an Access Control List creates an ACL called HRACL. This ACL includes ACEs contained in ace_list. The application privileges used in ace_list are available in the HRPRIVS security class. The st_date and en_date parameters specify the active start and end times for this ACL; note that only the SELECT and VIEW_SENSITIVE_INFO application privileges are temporary.

Example: Creating an Access Control List

DECLARE
  st_date TIMESTAMP WITH TIME ZONE;
  en_date TIMESTAMP WITH TIME ZONE;
  ace_list XS$ACE_LIST;
BEGIN
  st_date := SYSTIMESTAMP;
  en_date := TO_TIMESTAMP_TZ('2019-06-18 11:00:00 -5:00',
                          'YYYY-MM-DD HH:MI:SS  TZH:TZM');
  ace_list := XS$ACE_LIST(
      XS$ACE_TYPE(privilege_list=>XS$NAME_LIST('"SELECT"','VIEW_SENSITIVE_INFO'),
                  granted=>true,
                  principal_name=>'HRREP',
                  start_date=>st_date,
                  end_date=>en_date),
      XS$ACE_TYPE(privilege_list=>XS$NAME_LIST('UPDATE_INFO'),
                  granted=>true,
                  principal_name=>'HRMGR'),
      XS$ACE_TYPE(privilege_list=>XS$NAME_LIST('"SELECT"'),
                  granted=>true,
                  principal_name=>'DB_HR', principal_type=>XS_ACL.PTYPE_DB));

  sys.xs_acl.create_acl(name=>'HRACL',
                    ace_list=>ace_list,
                    sec_class=>'HRPRIVS',
                    description=>'HR Representative Access');
END;
/

Each ACE includes a principal that is the target of the grant and a list of application privileges. The grant is subject to the following attributes described in these topics:

• Denying a Privilege

• Inverting an Application Privilege

• ACE Start-Date and End-Date

Denying a Privilege

When a grant is negated, the application privileges are denied. Example: Denying a Privilege sets the value of the attribute granted to FALSE to deny application privileges to the principal. The default value is TRUE.

Real Application Security ACL supports only the ordered evaluation of ACEs. The first ACE that grants or denies the requested application privilege contributes toward the final grant or deny. See section “DBA_XS_ACES”.

Example: Denying a Privilege

XS$ACE_LIST(
            XS$ACE_TYPE(privilege_list=>XS$NAME_LIST('UPDATE_INFO'),
            granted=>FALSE,
            principal_name=>'HRREP'
            );

Inverting an Application Privilege

When the specified application privileges are given to all principals except one, that principal is inverted; the inverted attribute is set to TRUE. The default value of the attribute inverted is FALSE. In Example: Inverting an Application Privilege, a grant made to the inverted role HRGUEST provides the application privileges to any user that does not have the role enabled.

Example: Inverting an Application Privilege

XS$ACE_LIST(
            XS$ACE_TYPE(privilege_list=>XS$NAME_LIST('UPDATE_INFO'),
            inverted=>TRUE,
            principal_name=>'HRGUEST'
            );

ACE Start-Date and End-Date

Each ACE can have a time constraint based on a start-date and an end-date, specifying the time when the ACE is in effect.

In Example: Setting ACE Start-Date and End-Date, the optional attributes start_date and end_date (of datatype TIMESTAMP WITH TIME ZONE) define the time period over which an ACE is valid. The end_date value must be greater than the start_date value.

Example: Setting ACE Start-Date and End-Date

XS$ACE_TYPE(privilege_list=>XS$NAME_LIST('"SELECT"','VIEW_SENSITIVE_INFO'),
            granted=>true,
            principal_name=>'HRREP',
            start_date=>st_date,
            end_date=>en_date))

About Validating Access Control Lists

Oracle recommends that you always validate the Real Application Security objects after administrative configuration changes. The XS_DIAG package provides a set of validation APIs to help ensure that these changes do not damage the complicated relationships among your Real Application Security objects.

See “VALIDATE_ACL Function” for more information about validating an ACL.

Updating Access Control Lists

To manipulate ACLs, use the procedures in PL/SQL package XS_ACL; it contains procedures that create and manage ACLs. See “XS_ACL Package”.

Example: Appending an ACE to an Access Control List invokes APPEND_ACES to add an ACE, ace_entry, to the HRACL ACL. The ACE grants the SELECT privilege to the DB_HR database user.

Example: Removing all ACEs from an ACL invokes REMOVE_ACES to remove all ACEs from the ACL called HRACL.

The procedure sets or modifies the security class for an ACL. Example: Modifying the Security Class for an ACL invokes SET_SECURITY_CLASS procedure to associate the HRPRIVS security class with ACL HRACL.

Example: Setting or Modifying the Parent ACL invokes SET_PARENT_ACL to set the AllDepACL ACL as the parent ACL for the HRACL ACL. The inheritance type is set to EXTEND.

Example: Removing all ACL Parameters for an ACL invokes REMOVE_ACL_PARAMETERS to remove all ACL parameters for ACL1.

Example: Removing the Specified ACL Parameter for an ACL invokes REMOVE_ACL_PARAMETERS to remove the REGION parameter for ACL1.

Example: Setting a Description String for an ACL invokes SET_DESCRIPTION to set a description for ACL HRACL.

Example: Deleting an ACL invokes DELETE_ACL to delete ACL HRACL using the default delete option.

Example: Appending an ACE to an Access Control List

DECLARE
  ace_entry XS$ACE_TYPE;
BEGIN
  ace_entry := XS$ACE_TYPE(privilege_list=>XS$NAME_LIST('"SELECT"'),
                           granted=>true,
                           principal_name=>'DB_HR',
                           principal_type=>XS_ACL.PTYPE_DB);
  SYS.XS_ACL.APPEND_ACES('HRACL',ace_entry);
END;

Example: Removing all ACEs from an ACL

BEGIN
  SYS.XS_ACL.REMOVE_ACES('HRACL');
END;

Example: Modifying the Security Class for an ACL

BEGIN
  SYS.XS_ACL.SET_SECURITY_CLASS('HRACL','HRPRIVS');
END;

Example: Setting or Modifying the Parent ACL

BEGIN
  SYS.XS_ACL.SET_PARENT_ACL('HRACL','AllDepACL',XS_ACL.EXTENDED);
END;

Example: Removing all ACL Parameters for an ACL

BEGIN
  SYS.XS_ACL.REMOVE_ACL_PARAMETERS('ACL1');
END;

Example: Removing the Specified ACL Parameter for an ACL

BEGIN
  SYS.XS_ACL.REMOVE_ACL_PARAMETERS('ACL1','REGION');
END;

Example: Setting a Description String for an ACL

BEGIN
  SYS.XS_ACL.SET_DESCRIPTION('HRACL',
                         'Grants privileges to HR representatives and managers.');
END;

Example: Deleting an ACL

BEGIN
  SYS.XS_ACL.DELETE_ACL('HRACL');
END;

About Checking ACLs for a Privilege

There are two forms of enforcement; the system enforces DML privileges on data security protected objects, and the SQL operator added by the user enforces all other application privileges.

To check an ACL for an application privilege, call the SQL operator ORA_CHECK_ACL:

ORA_CHECK_ACL (acls, privilege [,privilege] ... )

The ORA_CHECK_ACL SQL operator evaluates the list of application privileges with respect to an ordered list of ACLs. The evaluation process proceeds until any one of the following three events occurs:

• A grant is encountered for every application privilege specified before any potential denials of the same application privilege. The outcome is that the application privileges are granted.

• One of the application privileges specified is denied before any potential grants. The outcome is that at least one of the application privileges is denied.

• The list of ACEs is fully traversed. The outcome is that not all of the application privileges are granted.

To evaluate the application privilege, Oracle checks the ACEs (which are kept in order), and the evaluation stops when it finds an ACE that grants or denies the requested application privileges.

To find the ACLs associated with rows of a table or view, call the SQL operator ORA_GET_ACLIDS: ORA_GET_ACLIDS(table, ...). For example, to enforce an application privilege, priv, on a table, tab, the user query adds the following check:

ORA_CHECK_ACL(ORA_GET_ACLIDS(tab), priv)

This function answers the question whether application privileges were granted, denied, or neither. A corresponding Java API is also available.

About Using Multilevel Authentication

Multilevel authentication enables the user to specify, through system-constraining ACLs, application privileges based on levels of authentication. A system-constraining ACL specifies a minimum application-wide set of application privileges on objects, based on dynamic roles that reflect an application user’s level of authentication. When attempting to access an object, an application user may be either strongly or weakly authenticated, either inside or outside the firewall, with the following four possible levels of authentication:

• Strongly authenticated, inside firewall

• Strongly authenticated, outside firewall

• Weakly authenticated, inside firewall

• Weakly authenticated, outside firewall

A system-constraining ACL can specify application privileges that apply to application users at each level of authentication in an application. Based on application requirements, the administrator may grant additional application privileges to specific users based on any necessary criteria; such additional application privileges are independent of any system-constraining ACL. Example: Constraining ACL Inheritance: Firewall-Specific Authentication Privilege and Example: Using a Constraining Application Privilege implement a system-constraining ACL.

Principal Types

In addition to Real Application Security principals, application users and application roles, Real Application Security supports grants based on database users and roles. When the system evaluates an ACL in a context of a Real Application Security session, it ignores grants that are based on a database schema, but honors grants that are based on database role because they are part of Real Application Security user’s role list. Within an ACL, multiple ACEs can grant privileges to a principal.

Access Resolution Results

Requests for access can have two possible results: true or false.

• A result of true means that the requested application privilege is granted

• A result of false means that the requested application privilege is either not granted or denied.

ACE Evaluation Order

ACEs are evaluated in the order they appear in the ACL. The outcome of evaluating a particular ACE may be one of the following:

• The application privilege is granted.

• The application privilege is denied.

• The application privilege is neither granted nor denied.

Note that if an ACE grants an application privilege that a previous ACE denies, the result is a deny because the ACEs are evaluated in order.

ACL Inheritance

ACLs can explicitly inherit from a single parent ACL, enabling the application to share policies across multiple objects. When the request for an application privilege involves two ACLs, the final result of the access-resolution algorithm may be based on semantics of individual access-resolution results of the ACLs. Real Application Security supports two types of inheritance semantics: extending ACL inheritance (OR with ordered evaluation), and constraining ACL inheritance (AND).

This section contains:

• Extending ACL Inheritance

• Constraining ACL Inheritance

Extending ACL Inheritance

Extending ACL inheritance (OR with ordered evaluation) dictates that the ACEs are evaluated from the bottom of the inheritance tree to its top, from child to parent. In extending ACL inheritance, an application privilege is granted if either child or parent ACL grants the privilege, and denied if either the child or parent ACL denies the privilege. In fact, the first ACL that explicitly grants or denies the requested application privilege determines the final result. After the first grant or deny, further evaluations of the remaining ACLs are not attempted. Note that this evaluation rule is the same as the ordered evaluation of ACEs within an ACL.

The following example sets the AllDepACL ACL as the parent ACL for the HRACL ACL. The inheritance type is set to EXTENDED.

Example: Extending ACL Inheritance

BEGIN
  SYS.XS_ACL.SET_PARENT_ACL('HRACL','AllDepACL',XS_ACL.EXTENDED);
END;

Constraining ACL Inheritance

Constraining ACL inheritance (AND) requires that both the child and the parent ACL grant the application privilege so that the ACL check evaluates to true.

Application-wide security policies can be enforced if all the ACLs for an application are constrained by the same parent ACL. For example, imagine a sample policy where users who are authenticated as being inside the corporate firewall can have application privileges in addition to the SELECT privilege. Example: Constraining ACL Inheritance: Firewall-Specific Authentication Privilege shows the constraining ACL for this policy (inheritance type is set to CONSTRAINED), where all application users with XSPUBLIC application role are granted the SELECT privilege. Note that only the application users who are inside the corporate firewall have the dynamic application role FIREWALL enabled. Therefore, application users inside the firewall are granted all the application privileges in HRPRIVS security class. As this ACL constrains all the ACLs, such as guestACL, Example: Using a Constraining Application Privilege shows that the application privilege grants of these ACLs are constrained by FIREWALL_ACL.

Example: Constraining ACL Inheritance: Firewall-Specific Authentication Privilege

DECLARE
  ace_list XS$ACE_LIST;
BEGIN
  ace_list := XS$ACE_LIST(
                 XS$ACE_TYPE(privilege_list=>XS$NAME_LIST('"SELECT"'),
                             granted=>true,
                             principal_name=>'XSPUBLIC'),
                 XS$ACE_TYPE(privilege_list=>XS$NAME_LIST('ALL'),
                             granted=>true,
                             principal_name=>'FIREWALL'));
  sys.xs_acl.create_acl(name=>'FIREWALL_ACL',
                    ace_list=>ace_list,
                    sec_class=>'HRPRIVS',
                    description=>'Only select privilege if not inside firewall');
END;
/

BEGIN
SYS.XS_ACL.SET_PARENT_ACL('GuestACL', 'FIREWALL_ACL',XS_ACL.CONSTRAINED);
END;

Example: Using a Constraining Application Privilege

SQL> select ACE_ORDER, GRANT_TYPE, PRINCIPAL, PRIVILEGE
     from DBA_XS_ACES
     where ACL='FIREWALL_ACL';

ACE_ORDER    GRANT_TYPE    PRINCIPAL    PRIVILEGE
----------   ----------    ---------    ----------
1            GRANT         XSPUBLIC     SELECT
2            GRANT         FIREWALL     ALL

About ACL Catalog Views

ACLs have the following catalog views:

• DBA_XS_ACLS catalog view, described in section “DBA_XS_ACLS”

• DBA_XS_ACES catalog view, described in section “DBA_XS_ACES”

About Security Class Catalog Views

Security classes have the following catalog views:

• DBA_XS_SECURITY_CLASSES, described in section “DBA_XS_SECURITY_CLASSES”

• DBA_XS_SECURITY_CLASS_DEP, described in “DBA_XS_SECURITY_CLASS_DEP”

• DBA_XS_PRIVILEGES, described in “DBA_XS_PRIVILEGES”