| Oracle® XML DB Developer's Guide 10g Release 1 (10.1) Part Number B10790-01 |
|
|
View PDF |
| Oracle® XML DB Developer's Guide 10g Release 1 (10.1) Part Number B10790-01 |
|
|
View PDF |
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:
Oracle XML DB maintains object-level security for all resources in the Oracle XML DB repository.
|
Note: 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.
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.
Every ACL conforms to the Oracle XML DB ACL schema which is an XML schema. This schema is located at: /sys/schemas/PUBLIC/xmlns.oracle.com/xdb/acl.xsd.
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.
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 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.
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 |
|
Note: Privilege names are XML element names. Privileges with adav: prefix are part of the WebDAV namespace. Other privileges are part of the Oracle XML DB ACL namespace: http://xmlns.oracle.com/xdb/acl.xsd |
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.
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. |
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.
|
Note: 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 |
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:
Example 23-1 illustrates how to create an ACL:
Example 23-1 Creating an ACL Using DBMS_XDB.createResource()
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;
Example 23-2 illustrates how to set the ACL of a resource using the DBMS_XDB.setAcl() procedure.
Example 23-3 illustrates how to delete an ACL using the DBMS_XDB.deleteResource() procedure.
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:
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.
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
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';
Example 23-6 illustrates how to use the DBMS_XDB.getAclDocument() function to retrieve the ACL document for a given resource.
Example 23-7 illustrates how to retrieve privileges granted to the current user using the DBMS_XDB.getPrivileges() function.
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
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 ;
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
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;
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.
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
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.
Create a DB User Corresponding to the Shared Schema
CREATE USER myapps IDENTIFIED GLOBALLY AS '' ; GRANT CREATE SESSION, CONNECT, RESOURCE TO myapps;
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
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
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
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>
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.
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.
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.
