Figure 1. Authorization Architecture
[Cache from http://www.trl.ibm.co.jp/projects/xml/xacl/xacl-spec.html; please use this canonical URL/source if possible.]
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:
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.
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.
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:
There are two important issues to consider here.
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>.
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)> |
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> |
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.
| 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:
| 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> |
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.
| Name | Parameters | Semantics |
|---|---|---|
| compareStr |
|
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 |
|
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 |
|
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 |
|
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>
|
| 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 |
|
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. |
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:
| 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.
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.
In this section, we present several samples of policies.
The following policy says that Alice is authorized to read the <contents> element, but not authorized to write them.
<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>
|
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.
<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>
|
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].
<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>
|
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".
| 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>
|
The following is the conflict resolution algorithm.
|
Algorithm: Conflict Resolution Input/Output: A decision list <decision_list>
|
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
Enforce the propagation policy as follows:
|
Now we describe the access evaluation algorithm.
|
Algorithm: Access Evaluation Input: An access request <access_req> Output: A decision list <decision_list>
|
Here is an example of a pair consisting of an access request and a decision for the XML document in Example 2.
<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>
|
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".
| [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. |