[Cache from http://www.trl.ibm.co.jp/projects/xml/xacl/xacl-spec.html; please use this canonical URL/source if possible.]


XML Access Control Language:
Provisional Authorization for XML Documents

October 16, 2000

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

Abstract

This document specifies syntax and semantics of XML access control language (XACL).

Contents

  1. Introduction
    1. Related Works
    2. Organization
  2. Provisional Authorization Architecture
  3. XACL Specification
    1. Subjects
    2. Objects
    3. Actions
    4. Conditions
    5. Policy Specification
  4. Sample Policies
    1. Simple Policy
    2. Single Policy for Multiple Objects
    3. Simple Policy with Provisional Signature Verification
  5. Access Evaluation
    1. Example of Access Request and Decision List
  6. Request Execution
  7. Definitions
  8. References

1 Introduction

The extensible markup language (XML) is a promising standard for describing structured information and contents on the Internet [XML]. It is well recognized that the benefits of using XML as a data container are its simplicity, richness of the data structure, and excellent handling of international characters. When XML becomes a widespread data encoding format for Web applications, the data must be protected from possible threats since, for example, it may contain confidential information or since proof of non-repudiation may be required to update it. Our research motivation is to provide a mechanism to add various security features to XML documents. We propose an XML-based language to specify security policies to be enforced on specific accesses to XML documents. We call it the XML Access Control Language (XACL). It provides XML with a sophisticated access control mechanism that enables the initiator not only to securely browse XML documents but also to securely update each document element.

Similar to existing policy languages, XACL is used to specify an object-subject-action-condition oriented policy in the context of a particular XML document. The notion of subject comprises identity, group, and role. The granularity of object is as fine as single elements within the document. Currently, there are four possible actions (read, write, create and delete), but the structure of the language is not limited to these.

XACL is based on a provisional authorization model [JKS00], [KH00], [KH01], where we can specify provisional actions associated with a primitive action (read, write, create, or delete). Almost all studies in access control and authorization systems have assumed the following model: "a user makes an access request of a system in some context, and the system either authorizes the access request or denies it." In the provisional authorization model, the answer from the system is not simply "grant" or "deny." It tells the user that his request will be authorized provided he (and the system) takes certain actions or that his request is denied but the system must still take certain actions. Such actions are called provisional actions. Examples of provisional actions include auditing, digital signature verification, encryption, and XSL transformations in addition to write, create and delete actions. These provisional actions enable us to specify policies such as the following:

In the existing access control mechanisms, these provisional actions are all hard coded within applications, but in the provisional authorization system, they can be processed by the policy enforcement module, but not by applications.

1.1 Related Works

Earlier authorization models have assumed that the system either authorizes the access request or denies it [CFMS94], [D83]. Recent work by [WL93], [JSS97], [JSSB98] aims at providing a general framework that is capable of supporting flexible and multiple access control policies such as a sub-subject overrides policy and a path overrides policy. All these models, however, assume that the system either authorizes the access request or denies it. The provisional authorization model enables the authorization system to return more flexible access decisions by incorporating the notion of provisional actions in traditional authorization semantics. XACL is the first XML-based access control language for the provisional authorization model.

E. Damiani et. al. proposed an access control model for XML documents [DVPS00a], [DVPS00b]. Although their intension of providing XML documents with an access control mechanism is the same as mitivates XACL, they lay more stress on the semantics of the read action of XML documents. Nor do they support provisional authorizations.

1.2 Organization

In Section 2, we present an overview of our provisional authorization architecture. Section 3 specifies syntax and semantics of XACL. Section 4 presents several examples of policies written in XACL. Sections 5 and 6 describe the semantics of access evaluation and request execution, respectively.

2 Provisional Authorization Architecture

Figure 1 shows the architecture of the provisional authorization system. 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 (written in XACL) is enforced as follows:

Step 1: An initiator submits an access request including a target element (an element in the target XML document), a subject (the initiator's identity and its roles), and an action. When the initiator desires to play a role, the role will be assigned by some role assignment mechanism such as [HMMNR00]. It is out of scope how to assign a role and how to authenticate the identitiy of the initiator.

Step 2: The access request is evaluated according to the policy (written in XACL) and the status associated with the target XML document. If necessary, the access evaluation module is allowed to access not only the policy but also the entire target XML document. Also, it checks the group membership of the initiator if necessary. The access decision indicates not only 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 any provisional actions specified in the access decision are executed. The target XML 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

There are two important issues to consider here.

3 XACL Specification

In this section, we specify the syntax and semantics of XACL. Specifically, we define the syntax and semantics of an element with an identifier <policy>.

3.1 Subjects

A subject is specified by a triple: uid, role-set and group-set, where role-set and group-set are a set of role names and group names, respectively. Semantically, it represents a user who has the specified identity, plays all specified roles, and belongs to all specified groups. Although both roles and groups may have hierarchical structures, the current specification does not deal with them (They should be dealt with in future).

<!ELEMENT subject (uid?,role*,group*)>
<!ELEMENT uid     (#PCDATA)>
<!ELEMENT role    (#PCDATA)>
<!ELEMENT group   (#PCDATA)>

3.2 Objects

XACL is a language to describe element-wise access control policies. An object represents a single element or a set of elements in a target XML document. We identify it by a single XPath expression [XPath], specifying it with an "href" attribute. Authorizations specified for an element are intended to be applicable to all its child non-element nodes such as attribute nodes and text nodes. For example, a read authorization for an element node means that one can read all its child nodes except for sub-elements. That is, That is, objects have an element-based hierarchical structure.

Policies may propagate downward or upward in the object's hierarchy. See Policy Specification for more details.

<!ELEMENT object   EMPTY>
<!ATTLIST object   href CDATA #REQUIRED>

3.3 Actions

An action is specified as an <action> element. XACL supports both "grant" and "deny." The "permission" attribute is used to indicate whether an access is granted or a denied. The "name" attribute is used to specify the name of action.

<!ELEMENT action (provisional_action*)>
<!ATTLIST action name (read|write|create|delete) #REQUIRED
                 permission (grant|deny) #REQUIRED>
<!ELEMENT provisional_action (parameter*)>
<!ATTLIST provisional_action name CDATA #REQUIRED
                             timing (before|after) "after">

We have four actions: read, write, create, and delete.

Table 1. Summary of Actions
Type
Parameters to be specified
in access requests
Semantics
read No To read values of all child nodes except for elements of the target XML element (See Policy Specification for the propagation policy).
write A string to be written To replace all child text nodes by a single text node whose value is equal to the specified string.
create A string to be created To append the specified element to the end of the list of children of the target element.
delete No To delete the target element.

XACL supports provisional authorization. We can specify provisional actions associated with an action. The "name" attribute is used to specify the name of a provisional action and the "timing" attribute is used to specify the timing when the provisional action is executed, i.e., before or after the requested action is executed. A provisional action may succeed or fail. Provisional actions take zero or more input parameters as predicates and functions (See the next section). Provisional actions are application-specific. Several examples are given below:

Table 2. Examples of Provisional Actions
Name Parameters Semantics
log None. logs the access history.
write
1. An XPath expression of an element
2. A string to be written
Write the string in the element refered to by the specified XPath expression. The context node is the target element of the primitive action that this provisional action is associated with.
create
1. An XPath expression of an element
2. An element to be created
Append the specified element to the location refered to by the specified XPath expression. The context node is the target element of the primitive action that this provisional action is associated with.
delete
1. An XPath expression of an element
Delete the element refered to by the specified XPath expression. The context node is the target element of the primitive action that this provisional action is associated with.
verify 1. An element or a string which specifies the parameters for signature verification. e.g. a signature algorithm. The XML-Signature can be used for this purpose [XSSP]. The digitally signed parameter of the action (write or create) is verified and the actual value of the parameter is recovered. This provisional action is successfully executed only if the verification succeeds. The "timing" attribute must be "before" otherwise it does not make sense.
encrypt 1. An element or a string which specifies the parameters for encryption. e.g. an encryption algorithm. The parameter of the action (write or create) is encrypted. The "timing" attribute must be "before" otherwise it does not make sense.
xslt 1. A XSL transformation [XSLT]. Transform the initiator's view. The "timing" attribute must be "after" otherwise it does not make sense.

The "log" is one of the most fundamental provisional actions and so we specify the data format for it. The <target> element may be used to specify the name of the target XML document.

<!ELEMENT status (log*)>
<!ELEMENT log    (target?, subject, object, action)>
<!ELEMENT target EMPTY>
<!ATTLIST target href CDATA #REQUIRED>
<!ATTLIST log    time CDATA #REQUIRED>

3.4 Conditions

XACL supports Boolean formula for conditions such that the access is granted if the formula holds true. The "operation" attribute is used to specify the logic "and", "or", or "not". A condition element must have a single child element (predicate or condition) if the operation is "not". Otherwise, it must have one or more child elements.

<!ELEMENT condition (predicate|condition)*>
<!ATTLIST condition operation (and|or|not) #REQUIRED>
<!ELEMENT predicate (parameter*)>
<!ATTLIST predicate name CDATA #REQUIRED>
<!ELEMENT parameter ANY>
<!ATTLIST parameter name CDATA #IMPLIED>
<!ELEMENT function  (parameter*)>
<!ATTLIST function  name CDATA #REQUIRED>

The <predicate> element represents a Boolean function which returns true or false and may have one or more <parameter> elements as subelements. Its name attribute is used to specify the name of the predicate.

The <function> element represents a function which returns a set of nodes. It may have one or more <parameter> elements as subelements. The name attribute is used to specify the name of the function. Intuitively, to evaluate the function is to replace it by a node set representing its return value.

The <parameter> element represents parameters of predicates and functions. It is allowed to have any subelement. In particular, it may have <function> elements as subelements.

Both predicates and functions are application-specific. Some examples for each of them are given below.

Table 3. Examples of Predicates
Name Parameters Semantics
compareStr
  1. A string representing an operator
    (eq, neq).
  2. A string.
  3. A string.
Compare two strings according to the operator. For example, the following is always false.
<predicate name="compareStr">
  <parameter>eq</parameter>
  <parameter>Kudo</parameter>
  <parameter>Michiharu</parameter>
</predicate>
compareInt
  1. A string representing an operator
    (eq, neq, ge, geq, le, leq).
  2. A string representing an integer.
  3. A string representing an integer.
Compare two integers numerically according to the operator. For example, the following is always true.
<predicate name="compareInt">
  <parameter>ge</parameter>
  <parameter>100</parameter>
  <parameter>1</parameter>
</predicate>
compareDate
  1. A string representing an operator
    (before or after).
  2. A string representing a date.
  3. A string representing a date.
Compare two dates for ordering according to the operator. For example, the following is always true.
<predicate name="compareDate">
  <parameter>before</parameter>
  <parameter>1/1/2000 00:00 AM</parameter>
  <parameter>1/1/2001 00:00 AM</parameter>
</predicate>
logged
  1. A <subject> element (Optional).
  2. A <object> element (Optional).
  3. A <action> element (Optional).
The order does not matter.
If the specified log information is already logged, return true, otherwise return false. The following is an example.
<predicate name="logged">
  <parameter>
    <subject>
      <uid>Alice</uid>
    </subject>
  </parameter>
  <parameter>
    <object href="/contents/data"/>
  </parameter>
  <parameter>
    <action name="write" permission="grant"/>
  </parameter>
</predicate>

Table 4. Examples of Functions
Name Parameters Semantics
getUid None. Returns a text node representing the initiator's uid.
getRole None. Returns a set of <role> elements representing the initiator's roles.
getValue
  1. A text node representing an XPath expression, which must identify a single node.
If the specified node is an element node, returns an array of child text nodes, otherwise returns a text node representing the value of the specified node. Here is an example:
<contents>
  <name>Satoshi Hada</name>
</contents>
<parameter>
  <function name="getValue">
    <parameter>/contents/name</parameter>
  </function>
</parameter>
After evaluating this "getValue" function, the parameter value will be set to:
<parameter>Satoshi Hada</parameter>
The context node is the object specified in an <xacl> tag containing this getValue function. When the object represents multiple elements, the getValue function may return different values for different elements. See Example 2.
getDate None. Returns a text node representing the current date/time.

3.5 Policy Specification

A <policy> element consists of multiple <xacl> elements, an <xacl> element consists of multiple <rule> elements, and a <rule> element consists of multiple <acl> element. One or more target <object> elements are specified for each <xacl> element. This means that one can specify multiple ACLs for the same target elements. All these ACLs are applied to all target elements.

<!ELEMENT policy  (property?, xacl*)>

<!ELEMENT xacl    (object+,rule+)>
<!ELEMENT rule    (acl)+>
<!ELEMENT acl     (subject*, action+, condition?)>

<!ELEMENT property      (propagation?, conflict_resolution?, default?)>
<!ELEMENT propagation EMPTY>
<!ATTLIST propagation read   (no|up|down) "down"
                      write  (no|up|down) "down"
                      create (no|up|down) "no"
                      delete (no|up|down) "up">
<!ELEMENT conflict_resolution EMPTY>
<!ATTLIST conflict_resolution read   (dtp|gtp|ntp) "dtp"
                              write  (dtp|gtp|ntp) "dtp"
                              create (dtp|gtp|ntp) "dtp"
                              delete (dtp|gtp|ntp) "dtp">
<!ELEMENT default EMPTY>
<!ATTLIST default read   (grant|deny) "deny"
                  write  (grant|deny) "deny"
                  create (grant|deny) "deny"
                  delete (grant|deny) "deny">

In an <acl> element, zero or more subjects, one or more actions, and an optional condition are specified. An <acl> element says that all specified subjects are to be authorized to execute all specified actions (although they may be associated with provisional actions) on all specified elements in <object> elements if the specified condition is satisfied.

A policy also may have a single <property> element. The property element is used to specify propagation, conflict resolution and default policies. As described before, objects have an element-based hierarchical structure. A policy may propagate through the hierarchy. The <propagation> element is used to specify a propagation policy for each action. We have three types of propagation policies:

Table 5. Summary of Propagation Policies
Type Semantics
no No propagation: Authorizations are not propagated.
up Propagation up: An authorization of an element is propagated to its parent element if there is a conflicting authorization, but otherwise it will not be propagated.
down Propagation down: An authorization of an element is propagated to its sub-elements only if there is no authorization for the subelement, i.e., only if there is no <xacl> element for the subelement.

Because XACL allows us to specify both "grant" and "deny," it is the possibility that some access request is simultaneously granted and denied. The <conflict_resolution> element is used to specify three types of conflict resolution policies for each action.

Table 6. Summary of Conflict Resolution Policies
Name Semantics
dtp Denials take precedence.
gtp Grants take precedence.
ntp Nothing takes precedence. We neither authorize nor deny an access when there is a conflict. Instead, we will make a decision by referring to the default policies.

When there is no authorization (grant or deny) for an access request or when the confliction resolution policy "ntp" is enforced, we need to make a decision according to the specified default policy. This should be specified in the <default> element for each action.

When one of the <propagation>, <conflict_resolution>, or <default> elements are omitted or the <property> element is omitted, the default policies specified in the DTD are applied to each action.

4. Sample Policies

In this section, we present several samples of policies.

Simple Policy

The following policy says that Alice is authorized to read the <contents> element, but not authorized to write them.

Example 1. Simple Policy
<contents>
  <entry>
    <name>Alice</name>
    <officeTel>111-1111</officeTel>
    <homeTel>123-4567</homeTel>
  </entry>
<contents>

<policy>
  <xacl>
    <object href="/contents"/>
    <rule>
      <acl>
        <subject>
          <uid>Alice</uid>
        </subject>
        <action name="read" permission="grant"/>
        <action name="write" permission="deny"/>
      </acl>
    </rule>
  </xacl>
</policy>

Single Policy for Multiple Objects

The following policy says that an access initiator is authorized to read the <entry> element if the <name> element value equal to the initiator's uid.

Example 2. Single Policy for Multiple Objects
<contents>
  <list>
    <entry>
      <name>Alice</name>
      <officeTel>111-1111</officeTel>
      <homeTel>123-4567</homeTel>
    </entry>
    <entry>
      <name>Bob</name>
      <officeTel>001-0001</officeTel>
      <homeTel>999-7777</homeTel>
    </entry>
  </list>
<contents>

<policy>
  <xacl>
    <object href="/contents/list/entry"/>
    <rule>
      <acl>
        <action name="read" permission="grant"/>
        <condition operation="and">
          <predicate name="compareStr">
            <parameter>eq</parameter>
            <parameter>
              <function name="getValue"/>
                <parameter>./name</parameter>
              </function>
            </parameter>
            <parameter>
              <function name="getUid"/>
            </parameter>
          </predicate>
        </condition>
      </acl>
    </rule>
  </xacl>
</policy>

Simple Policy with Provisional Signature Verification

This example is equivalent to Example 2 except for the policy regarding the "write" action. This policy says that the "write" access is authorized only when the parameter to be written is digitally signed and that the access is logged before updating the document. The parameters required for the signature verification are specified based on the XML-Signature [XSSP].

Example 3. Simple Policy with Provisional Signature Verification
<contents>
  <list>
    <entry>
      <name>Alice</name>
      <officeTel>111-1111</officeTel>
      <homeTel>123-4567</homeTel>
    </entry>
    <entry>
      <name>Bob</name>
      <officeTel>001-0001</officeTel>
      <homeTel>999-7777</homeTel>
    </entry>
  </list>
<contents>

<policy>
  <xacl>
    <object href="contents/entry"/>
    <rule>
      <acl>
        <action name="read" permission="grant"/>
        <action name="write" permission="grant">
          <provisional_action timing="before" name="log"/>
          <provisional_action timing="before" name="verify">
            <parameter>
              <SignedInfo>
                <CanonicalizationMethod
                  Algorithm="http://www.w3.org/TR/1999/WD-xml-c14n-19991115"/>
                <SignatureMethod 
                  Algorithm="http://www.w3.org/2000/01/xmldsig/rsa-sha1"/>
                <Reference>
                  <Transforms>
                    <Transform
                      Algorithm="http://www.w3.org/TR/1999/WD-xml-c14n-19991115"/>
                  </Transforms>
                  <DigestMethod
                    Algorithm="http://www.w3.org/2000/01/xmldsig/sha1"/>
                </Reference>
              </SignedInfo>
            </parameter>
          </provisional_action>
        </action>
        <condition operation="and">
          <predicate name="compareStr">
            <parameter>eq</parameter>
            <parameter><function name="getUid"/></parameter>
            <parameter>
              <function name="getValue">
                <parameter>name</parameter>
              </function>              
            </parameter>
          </predicate>
        </condition>
      </acl>
    </rule>
  </xacl>
</policy>

5. Access Evaluation

The access evaluator takes as input an access request and outputs a list of access decisions. The following is a DTD of access requests. An initiator must specify all three of object, subject, and action. The specified object must identify a unique element.

<!ELEMENT access_req   (object, subject, action)>
<!ATTLIST access_req   type (query|execute) "query">
<!ELEMENT subject      (uid?,role*)>
<!ELEMENT uid          (#PCDATA)>
<!ELEMENT role         (#PCDATA)>
<!ELEMENT object       EMPTY>
<!ATTLIST object       href CDATA #REQUIRED>
<!ELEMENT action       (parameter*)>
<!ATTLIST action       name CDATA #REQUIRED>
<!ELEMENT parameter    ANY>

Here is a DTD for access decisions. The <object> element and the <action> element of the <decision_list> element are used to record the requested object and the requested action, respectively. A decision (corresponding to <decision>) consists of an object, a subject, and an action. The meaning is that the subject is (or is not) authorized to execute the action on the object.

<!ELEMENT decision_list       (object, action, decision*)>
<!ATTLIST decision_list       type (query|execute) #REQUIRED>
<!ELEMENT decision            (object, subject, action)>
<!ELEMENT object              EMPTY>
<!ATTLIST object              href CDATA #REQUIRED>
<!ELEMENT subject             (uid?,role*)>
<!ELEMENT uid                 (#PCDATA)>
<!ELEMENT role                (#PCDATA)>
<!ELEMENT action              (parameter*, provisional_action*)>
<!ATTLIST action              name (read|write|create|delete) #REQUIRED
                              permission (grant|deny) #REQUIRED>
<!ELEMENT provisional_action  (parameter*)>
<!ATTLIST provisional_action  name CDATA #REQUIRED>
<!ELEMENT parameter           ANY>

We have two types of access requests: query and execute. The "type" attribute is used to indicate whether the request is query or execute. An access request of type "query" is used to check whether the initiator is authorized to execute the requested action for each of the subelements of the requested object. In this case, the target XML document is not updated. On the other hand, an "execute" access request is used to update the target XML document and the subtree evaluation is not done except when the requested action is "read".

Table 7. Query vs. Execute
Type Subtree Evaluation Document Update Initiator's View
query Always executed. No update. Any parameters specified in the request are ignored. No view is output.
execute Not executed except for "read" actions. The target XML document is updated. Provisional actions are also executed, but all provisional actions regarding the subtree are ignored. A view is created when the requested action is "read". The view contains only those nodes that the initiator is authorized to read.

The following is the matching algorithm. This algorithm doesn't deal with propagation and conflict resolution, but simply finds all ACLs matched.

Algorithm: Matching
Input: An access request <access_req>
Output: A decision list <decision_list>

  1. Search the associated policy for <xacl> elements satisfying the following conditions:
    • [Object] A set of elements refered to by the XPath expressoins specified in the <object> elements contains the object specified in the access request.
    • [Subject] The subject of the initiator and the requested action is semantically equal to the corresponding subject and action in the <xacl> element. In particular, the initiator must belong to all specified groups and play all specified roles.
    • [Condition] The condition specified in the <xacl> element holds true.
  2. Create a <decision> element for each of <xacl> elements satisfying the above conditions, where a decision consists of the requested object, the subject of the initiator, and the action specified in the <xacl> element, and append all <decision> elements to the decision list.

The following is the conflict resolution algorithm.

Algorithm: Conflict Resolution
Input/Output: A decision list <decision_list>

  1. If there is a conflict, resolve it according to the resolution policy for the requested action. If the conflict resolution "ntp" is applied, the decision depends on the default policy for the requested action. In this case, there can be no provisional action associated with the decision.

The following is the basic evaluation algorithm using the above matching algorithm. In this algorithm, both propagation and conflict resolution are dealt with. This algorithm outputs exactly one access decision.

Algorithm: Basic Evaluation
Input: An access request <access_req>
Output: Exactly one decision, which contains the access permission (grant or deny) and any associated provisional actions

Step 1: Matching
  1. Call the Matching algorithm for the input access request to get a decision list.
  2. Call the Conflict Resolution algorithm for the decision list. As a result, the list contains zero or one decision.
Step 2: Propagation Processing

Enforce the propagation policy as follows:

  • no
    Go to Step 3.
  • down
    If the decision list is empty, create an access request for the parent element, recursively call this algorithm for it, and append the resulting decision to the decision list as a decision for the original target element.
  • up
    If the decision list is empty then for each of its subelements, create a corresponding access request, recursively call this algorithm for it, and append the resulting decision to the decision list as a decision for the original target element.

    Otherwise, for each of its subelements, create a corresponding access request, recursively call this algorithm for it. If One of the decisions conflicts the original decision then remove the original one and append all the conflicting decisions to the decision list as decisions for the original target element.

Step 3: Apply Default Policy
  1. If there is no access decision in the list, make a decision according to the default policy for the requested action. In this case, this algorithm is terminated at this step and there is no provisional action associated with the decision.
Step 4: Select Only One Decision
  1. Call the Conflict Resolution algorithm for the decision list.
  2. At this point, the list contains at least one decision, but may contain more than one decision. If it is the case, select one in an arbitrary way.

Now we describe the access evaluation algorithm.

Algorithm: Access Evaluation
Input: An access request <access_req>
Output: A decision list <decision_list>

  1. Set the <object> and <action> element of the decision list to the corresponding ones in the access request.
  2. Set the "type" attribute of the decision list.
  3. Call the Basic Evaluation algorithm for the input access request.
  4. If the type of the access request is "query" or if the requested action is "read", then for each element of the subtree, create an access request and call the Basic Evaluation algorithm for it.

5.1 Example of Access Request and Decision List

Here is an example of a pair consisting of an access request and a decision for the XML document in Example 2.

Example 4. Access Request and Decision
<access_req type="query">
  <object href="/contents/list/entry[position()=2]"/>
  <subject>
    <uid>Alice</uid>
  </subject>
  <action name="read"/>
</access_req>

<decision_list type="query">
  <object href="/contents/list/entry[position()=2]"/>
  <action name="read"/>
  <decision>
    <object href="/contents/list/entry[position()=2]"/>
    <subject>
      <uid>Alice</uid>
    </subject>
    <action name="read" permission="deny"/>
  </decision>
</decision_list>

6. Request Execution

The request execution module takes as input a decision list and updates the target XML document. This will be done only when the request is of type "execute".

  1. For each target element specified in <object> of every <decision> element, execute each provisional action whose timing is "before". If any provisional action's execution fails, stop.
  2. If the requested action is "read", create a view for the initiator, otherwise no view is created. The view is the same as the target XML document except that only element nodes that the initiator is authorized to read have child nodes.
  3. Execute the granted actions in any decisions that update the target XML document.
  4. For each target element specified in <object> of every <decision> element, execute each provisional action whose timing is "after". If any provisional action's execution fails, stop.

7 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.

8 References

[CFMS94] S. Castano, M. Fugini, G. Martella, and P. Samarati, Database Security, Addison-Wesley, Reading, MA, 1994.
[D83] D. E. Denning, Cryptography and Data Security, Addison-Wesley, Reading, MA, 1983
[DVPS00a] E. Damiani, S.D.C. Vimercati, S. Paraboschi, and P. Samarati, "Securing XML Documents," Proceedings of EDBT 2000, Lecture Notes in Computer Science Vol. 1777, pp.121-135, 2000.
[DVPS00b] E. Damiani, S.D.C. Vimercati, S. Paraboschi, and P. Samarati, "Design and Implementation of an Access Control Processor for XML Documents," Proceedings of 9th WWW Conference, 2000.
[JKS00] S. Jajodia, M. Kudo, and V. S. Subrahmanian, "Provisional Authorizations,'' To appear in Workshop on Security and Privacy in E-commerce (WSPEC), Nov. 2000.
[JSS97] S. Jajodia, P. Samarati, and V. S. Subrahmanian, "A Logical Language for Expressing Authorizations,'' Proc. 1997 IEEE Symposium on Security and Privacy, pp., 31-42, May 1997.
[JSSB97] S. Jajodia, P. Samarati, and V. S. Subrahmanian, and E. Bertino, "A Unified Framework for Enforcing Multiple Access Control Policies," Proc. ACM SIGMOD International Conference on Management of Data, pp., 474-485, May 1997.
[KH00] M. Kudo and S. Hada, "XML Document Security based on Provisional Authorization," To appear in 7th ACM Conference on Computer and Communication Security, 2000.
[KH01] M. Kudo and S. Hada, "Access Control Model with Provisional Actions," To appear in IEICE Trans. Fundamentals, Vol. E84-A, 2001.
[HMMNR00] A. Herzberg, Y. Mass, J. Mihaeli, D. Naor, Y. Ravid, "Access Control Meets Public Key Infrastructure, Or: Assigning Roles to Strangers," IEEE Symposium on Security and Privacy, May, 2000.
[WL93] T. Y. C. Woo and S. S. Lam, "A Framework for Distributed Authorization," 1st ACM Conference on Computer and Communications Security, Nov. 1993.
[XML] T. Bray et.al. "Extensible Markup Language (XML) 1.0," World Wide Web Consortium (W3C), http://www.w3.org/TR/REC-xml, W3C Recommendation 6 October 2000.
[XPath] World Wide Web Consortium (W3C), "XML Path Language (XPath) Version 1.0," http://www.w3.org/TR/xpath.html, W3C Recommendation 16 November 1999.
[XSLT] J. Clark, "XSL Transformations (XSLT) Version 1.0," W3C Recommendation 16 November 1999, http://www.w3.org/TR/xslt, W3C Recommendation 16 November 1999.
[XSSP] M. Bartel et. al. "XML-Signature Syntax and Processing," http://www.w3.org/TR/xmldsig-core, W3C Working Draft.