Access Control in eXist: Introduction to XACML

The XACML Standard

eXtensible Access Control Markup Language (XACML) is an OASIS standard for restricting access to resources. eXist currently uses version 1.1 / 1.0 of the standard. The most recent version is 2.0 (unsupported). Work on version 3.0 is currently in progress. The following background information on XACML is not exhaustive. It is meant to be a relatively brief introduction to XACML in order to get started using XACML in eXist.

Basic Terminology

There are a few common terms used when discussing XACML. There are many more terms explicitly defined in the glossaries of the specifications; these terms are the ones that occur frequently throughout this documentation and are the most important for an overall understanding of XACML. Additionally, the below explanations are not the official definitions given in the XACML specifications. Those definitions may be found in the glossary of any of the specifications listed in the previous section.

Resource

A resource is anything to which access can be controlled. Examples include XQuery modules and Java methods.

Access Request

An access request consists of attributes that describe an operation on a resource. There are usually attributes providing information about the subject(s) (for example, a user) making the access, the resource being accessed, and the action being performed on the resource (such as 'execute query' or 'call function').

Policy

A policy is a group of definitions that restricts access to resources. Policies are generally written by a database administrator.

PEP

A Policy Enforcement Point (PEP) generates the access request to the Policy Decision Point (PDP). It interprets the PDP's decision and proceeds accordingly. For example, the PEP will likely perform the access if it is allowed or provide feedback to the user if the access is not allowed.

PDP

A Policy Decision Point (PDP) handles an access request and determines if that access is allowed. The PDP uses policies in order to make that decision.

An Example

To try to help make the key terms and their usage clearer, here is an example of an XACML use case in eXist.

A user clicks the Function Library documentation link on the left sidebar on the eXist webpage. This causes a request to eXist to execute the XQuery functions.xq. The code responsible for executing XQueries contains a Policy Enforcement Point (PEP) that generates an access request. This request contains the user making the request (in this case, the user under which Cocoon runs), the interface used to make the request (Cocoon uses the XML:DB interface, so 'XML:DB' is the specified interface in the request), the source of the query (which is 'functions.xq' for this example), and the action being performed on the resource (in this example, 'execute' is the action).

The PEP makes the request to the Policy Decision Point (PDP). The PDP finds the applicable policy out of all of the policies created by the administrator. The PDP then checks the request against the policy, makes a decision, and informs the PEP. Let's say that in this example, the administrator decided to allow execution of functions.xq by everyone. The PDP then informs the PDP that functions.xq may be executed.

The PEP gets the response from the PDP that executing functions.xq is allowed. It allows the query execution code to proceed. If the access were denied, it would have thrown a PermissionDeniedException.

During its execution, the functions.xq query calls several functions in the http://exist-db.org/xquery/util module during its execution. util:registered-modules() is one of these functions. In the code that performs XQuery function calls, there is a PEP controlling access to function calls. This PEP generates the appropriate access request, passes it to the PDP, obtains the result, and allows the method to be called if the PDP allowed the access.

This sequence of events occurs for each access to a controlled resource.

XACML Policies

This section describes XACML policies in enough detail to write policies in eXist using the graphical policy editor in the client. To manually create policies, the level of detail provided in the specifications (or possibly in a thorough tutorial) is probably required. A policy has a structure that is represented by the following cropped screenshot from the graphical editor.

A Policy Decision Point (PDP) responds to an access request by finding the unique policy that applies to that request. It is an error if more than one policy applies or if no policy applies. The target section of each policy provides the initial information for determining the applicable policy.

This policy applies if:
							the value of the subject attribute "user-name" in the request equals the string constant "guest".
						

This policy applies if the resource being accessed is:
							(an "XQuery main module" named "delete.xql" accessed through the "REST" interface)
							OR
							(a "Java method" named "exit" in class "java.lang.System" accessed by the "XML:DB" interface).
						

This policy applies if:
							The subject's name is ("xmldb" or "cocoon")
							AND
							the interface is ("XML:DB" or "Cocoon").
						

Sun's XACML Implementation

As the section title suggests, Sun developed an implementation of XACML in Java called Sun's XACML Implementation. It is open source and is hosted at SourceForge: http://sunxacml.sourceforge.net/. eXist uses this implementation to construct and evaluate access requests according to the policies provided by the database administrator. In general, you don't need to know much about Sun's implementation unless you want to use XACML outside of eXist. That is, if you will be enforcing policies in your application and making your own requests. The Policy Decision Point (PDP) in Sun's implementation should theoretically be a black box to which you provide policies, eXist provides an access request, and it tells you if that access is allowed.

Sun, Sun Microsystems, and Java are trademarks or registered trademarks of Sun Microsystems, Inc. in the U.S. and other countries.