23 Oracle XML DB Resource Security

Introducing Oracle XML DB Resource Security and ACLs

Oracle XML DB maintains object-level security for all resources in the Oracle XML DB repository.

Oracle XML DB uses an access control list (ACL) mechanism to restrict access to any Oracle XML DB resource or database object mapped to the Oracle XML DB repository. An ACL is a list of access control entries that determine which principals have access to a given resource or resources. ACLs are a standard security mechanism used in Java, Windows NT, and other systems.

Access Control List Concepts

This section describes several access control list (ACL) terms and concepts:

• Principal. An entity that may be granted access control privileges to an Oracle XML DB resource. Oracle XML DB supports the following as principals:

  • Database users

  • Database roles. A database role can be understood as a group; for example, the DBA role represents the group of all database administrators.

  • LDAP users and groups. For details on using LDAP principals see "Integration with LDAP".

  The special principal, dav:owner, corresponds to the owner of the resource being secured. The owner of the resource is one of the properties of the resource. Use of the dav:owner principal allows greater ACL sharing between users, because the owner of the document often has special rights. See Also "Oracle XML DB Supported Privileges".

• Privilege: This is a particular right that can be granted or denied to a principal. Oracle XML DB has a set of system-defined rights (such as READ or UPDATE) that can be referenced in any ACL. Privileges can be granted or denied to the principal dav:owner, that represents the owner of the document, regardless of who the owner is. Privileges can be one of the following:

  • Aggregate (containing other privileges)

  • Atomic (which cannot be subdivided)

  Aggregate privileges are a naming convenience to simplify usability when the number of privileges becomes large, as well as to promote inter operability between ACL clients. Please see "Oracle XML DB Supported Privileges" for the list of atomic and aggregate privileges that can be used in ACLs.

  The set of privileges granted to a principal controls the ability of that principal to perform a given operation or method on an Oracle XML DB resource. For example, if the principal Scott wants to perform the read operation on a given resource, then the read privileges must be granted to Scott prior to the read operation. Therefore, privileges control how users can operate on resources.

• ACE (access control entry): ACE is an entry in the ACL that grants or denies access to a particular principal. An ACL consists of a list of ACEs where ordering is irrelevant. There can be only one grant ACE and one deny ACE for a particular principal in a single ACL.

  
  

  Note: Many grant ACEs (or deny ACEs) may apply to a particular user because a user may be granted many roles.

  
  

  An Oracle XML DB ACE element has the following properties:

  • Operation: Either grant or deny

  • Principal: A valid principal, as described previously.

  • Privileges Set: Particular set of privileges to be granted or denied for a particular principal

  • Principal Format (optional): Specifies the format of the principal. It could be an LDAP distinguished name (DN), a short name (either a DB user/role or an LDAP nickname) or an LDAP GUID. The default is 'short name'. If the principal name matches both a DB user and an LDAP nickname, it is assumed to refer to the LDAP nickname.

  • Collection (optional): This is a boolean attribute that specifies whether the principal is a collection of users (LDAP group or DB role) or a single user (LDAP or DB user).

• Access control list (ACL): A list of access control entry elements, with the element name ace, that defines access control to a resource. An ACE either grants or denies privileges for a principal.

  The following example shows entries in an ACL:

  <acl description="myacl"
        xmlns="http://xmlns.oracle.com/xdb/acl.xsd"
        xmlns:dav="DAV:"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="http://xmlns.oracle.com/xdb/acl.xsd
                            http://xmlns.oracle.com/xdb/acl.xsd">
    <ace>
      <principal>dav:owner</principal>
      <grant>true</grant>
      <privilege>
        <dav:all/>
      </privilege>
    </ace>
  </acl>

  In this ACL there is only one ACE. The ACE grants all privileges to the owner of the resource.

• Default ACL: When a resource is inserted into the Oracle XML DB repository by default the ACL on its parent folder is used to protect the resource. After the resource is created a new ACL can be set on it.

• ACL file-naming conventions: Supplied ACLs use the following file-naming conventions: <privilege>_<users>_acl.xml

  where <privilege> represents the privilege granted and <users> represents the users that are granted access to the resource.

