Skip Headers

Oracle® XML DB Developer's Guide
10g Release 1 (10.1)

Part Number B10790-01
Go to Documentation Home
Go to Book List
Book List
Go to Table of Contents
Go to Index
Go to Master Index
Master Index
Go to Feedback page

Go to previous page
Go to next page
View PDF

23 Oracle XML DB Resource Security

This chapter describes the access control list (ACL) based security mechanism for Oracle XML DB resources, how to create ACLs, set and change ACLs on resources, and how ACL security interacts with other Oracle Database security mechanisms.

This chapter contains these topics:

Introducing Oracle XML DB Resource Security and ACLs

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


XML objects that are not stored in Oracle XML DB repository do not have object-level access control.

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.

How the ACL-Based Security Mechanism Works

ACLs in Oracle XML DB are XML schema-based resources. They are stored and managed in Oracle XML DB. Every resource in the Oracle XML DB is protected by an ACL. Before a user performs an operation or method on a resource, a check of user privileges on the resource takes place. The set of privileges checked depends on the operation or method being performed. For example, to increase employee Scott's salary by 10 percent, READ and WRITE privileges are needed for the /home/SCOTT/salary.xml resource.

Some ACLs are supplied with Oracle XML DB. There is only one ACL, the bootstrap ACL, located at /sys/acls/bootstrap_acl.xml in Oracle XML DB repository, that is self-protected; that is, it is protected by its own contents. This ACL, supplied with Oracle XML DB, grants READ privilege to all users. The bootstrap ACL also grants FULL ACCESS to XDBADMIN (Oracle XML DB ADMIN) and DBA roles. The XDBADMIN role is particularly useful for users that must register global XML schemas.

Other ACLs supplied with Oracle XML DB are:

  • all_all_acl.xml Grants all privileges to all users

  • all_owner_acl.xml Grants all privileges to the owner of the resource

  • ro_all_acl.xml Grants read privileges to all users

These ACLs are also protected by the bootstrap ACL.

Relationship Between ACLs and Resources

Every ACL conforms to the Oracle XML DB ACL schema which is an XML schema. This schema is located at: /sys/schemas/PUBLIC/

Every ACL is stored in a table named XDB$ACL that is owned by user XDB. This is an XML schema-based XMLType table. Hence every row in this table (and therefore each ACL) has a system-generated object identifier (OID) that can be accessed as a column named OBJECT_ID.

Every resource has a property named ACLOID. The ACLOID stores the OID of the ACL that protects the resource. Note that an ACL is also a resource in Oracle XML DB. Hence the XMLRef property of an ACL resource, for example, /sys/acls/all_all_acl.xml, is a REF to the row in table XDB$ACL that contains the actual content of the ACL. These two properties form the link between the XDB$RESOURCE table, which stores Oracle XML DB resources, and table XDB$ACL.

Access Control List Concepts

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

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:

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.

Atomic Privileges

Table 23-1 lists the atomic privileges supported by Oracle XML DB.

Table 23-1 Oracle XML DB Supported Atomic Privileges

Privilege Name Description Database Counterpart
read-properties Read the properties of a resource SELECT
read-contents Read the contents of a resource SELECT
update Update the properties and contents of a resource UPDATE
link For containers only. Allows resources to be bound to the container. INSERT
unlink For containers only. Allows resources to be unbound from the container. DELETE
link-to Allows resources to be linked N/A
unlink-from Allows resources to be unlinked N/A
read-acl Read the resource ACL SELECT
write-acl-ref Changes the resource ID UPDATE
update-acl Change the contents of the resource ACL UPDATE
resolve For containers only: Allows the container to be traversed SELECT
dav:lock Lock a resource using WebDAV locks UPDATE
dav:unlock Unlock a resource locked using a WebDAV lock UPDATE


Privilege names are XML element names. Privileges with a dav: prefix are part of the WebDAV namespace. Other privileges are part of the Oracle XML DB ACL namespace:

Because you can directly access the XMLType storage for ACLs, the XML structure is part of the client interface. Hence ACLs can be manipulated using XMLType APIs.

Aggregate Privileges

Table 23-2 lists the aggregate privileges defined by Oracle XML DB, along with the atomic privileges of which they are composed.

Table 23-2 Aggregate Privileges

Aggregate Privilege Names Atomic Privileges
all All atomic privileges: dav:read, dav:write, dav:read-acl, dav:write-acl, dav:lock, dav:unlock
dav:all All atomic privileges except linkto
dav:read read-properties, read-contents, resolve
dav:write update, link, unlink, unlink-from
dav:read-acl read-acl
dav:write-acl write-acl-ref, update-acl

Table 23-3 shows the privileges required for some common operations on resources in Oracle XML DB repository. The Privileges Required column assumes that you already have the resolve privilege on container C and all its parent containers, up to the root of the hierarchy.

Table 23-3 Privileges Needed for Operations on Oracle XML DB Resources

Operation Description Privileges Required
CREATE Create a new resource in container C update and link on C
DELETE Delete resource R from container C update and unlinkfrom on R, update and unlink on C
UPDATE Update the contents or properties of resources R update on R
GET An FTP or HTTP GET of resource R read-properties, read-contents on R
SET_ACL Set the ACL of a resource R dav:write-acl on R
LIST List the resources in container C read-properties on C, read-properties on resources in C. Only those resources on which the user has read-properties privilege are listed.

Interaction with Database Table Security

