XML Access Control

October 24, 2000

Michiharu Kudo and Satoshi Hada
Tokyo Research Laboratory, IBM Research
{kudo, satoshih}@jp.ibm.com

XML Access Control aims at providing XML documents with a sophisticated access control model and access control specification language. With this access control technology, the access control policies control how an XML document appears. The policies also insure the document is securely updated as specified by the security programmer.

Suppose there is an online catalog document written in XML that lists available goods sold on the Internet. Consider an access control policy such that only premium members can view the special discount price information in the document. When a regular member views the catalog, any information provided for the premium members should be hidden. XML access control is capable of specifying such fine-grained access control policies for XML documents.

1. XML Access Control Language

XML Access Control Language (XACL) is an access control policy specification language that is a primary component of XML Access Control technology. Similar to existing policy languages, XACL is a language oriented around triplets of object, subject, and action. The subject primitive allows user IDs, groups and/or role names. The granularity of object reference is as fine as a single element within an XML document. The action primitive consists of four kinds of actions: read, write, create, and delete. Moreover, XACL provides the notion of provisional actions that means provisions attached to the access decision. Suppose a log provisional action is specified in the access control rule of "Alice is allowed to read the salary field". This basically means, "Alice is allowed to read the salary field, provided the access is logged." The provisional authorization model provides more flexibility in specifying access control policies than is possible with traditional object-subject-action based semantics.

2. Authorization Architecture

Figure 1 shows the architecture of the provisional authorization model. We have two main modules: an access evaluation module and a request execution module. Given an access request to execute an action for a target XML document, an associated policy is enforced as follows:

Step 1: An initiator submits an access request including a target element (i.e., an element in the target XML document), a subject (i.e., the initiator's identity and its roles), and an action (read, write, create, or delete). When the initiator desires to play a role in a transaction, it will be assigned by some role assignment mechanism, which is out of scope of XACL.

Step 2: The access request is evaluated according to the policy (written in XACL) and the status associated with the target XML document in the access evaluation module, which is allowed to access not only the policies but also the entire target document. Also, the access evaluation module checks the group membership of the initiator if necessary. The access decision includes not only a one-bit answer ("grant" or "deny") but also any provisional actions.

Step 3: The request is executed in the request execution module, where both the requested action and provisional actions specified in the access decision are executed. The target document is updated when the requested action is "write", "create" or "delete". The associated status may be updated.

Step 4: An initiator's view is created when the requested action is "read."

Figure 1. Authorization Architecture

3. Scenarios

We describe several usage scenarios for XML access control.

3.1 Server Oriented Scenario 1 - Intranet Application

Suppose there is a personnel information system built for the Intranet of a certain company. Each employee has an user account and belongs to one or more organizational groups defined by security administrators. Whenever emplyees make accesses, they are authenticated. The overall system architecture is described in Figure 2. The system is mainly used by the people in the personnel department to browse some private information such as salary information as well as employee names. These personnel data are represented in XML format as ex2_target.xml. Since the salary information is categorized as "private", accesses to those sensitive information must be prevented from unauthorized accesses. Since employee names are classified as a lower security category, they can be accessed from broader set of people. This access control policy is represented as ex2_policy.xml also in XML format.

Figure 2. System Architecture for Intranet Application

In this example, each initiator gets different view according to the access control policies and group definitions. XML access control is used to determine whether or not the initiator is allowed to read as fine as a single element within the personnel XML document.

3.2 Server Oriented Scenario 2 - Internet Workflow Application

This application simulates a typical review process for academic papers. This example illustrates how the XML access control is applied to a kind of Internet workflow applications that needs information sharing and/or updating among multiple participants who play different roles. The review process can be described as follows:

Authors submit their papers to the submission server.

A chairperson assigns one or more reviewers to each submitted paper.

The reviewers read the assigned paper and evaluate it.

The program committee members read the reviewers' evaluations and decide whether or not each paper should be accepted.

The chairperson decides on the list of accepted papers.

The authors receive notifications of acceptance or rejection.

We simplify the above process and produce a review summary document. The overall system architecture is described in Figure 3. The summary document stores data such as author information and evaluation results. The following summary document (review_target.xml) includes paper submissions from authors Xerces, Stackman, and Dreamer. Each submission consists of <paper_title>, <paper_number>, <author>, <review>, <result>, and <confirmation> fields. The <paper_title>, <paper_number>, and <author> fields stores submission information. The <review> section is used by reviewers. The <result> field is written by chairperson. The <confirmation> field is automatically filled with "checked" when the author first read the result of their submission. These set of policies are described in review_policy.xml.

Figure 3. System Architecture for Internet Workflow Application

3.3 Server Oriented Scenario 3 - Web Services

This scenario is based on the future Web Services world on the Internet. The Web Services provided by the Web services provider are registered in the Broker's repository in XML format. Users can find desirable service descriptions by submitting "find_business" message to the Broker. Broker returns appropriate service descriptions to the requester. The overoall system architecture is described in Figure 4. When returning the service description, the Broker uses the XML access control to enforce the access control policy. In figure 3, the GoodAgency obtains the service description for premium members of the Broker that includes free-dial number (1-800-123-...)while the SosoAgency obtains the service description for normal members.

Figure 4. System Architecture for Web Services

3.4 Client Side Access Control- Private Information Management

In this scenario, the XML access control is used in the client side to manage client's private information. When we send our private information such as an e-mail address and a phone number to Web servers, we have to be careful whether or not the receiving company deals with these private information securely and appropriately. Overall system architecture is described in Figure 5. In this example, Alice's private information is stored in her local machine in XML format. She made a set of access control policies like "TRUSTe" conformed companies can read private information categorized as "pvivate" while other companies can only read information categorized as "general". Once she setup her private policy, the local machine can determine which private information should be sent to the requester.

Figure 5. System Architecture for Web Services

4. Definitions

Action (Primitive action): There are four primitive actions: read, write, create, and delete.
Access Decision: A decision that indicates whether an access request is granted or denied.
Access Evaluation: A specialized function that makes access decisions by applying an associated policy to an access request for a target XML document.
Access request: The operations and operands that form part of an attempted access.
Group: A set of initiators.
Initiator: An entity (e.g. human user or computer-based entity) that attempts to access a target XML document.
Initiator's view: An XML document that the initiator receives as a result of a "read" access request.
Policy: A policy is associated with a target XML document. It contains a set of that define the conditions under which an access may be granted or denied.
Provisional action: An action associated with a primitive action (read, write, create, or delete). Whenever a requested primitive action is executed, any associated provisional actions must be executed.
Request Execution: A specialized function that updates the target XML document and the associated status, executes any provisional actions, and creates the initiator's view.
Role: A role characterizes the functions an initiator is allowed to perform.
Status: A status is associated with a target XML document. It contains logs of the accesses.
Target element: An element node in a target XML document to which access may be attempted.
Target XML document (Target document): An XML document to which access may be attempted.