• ACL Evaluation Rules: As mentioned before, privileges are checked before a user is allowed to access a resource. This is done by evaluating the resource's ACL for the current user. To evaluate an ACL, the database collects the list of ACEs in the ACL that apply to the user logged into the current database session. The list of currently active roles for the user is maintained as a part of the session and is used to match ACEs (that specify roles as principals) with the current users. To resolve conflicts between ACEs, the following rule is used: if a privilege is denied by any ACE, then the privilege is denied for the entire ACL.

Oracle XML DB Supported Privileges

Oracle XML DB provides a set of privileges to control access to Oracle XML DB resources. Access privileges in an ACE are stored in the privilege element. Privileges can be:

• Aggregate, composed of other privileges

• Atomic, cannot be subdivided

When an ACL is stored in Oracle XML DB, the aggregate privileges retain their identity, that is, they are not decomposed into the corresponding leaf privileges. In WebDAV terms, these are non-abstract aggregate privileges.

Interaction with Database Table Security

Resources in the Oracle XML DB repository are either:

• LOB-based (content is stored in a LOB which is part of the resource). Access is determined only by the ACL that protects the resource. Or,

• REF-based (content is XML and is stored in a database table). Users must have the appropriate privilege in the underlying table (or view) where the XML content is stored, as well as permissions through the ACL for the resource.

Since the contents of a REF-based resource may actually be stored in a table, it is possible to access this data directly using SQL queries on the table. A uniform access control mechanism is one where the privileges needed are independent of the method of access (for example, FTP, HTTP, or SQL). To provide a uniform security mechanism using ACLs, the underlying table must first be hierarchy-enabled before resources that reference the rows in the table are inserted into Oracle XML DB. This is done using the DBMS_XDBZ.enable_hierarchy() procedure. This procedure adds two hidden columns to store the ACL OID and the OWNER of the resources that reference the rows in the table. It also adds a Row Level Security (RLS) policy to the table which checks the ACL whenever a SELECT, UPDATE, or DELETE statement is executed on the table. Note that the default tables produced by XML schema registration are already hierarchy-enabled.

Working with Oracle XML DB ACLs

As mentioned before, ACLs in Oracle XML DB are resources and hence all the methods that operate on resources also apply to ACLs. In addition, there are several APIs specific to ACLs. These are in the DBMS_XDB package. The procedures and functions in this package enable you to use PL/SQL to access Oracle XML DB security mechanisms, check privileges given a particular ACL, and list the set of privileges the current user has for a particular ACL and a particular resource.

The following are examples of different ACL-related operations:

declare
    b boolean;