Resources in the Oracle XML DB repository are either:

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.


Some, but not all, objects in a particular table may be mapped to Oracle XML DB resources. In that case, only those objects mapped into the Oracle XML DB repository have ACL checking done, although they will all have table-level security.

Note: You cannot hide data in XMLType tables from other users when using out-of-line storage. The out-of-line data is not protected by ACL Security.

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:

Creating an ACL Using DBMS_XDB.createResource()

Example 23-1 illustrates how to create an ACL:

Example 23-1 Creating an ACL Using DBMS_XDB.createResource()

    b boolean;
    b := DBMS_XDB.createResource('/home/SCOTT/acl1.xml', 
       <acl description="myacl"

Setting the ACL of a Resource

Example 23-2 illustrates how to set the ACL of a resource using the DBMS_XDB.setAcl() procedure.

Example 23-2 Setting the ACL of a Resource

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

Deleting an ACL

Example 23-3 illustrates how to delete an ACL using the DBMS_XDB.deleteResource() procedure.

Example 23-3 Deleting an ACL

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

If a resource is being protected by the ACL to be deleted, first change the ACL of that resource before deleting the ACL.

Updating an ACL

This can be done using standard methods for updating resources. In particular since an ACL is an XML document, updateXML and other operators can be used to manipulate ACLs. Oracle XML DB ACLs are cached for fast evaluation. When a transaction that updates an ACL is committed, the modified ACL is picked up by existing database sessions after the timeout specified in the Oracle XML DB configuration file, /xdbconfig.xml, is up. The XPath for this configuration parameter is: /xdbconfig/sysconfig/acl-max-age. The unit of this timeout is second. Note that sessions initiated after the ACL is modified will use the new ACL without any delay.If an ACL resource is updated with non-ACL content, the same rules that apply for deletion will apply, that is, if any resource is being protected by the ACL that is being updated, first change the ACL of that resource. There are 2 different cases for updating ACL:

Updating the Entire ACL or Adding or Deleting an Entire ACE

You can use FTP or WebDAV to update the ACL. For more details on how to use these protocols, see Chapter 24. You can also use RESOURCE_VIEW to do this.

Example 23-4 Updating the Entire ACL

UPDATE resource_view r SET 
   r.res=updatexml('/r:Resource/r:Contents/a:acl', <new content of ACL>,  
   WHERE r.any_path='/home/SCOTT/acl1.xml';

Updating Existing ACE(s)

This can be done using RESOURCE_VIEW. Example 23-5 illustrates changing the principal in an ACE from SCOTT to JONES:

Example 23-5 Updating Existing ACE(s) Using RESOURCE_VIEW

UPDATE resource_view r SET 
   WHERE r.any_path='/home/SCOTT/acl1.xml';

Retrieving the ACL Document for a Given Resource

Example 23-6 illustrates how to use the DBMS_XDB.getAclDocument() function to retrieve the ACL document for a given resource.

Example 23-6 Retrieving the ACL Document for a Resource

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

Retrieving Privileges Granted to the Current User for a Particular Resource

Example 23-7 illustrates how to retrieve privileges granted to the current user using the DBMS_XDB.getPrivileges() function.

Example 23-7 Retrieving Privileges Granted to the Current User for a Particular Resource

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

Checking if the Current User Has Privileges on a Resource

Example 23-8 illustrates how to use the DBMS_XDB.checkPrivileges() function to check if the current user has a given set of privileges on a resource. This function returns a nonzero value if the user has the privileges.

Example 23-8 Checking if the Current User has a Given Set of Privileges on a Resource

SELECT DBMS_XDB.checkPrivileges('/home/SCOTT/po1.xml', 
        </privilege>') FROM dual ;

Checking if the Current User Has Privileges With the ACL and Resource Owner

This is typically used by applications that must perform ACL evaluation on their own before allowing the user to perform an operation. Use the DBMS_XDB.aclCheckPrivileges() function.

Example 23-9 Checking if the Current User Has a Given Set of Privileges Given the ACL and the Resource Owner

SELECT DBMS_XDB.aclCheckPrivileges('/home/SCOTT/acl1.xml','SCOTT', 
    </privilege>') FROM dual;

Retrieving the Path of the ACL that Protects a Given Resource

Example 23-10 retrieves the path of the ACL that protects a given resource by using a RESOURCE_VIEW query. The query uses the fact that the XMLRef and ACLOID elements of the resource form the link between an ACL and a resource.

Example 23-10 Retrieving the Path of the ACL that Protects a Given Resource

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>');

The inner query retrieves the ACLOID of the given resource. The outer query retrieves the path to the resource based on the OID of the content. The latter is retrieved by applying sys_op_r2o to the XMLRef.

Retrieving the Paths of all Resources Protected by a Given ACL

Example 23-11 illustrates how to retrieve the paths of all resources protected by a given ACL. This is done with a query similar to that used in Example 23-10.

Example 23-11 Retrieving the Paths of All Resources Protected by a Given ACL

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>');

The inner query retrieves the OID of the specified ACL's content. The outer query selects the paths of all resources ACLOIDs match the OID of the given 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

  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

    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
  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="" xmlns:dav="DAV:"
       <ace principalFormat="DistinguishedName"> 

    Example 23-16 ACL Referencing an LDAP Group

    <acl  xmlns="" xmlns:dav="DAV:"
      <ace principalFormat="DistinguishedName"> 
  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.