begin
    b := DBMS_XDB.createResource('/home/SCOTT/acl1.xml', 
       <acl description="myacl"
          xmlns="http://xmlns.oracle.com/xdb/acl.xsd"
          xmlns:dav="DAV:"
          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xsi:schemaLocation="http://xmlns.oracle.com/xdb/acl.xsd
                      http://xmlns.oracle.com/xdb/acl.xsd">
            <ace>
              <principal>dav:owner</principal>
                <grant>true</grant>
                  <privilege>
                   <dav:all/>
                  </privilege>
            </ace>
       </acl>');
end;

call DBMS_XDB.setAcl('/home/SCOTT/po1.xml', '/home/SCOTT/acl1.xml');

call DBMS_XDB.deleteResource('/home/SCOTT/acl1.xml');

UPDATE resource_view r SET 
   r.res=updatexml('/r:Resource/r:Contents/a:acl', <new content of ACL>,  
      'xmlns:r="http://xmlns.oracle.com/xdb/XDBResource.xsd"
       xmlns:a="http://xmlns.oracle.com/xdb/acl.xsd"')
   WHERE r.any_path='/home/SCOTT/acl1.xml';

UPDATE resource_view r SET 
   r.res=updatexml('/r:Resource/r:Contents/a:acl/a:ace/a:principal/text()', 
                    'JONES',  
                    'xmlns:r="http://xmlns.oracle.com/xdb/XDBResource.xsd"
                     xmlns:a="http://xmlns.oracle.com/xdb/acl.xsd"') 
   WHERE r.any_path='/home/SCOTT/acl1.xml';

SELECT DBMS_XDB.getAclDocument('/home/SCOTT/po1.xml').getClobVal() FROM dual;

SELECT DBMS_XDB.getPrivileges('/home/SCOTT/po1.xml').getClobVal() FROM dual;

SELECT DBMS_XDB.checkPrivileges('/home/SCOTT/po1.xml', 
       '<privilege 
          xmlns="http://xmlns.oracle.com/xdb/acl.xsd"
          xmlns:dav="DAV:"
          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xsi:schemaLocation="http://xmlns.oracle.com/xdb/acl.xsd 
                            http://xmlns.oracle.com/xdb/acl.xsd">
           <read-contents/>
           <read-properties/>
        </privilege>') FROM dual ;

SELECT DBMS_XDB.aclCheckPrivileges('/home/SCOTT/acl1.xml','SCOTT', 
   '<privilege 
     xmlns="http://xmlns.oracle.com/xdb/acl.xsd"
     xmlns:dav="DAV:"
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xsi:schemaLocation="http://xmlns.oracle.com/xdb/acl.xsd 
                         http://xmlns.oracle.com/xdb/acl.xsd">
       <read-contents/>
       <read-properties/>
    </privilege>') FROM dual;

SELECT a.any_path from resource_view a
   WHERE sys_op_r2o(extractValue(a.res, '/Resource/XMLRef')) =
     (select extractValue(r.res, '/Resource/ACLOID') FROM resource_view r 
      WHERE r.any_path='<path_of_resource>');

SELECT a.any_path FROM resource_view a
   WHERE extractValue(a.res, '/Resource/ACLOID') = 
         (SELECT sys_op_r2o(extractValue(r.res, '/Resource/XMLRef')) 
            FROM resource_view r
            WHERE r.any_path='<path_of_ACL>');

Integration with LDAP

Some setup steps outside of XML DB need to be performed before you can use LDAP users and groups as principals in ACLs. You need to set up the Oracle Internet Directory (OID), register the database with OID, and set up SSL authentication between the database and OID. For more details on these steps, see the Oracle Advanced Security Administrator's Guide.

This section describes the main steps involved in allowing LDAP users to use the features of XML DB. The scenario presented here deals with a single shared database schema (also termed schema-independent LDAP users). In this case, a single database user is created. The mapping of multiple LDAP users to the shared database schema is maintained in OID. Users can log in to the database (using SQL or protocols like FTP and WebDAV that are supported by XML DB) using the LDAP username and password. They are then automatically mapped to the corresponding shared schema.

1. Create a DB User Corresponding to the Shared Schema

   CREATE USER myapps IDENTIFIED GLOBALLY AS '' ;
   GRANT CREATE SESSION, CONNECT, RESOURCE TO myapps;

2. Create LDAP Users

   dn: cn=user1,ou=Americas,o=oracle,l=redwoodshores,st=CA,c=US
   cn: user1
   sn: snuser1
   uid: uiduser1
   objectclass: top
   objectclass: inetorgperson
   objectclass: orclUser
   orclPassword: {x- orcldbpwd}1.0:46B35D8418C795B3

3. Map LDAP Users to Shared DB Schema

   Example 23-12 Mapping a Single LDAP User to a Shared DB Schema

   dn: cn=odelmMyapps1,cn=server1,cn=OracleContext,ou=Americas,o=Oracle,C=US
   cn: odelmMyapps1
   objectclass: top
   objectclass: OrclDBEntrylevelMapping
   OrclDBDistinguishedName:cn=user1,ou=Americas,o=oracle,l=redwoodshores,st=CA,c=US
   orclDBNativeuser:myapps

   Example 23-13 Mapping a Subtree of Users to a Shared DB Schema

   dn: cn=odelmMyapps2,cn=server1,cn=OracleContext,ou=Americas,o=Oracle,C=US
   cn: odelmMyapps2
   objectclass: top
   objectclass: OrclDBSubtreelevelMapping
   OrclDBDistinguishedName:ou=Americas,o=oracle,l=redwoodshores,st=CA,c=US
   orclDBNativeuser:myapps

4. Create LDAP groups and specify its members

   Example 23-14 Creating LDAP Groups and Specifying Their Members

   dn: cn=grp1,ou=Americas,o=oracle,l=redwoodshores,st=CA,c=US
   cn: grp1
   objectclass: top
   objectclass: orclgroup
   objectclass: orclprivilegegroup
   objectclass: groupOfUniqueNames
   uniquemember: cn=user1,ou=Americas,o=oracle,l=redwoodshores,st=CA,c=US
   uniquemember: cn=user3,ou=Americas,o=oracle,l=redwoodshores,st=CA,c=US

5. Define ACLs in Oracle XML DB

   Example 23-15 ACL Referencing an LDAP User

   <acl description="/public/txmlacl1/acl1.xml"
         xmlns="http://xmlns.oracle.com/xdb/acl.xsd" xmlns:dav="DAV:"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
         xsi:schemaLocation="http://xmlns.oracle.com/xdb/acl.xsd 
                             http://xmlns.oracle.com/xdb/acl.xsd">
      <ace principalFormat="DistinguishedName"> 
     <principal>cn=user1,ou=Americas,o=oracle,l=redwoodshores,st=CA,c=US</principal>
       <grant>true</grant>
       <privilege>
         <dav:all/>
       </privilege>
     </ace> 
   </acl>

   Example 23-16 ACL Referencing an LDAP Group

   <acl  xmlns="http://xmlns.oracle.com/xdb/acl.xsd" xmlns:dav="DAV:"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
         xsi:schemaLocation="http://xmlns.oracle.com/xdb/acl.xsd 
                             http://xmlns.oracle.com/xdb/acl.xsd">
     <ace principalFormat="DistinguishedName"> 
       <principal>cn=grp1,ou=Americas,o=oracle,l=redwoodshores,st=CA,c=US</principal>
       <grant>true</grant>
       <privilege>
         <dav:read/>
       </privilege>
     </ace> 
   </acl>

6. Create Resources in Oracle XML DB and Protect Them with ACLs

   All existing APIs and protocol methods can be used to create resources and protect them with ACLs.

7. Connect as LDAP users Using SQL/DAV/FTP and Access Oracle XML DB

   All Oracle XML DB functionality is available when you connect as the LDAP user. The implicit ACL resolution is based on the current LDAP user and the corresponding LDAP group membership information.

Performance Issues for Using ACLs

Since ACLs are checked for every repository access, the performance of the ACL check operation is critical to the performance of the repository. In XML DB the required performance for this operation is achieved by employing several caches. ACLs are cached in a shared (shared by all sessions in the instance) cache. The performance of this cache is better when there are fewer ACLs in your system. Hence it is recommended that you share ACLs (between resources) as much as possible. Also, the cache works best when the number of ACEs in an ACL is at most 16.

There is also a session-specific cache of privileges granted to a given user by a given ACL. The entries in this cache have a time out (in seconds) specified by the element <acl-max-age> in the XDB configuration file (/xdbconfig.xml). For maximum performance this timeout should be as large as possible. But note that there is a trade-off here: the greater the timeout, the longer it will take for current sessions to pick up an updated ACL.

XML DB also maintains caches to improve performance when using ACLs that have LDAP principals (LDAP groups or users). The goal of these caches is to minimize network communication with the LDAP server. One is a shared cache that maps LDAP GUIDs to the corresponding LDAP nicknames and Distinguished Names (DNs). This is used when an ACL document is being displayed (or converted to CLOB or VARCHAR2 forms from XMLType). To purge this cache, use the DBMS_XDBZ.PurgeLdapCache() procedure. The other cache is session-specific and maps LDAP groups to their members (nested membership). Note that whenever XML DB encounters an LDAP group for the first time (in a session) it will get the nested membership of that group from the LDAP server. Hence it is best to use groups with as few members and levels of nesting as possible.