Figure 1. Authorization Architecture
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 can be as fine as the one of XML nodes within the document though the current version is restricted to elements and attributes. 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 is to provide XML documents with an access control mechanism and is the same as the intension of 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. Section 7 has links to schemas of XACL. Section 8 summarizes our terminology.
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:
This architecture is intended to be conceptual only. An implementation is not mandated to provide the access evaluation and the request execution as separate processes.
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>. The semantics may implicitly assume the use of the DOM for the implementation, but we believe that the SAX-based implementation is still possible.
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 the specified roles, and belongs to all the specified groups. So intuitively subjects have the meaning of an "AND" condition regarding identities, roles, and groups.
Both roles and groups may have hierarchical structures. Take for example a group hierarchy. When a user belongs to a group, he is also a member of its subgroups. It is often the case that all the acls regarding a group propagate downward to its subgroup. XACL supports this kind of acl propagation along both role and group hierarchies. See Policy Specification for more details.
<xsd:element name="subject">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="uid" type="xsd:string" minOccurs="0" maxOccurs="1"/>
<xsd:element name="role" type="xsd:string" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element name="group" type="xsd:string" minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
|
XACL is a language to describe element & attribute-wise access control policies. An object represents a single element, a single attribute, a set of elements, or a set of attributes in a target XML document. An object must not represent an attribute for namespace declaration, that is, "xmlns" attributes and any attribute that starts with "xmlns:" cannot be target nodes. In particular, we assume that such nodes are always in the initiator's view. We identify objects by a single XPath expression [XPath], specifying it with an "href" attribute.
An access decision may propagate downward or upward along the object hierarchy. For example, an access decision for an element may apply to all its child elements. See Policy Specification for more details.
<xsd:element name="object">
<xsd:complexType>
<xsd:attribute name="href" type="xsd:string" use="required"/>
</xsd:complexType>
</xsd:element>
|
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 action name.
<xsd:element name="action">
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="ac:provisional_action" minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
<xsd:attribute name="name" type="xsd:string" use="required"/>
<xsd:attribute name="permission" use="required">
<xsd:simpleType>
<xsd:restriction base="xsd:string">
<xsd:enumeration value="grant"/>
<xsd:enumeration value="deny"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:attribute>
</xsd:complexType>
</xsd:element>
<xsd:element name="provisional_action">
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="ac:parameter" minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
<xsd:attribute name="name" type="xsd:string" use="required"/>
<xsd:attribute name="timing" type="ac:timingName" default="after"/>
<simpleType>
<restriction base="xsd:string">
<enumeration value="after"/>
<enumeration value="before"/>
</restriction>
</simpleType>
</xsd:attribute>
</xsd:complexType>
</xsd:element>
<xsd:element name="parameter">
<xsd:complexType>
<xsd:sequence>
<xsd:any minOccurs="0" maxOccurs="unbounded" />
</xsd:sequence>
<xsd:attribute name="name" type="xsd:string" use="optional"/>
<xsd:attribute name="value" type="xsd:string" use="optional"/>
</xsd:complexType>
</xsd:element>
|
XACL supports any kind of action names. Actions in XACL have no hierarchical structure unlike subjects and objects. Here, we describe four built-in actions: read, write, create, and delete.
| Name | Parameters to be specified in access requests | Semantics |
|---|---|---|
| read | No |
When the target node is an element, the read action is to read the values of all the child nodes of the target element except for the child elements. When the target node is an attribute, it is to read the attribute value. |
| write | A string to be written |
When the target node is an element, the write action is to replace all the child text nodes by a single text node whose value is the specified string. When the target node is an attribute, this action is to set the attribute value to be the specified string. Here is an example of a write request (See Access Evaluation for its schema):
<access_req xmlns="http://www.trl.ibm.com/projects/xml/xacl" type="query">
<object href="/contents/list/entry"/>
<subject>
<uid>Alice</uid>
</subject>
<action name="write">
<parameter value="XACL"/>
</action>
</access_req>
This means that Alice is requesting to write a string "XACL" in the "/contents/list/entry" element.
|
| create | An array of nodes to be created |
The "create" action works only when the target node is an element. When the target node is an attribute, nothing will be done. This action is to append the elements specified as parameters to the end of the list of child elements of the target element. Here is an example of a create request (See Access Evaluation for its schema):
<access_req xmlns="http://www.trl.ibm.com/projects/xml/xacl" type="query">
<object href="/contents/list"/>
<subject>
<uid>Alice</uid>
</subject>
<action name="create">
<parameter>
<entry>XACL</entry>
</parameter>
</action>
</access_req>
This means that Alice is requesting to create a new <entry> element under the "/contents/list" element.
|
| delete | No | To delete the target attribute or 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 do (See the next section for the details).
In the process of request execution, if the action is "read", provisional actions associated with it are applied to the initiator's view. This means that provisional actions of timing "before" will be ignored. Only "after" provisional actions will be executed for the initiator's view after it is created. On the other hand, if the action is "write", "create", or "delete", provisional actions associated with it are applied to the target XML document. In this case, provisional actions of timing "before" (resp., "after") are executed before (resp., after) the (requested) action is executed.
Provisional actions should be application-specific. Several examples are given below:
| Name | Parameters | Semantics |
|---|---|---|
| log | None. | logs the access history. |
| write | 1. An XPath expression of an element or an attribute 2. A string to be written | Write the string in the element or the attribute referred to by the specified XPath expression. The context node is the target node of the decision that this provisional action is associated with. |
| create | 1. An XPath expression of an element 2. An array of nodes to be created under the element | Append the specified element to the location referred to by the specified XPath expression. The context node is the target node of the decision that this provisional action is associated with. |
| delete | 1. An XPath expression of an element or an attribute | Delete the element or the attribute referred to by the specified XPath expression. The context node is the target node of the decision 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.
<xsd:element name="status">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="log">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="target">
<xsd:complexType>
<xsd:attribute name="href" type="xsd:string" use="required"/>
</xsd:complexType>
</xsd:element>
<xsd:element ref="ac:subject" minOccurs="1" maxOccurs="1"/>
<xsd:element ref="ac:object" minOccurs="1" maxOccurs="1"/>
<xsd:element name="action" minOccurs="1" maxOccurs="1">
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="ac:parameter" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element ref="ac:provisional_action" minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
<xsd:attribute name="name" type="xsd:string" use="required"/>
<xsd:attribute name="permission" use="required">
<xsd:simpleType>
<xsd:restriction base="xsd:string">
<xsd:enumeration value="grant"/>
<xsd:enumeration value="deny"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:attribute>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
<xsd:attribute name="time" type="xsd:string" use="required"/>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
|
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.
<xsd:element name="condition">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="predicate">
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="ac:parameter" minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
<xsd:attribute name="name" type="xsd:string" use="required"/>
</xsd:complexType>
</xsd:element>
<xsd:element ref="ac:condition" minOccurs="0" maxOccurs="unbounded"/> </xsd:sequence>
<xsd:attribute name="operation" use="required">
<xsd:simpleType>
<xsd:restriction base="xsd:string">
<xsd:enumeration value="and"/>
<xsd:enumeration value="or"/>
<xsd:enumeration value="not"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:complexType>
</xsd:element>
<xsd:element name="function">
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="ac:parameter" minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
<xsd:attribute name="name" type="xsd:string" use="required"/>
</xsd:complexType>
</xsd:element>
|
The <predicate> element represents a Boolean function that returns true or false and may have one or more <parameter> elements as child elements. Its "name" attribute is used to specify the name of the predicate.
The <function> element represents a function that returns a set of nodes. It may have one or more <parameter> elements as child elements. 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 an input parameter of predicates and functions, which can be specified in three ways:
Both predicates and functions may be application-specific. Some typical 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 value="eq"/> <parameter value="Kudo"/> <parameter value="Michiharu"/> </predicate> |
| compareInt |
|
Compare two integers numerically according to the operator. For example, the following is always true.
<predicate name="compareInt"> <parameter value="ge"/> <parameter value="100"/> <parameter value="1"/> </predicate> |
| compareDate |
|
Compare two dates for ordering according to the operator. For example, the following is always true.
<predicate name="compareDate"> <parameter value="before"/> <parameter value="1/1/2000 00:00 AM"/> <parameter value="1/1/2001 00:00 AM"/> </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 value="/contents/name"/>
</function>
</parameter>
After evaluating this "getValue" function, the parameter value will be intuitively set to:
<parameter>Satoshi Hada</parameter>The context node is the node for which the access request is evaluated when this getValue function is evaluated. Therefore the context node is determined in the evaluation time. See Example 2. |
| getAttribute |
| When the node for which the access request is evaluated is an element node then this function returns the value of the attribute attached to the element. When it is an attribute node, this function returns the value of the attribute attached to the owner element. |
| getDate | None. | Returns a text node representing the current date/time. |
A <policy> element consists of one or more <xacl> elements, an <xacl> element consists of one or more <rule> elements, and a <rule> element consists of one or more <acl> elements. One or more target <object> elements are specified for each <xacl> element. This means that one can specify multiple access control rules and acls for fixed target nodes. All these access control rules and acls are applied to the target nodes. This may be useful when you want to specify different rules and acls for different actions (for fixed target nodes).
In an <acl> element, zero or more subjects, one or more actions, and an optional condition are specified. An <acl> element says that all the specified subjects (if no subject is specified, it means an arbitrary subject) are to be authorized (or unauthorized) to execute all the specified actions (although they may be associated with provisional actions) on all the nodes specified in the <object> elements if the specified condition is satisfied. So intuitively one
Therefore, an access request matches an acl if:
<xacl>, <rule>, and <acl> elements may have an optional "precedence" attribute. This attribute is used to specify a precedence value. Smaller value means higher prececence (0 means the highest precedence). These values may be used for propagation so that acls with higher precedence override acls with lower precedence. The default precedence value of <xacl> elements is 0. The precedence of an <xacl> element is propagated downward to a child <rule> element whose value is omitted. Analogously, the precedence of a <rule> element is propagated downward to a child <acl> element whose value is omitted.
<xsd:element name="policy">
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="ac:property" minOccurs="0" maxOccurs="1"/>
<xsd:element ref="ac:xacl" minOccurs="1" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="property">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="action_definition" minOccurs="1" maxOccurs="unbounded">
<xsd:complexType>
<xsd:attribute name="name" type="xsd:string" use="required"/>
<xsd:attribute name="policy" type="xsd:IDREF" use="required"/>
</xsd:complexType>
</xsd:element>
<xsd:element name="policy_definition" minOccurs="1" maxOccurs="unbounded">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="propagation_along_oh" type="ac:propagationPolicyType" minOccurs="0" maxOccurs="4"/>
<xsd:element name="propagation_along_rh" type="ac:propagationPolicyType" minOccurs="0" maxOccurs="4"/>
<xsd:element name="propagation_along_gh" type="ac:propagationPolicyType" minOccurs="0" maxOccurs="4"/>
<xsd:element name="conflict_resolution" minOccurs="0" maxOccurs="1">
<xsd:complexType>
<xsd:attribute name="name" use="required">
<xsd:simpleType>
<xsd:restriction base="xsd:string">
<xsd:enumeration value="dtp"/>
<xsd:enumeration value="gtp"/>
<xsd:enumeration value="ntp"/>
<xsd:enumeration value="error"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:attribute>
</xsd:complexType>
</xsd:element>
<xsd:element name="default" minOccurs="0" maxOccurs="1">
<xsd:complexType>
<xsd:attribute name="permission" use="required">
<xsd:simpleType>
<xsd:restriction base="xsd:string">
<xsd:enumeration value="grant"/>
<xsd:enumeration value="deny"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:attribute>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
<xsd:attribute name="id" type="xsd:ID" use="required"/>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:complexType name="propagationPolicyType">
<xsd:attribute name="direction" use="required">
<xsd:simpleType>
<xsd:restriction base="xsd:string">
<xsd:enumeration value="upward"/>
<xsd:enumeration value="downward"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:attribute>
<xsd:attribute name="permission" use="required">
<xsd:simpleType>
<xsd:restriction base="xsd:string">
<xsd:enumeration value="grant"/>
<xsd:enumeration value="deny"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:attribute>
<xsd:attribute name="name" use="required">
<xsd:simpleType>
<xsd:restriction base="xsd:string">
<xsd:enumeration value="no"/>
<xsd:enumeration value="override"/>
<xsd:enumeration value="no_override"/>
<xsd:enumeration value="precedence"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:attribute>
</xsd:complexType>
<xsd:element name="xacl">
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="ac:object" minOccurs="1" maxOccurs="unbounded"/>
<xsd:element ref="ac:rule" minOccurs="1" maxOccurs="unbounded"/>
</xsd:sequence>
<xsd:attribute name="id" type="xsd:ID" use="optional"/>
<xsd:attribute name="precedence" type="xsd:unsignedByte" default="0"/>
</xsd:complexType>
</xsd:element>
<xsd:element name="rule">
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="ac:acl" minOccurs="1" maxOccurs="unbounded"/>
</xsd:sequence>
<xsd:attribute name="id" type="xsd:ID" use="optional"/>
<xsd:attribute name="precedence" type="xsd:unsignedByte" use="optional"/>
</xsd:complexType>
</xsd:element>
<xsd:element name="acl">
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="ac:subject" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element name="action" minOccurs="1" maxOccurs="unbounded">
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="ac:provisional_action" minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
<xsd:attribute name="name" type="xsd:string" use="required"/>
<xsd:attribute name="permission" use="required">
<xsd:simpleType>
<xsd:restriction base="xsd:string">
<xsd:enumeration value="grant"/>
<xsd:enumeration value="deny"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:attribute>
</xsd:complexType>
</xsd:element>
<xsd:element name="condition" minOccurs="0" maxOccurs="1">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="predicate" minOccurs="0" maxOccurs="unbounded">
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="ac:parameter" minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
<xsd:attribute name="name" type="xsd:string" use="required"/>
</xsd:complexType>
</xsd:element>
<xsd:element name="condition" minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
<xsd:attribute name="operation" use="required">
<xsd:simpleType>
<xsd:restriction base="xsd:string">
<xsd:enumeration value="and"/>
<xsd:enumeration value="or"/>
<xsd:enumeration value="not"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:attribute>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
<xsd:attribute name="id" type="xsd:ID" use="optional"/>
<xsd:attribute name="precedence" type="xsd:unsignedByte" use="optional"/>
</xsd:complexType>
</xsd:element>
|
A <policy> element also may have a single <property> element. This element consists of one or more <action_definition> and <policy_definition> elements. An <action_definition> element is used to define an action used in the policy. The required "policy" attribute is used to refer to a <policy_definition> element in which the propagation, conflict resolution and default policies for the action are specified. <propagation_along_oh>, <propagation_along_rh>, <propagation_along_gh>, <conflict_resolution>, and <default> elements are used to specify them. Note that any <policy_definition> element can be referred to by multiple action definitions.
See below for the default policy definitions of the four built-in actions and other actions. You can override the default policy definitions by re-defining them in <action_definition> elements.
As described before, both objects and subjects have hierarchical structure. Access decisions or acls are propagated along the hierarchies. XACL supports both upward and downward propagation. Take for example the propagation along the (element-based) object hierarchy. In case of upward propagation, an access decision (or an acl) for an element and an attribute is propagated upward to the parent element and the owner element, respectively. In case of downward propagation, an access decision (or an acl) for an element is propagated downward to its attributes and child elements.
The <propagation_along_oh> element is used to specify propagation policies. XACL supports four types of propagation policies (no, overriding, no_overriding, and precedence). XACL allows us to specify different policies for different directions (downward or upward), actions (read, write, or etc), and permissions (grant or deny).
The <propagation_along_rh> and <propagation_along_gh> elements are used to specify propagation policies along the role and group hierarchies, respectively. XACL supports only two propagation policies (no and precedence). XACL allows us to specify different policies for different directions (downward or upward), actions (read, write, or etc), and permissions (grant or deny). Although the semantics are similar to the one along the object hierarchy, they are different. Access decisions and acls are propagated along the object hierarchy while only acls are propagated along the subject hierarchy. See Access Evaluation for more deitals.
The following table summarizes the semantics of the four types of propagation policies, where it is described how an access decision for O1 is propagated to O2 and how an acle for S1 is propagated to S2, in general. The semantics is common to upward and downward propagation. For example, in case of downward propagation, O1 and O2 may be an element and an attribute of it, respectively. S1 and S2 may be a group and a subgroup of it, respectively.
| Name | Semantics |
|---|---|
| no |
Nothing is propagated.
|
| override |
An access decision for X1 is propagated to X2 regardless of the presence of the decision for X2 and the original decision for X2 are ignored if any. That is, the decision for X1 unconditionally overrides the decision for X2. For example, assume that X1 is an element and X2 is the parent element of X1. Furthermore assume that we have an access decision, which says that you can delete X2 but you cannot delete X1. In this case, the "deny" permission for the child X2 is propagated upward to the parent X1 so that you can no longer delete X1 (even though there is an acl that says you can delete X1). Acls for X1 are propagated to X2 regardless of the presence of an acl for X2 and the acl for X2 is ignored if any. That is, the acls for X1 unconditionally override any for X2. |
| no_override |
An access decision for X1 is propagated to X2 only if X2 has no decision yet. For example, assume that X1 is an element and X2 is a child element of X1. Furthermore assume that we have an access decision, which says that you can read X1, and that we have no specific acl for X2. Then the "grant" permission for X1 is propagated to X2 so that you can read X2 as well. Acls for X1 are propagated to X2 only if X2 has no specific acl. |
| precedence |
An access decision for X1 is propagated to X2 regardless of the presence of the decision for X2 and the decision with higher precedence is taken. Acls for X1 (S1) is propagated to X2 (S2) regardless of the presence of acls for X2 (S2) and the acls with the highest precedence are taken. |
As described above, XACL provides a very flexible propagation mechanism for the object hierarchy (although the propagation along the subject hierarchy must be based on precedence). However, not all the combinations of propagation policies are supported. So XACL requires the propagation policy along the object hierarchy satisfies either of the following two conditions:
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 four types of conflict resolution policies for each action. The default conflict resolution policy is "dtp" for every action.
When there is no permission (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 can be specified in the <default> element for each action. The default policy is "deny" by default for every 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 xmlns="http://www.trl.ibm.com/projects/xml/xacl">
<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 xmlns="http://www.trl.ibm.com/projects/xml/xacl">
<xacl>
<object href="/contents/list/entry"/>
<rule>
<acl>
<action name="read" permission="grant"/>
<condition operation="and">
<predicate name="compareStr">
<parameter value="eq"/>
<parameter>
<function name="getValue">
<parameter value="./name"/>
</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 xmlns="http://www.trl.ibm.com/projects/xml/xacl">
<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 xmlns="http://www.w3.org/2000/09/xmldsig#">
<CanonicalizationMethod
Algorithm="http://www.w3.org/TR/2000/CR-xml-c14n-20001026"/>
<SignatureMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<Reference>
<Transforms>
<Transform
Algorithm="http://www.w3.org/TR/2000/CR-xml-c14n-20001026"/>
</Transforms>
<DigestMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
</Reference>
</SignedInfo>
</parameter>
</provisional_action>
</action>
<condition operation="and">
<predicate name="compareStr">
<parameter value="eq"/>
<parameter><function name="getUid"/></parameter>
<parameter>
<function name="getValue">
<parameter value="name"/>
</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 the schema of the access request. An initiator must specify all three of object, subject, and action. The specified object must identify a unique node (an element or an attribute).
<xsd:element name="access_req">
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="ac:object" minOccurs="1" maxOccurs="1"/>
<xsd:element ref="ac:subject" minOccurs="0" maxOccurs="1"/>
<xsd:element name="action" minOccurs="1" maxOccurs="1">
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="ac:parameter" minOccurs="0" maxOccurs="1"/>
</xsd:sequence>
<xsd:attribute name="name" type="xsd:string" use="required"/>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
<xsd:attribute name="type" use="required">
<xsd:simpleType>
<xsd:restriction base="xsd:string">
<xsd:enumeration value="query"/>
<xsd:enumeration value="execute"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:attribute>
</xsd:complexType>
</xsd:element>
|
Here is the schema of list of access decisions. It contains the original access request as well as resulting access decisions (<decision> elements). Each decision consists of a "permission" attribute, an "href" attribute specifying the XPath of a node, and optional provisional action elements. It means that the subject specified in the access request is (or is not) authorized to execute the action specified in the request on the node if the provisional actions are executed.
<xsd:element name="decision_list">
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="ac:access_req" minOccurs="1" maxOccurs="1"/>
<xsd:element name="decision" minOccurs="0" maxOccurs="unbounded">
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="ac:provisional_action" minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
<xsd:attribute name="href" type="xsd:string" use="required"/>
<xsd:attribute name="permission" use="required">
<xsd:simpleType>
<xsd:restriction base="xsd:string">
<xsd:enumeration value="grant"/>
<xsd:enumeration value="deny"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:attribute>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
|
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 child elements 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. In case of read action, it is often the case that different nodes in the subtree of the target element have different provisional actions. All these provisional actions must be executed. | A view is created when the requested action is "read". The view contains only those nodes that the initiator is authorized to read. |
We describe four algorithms for the access evaluation.
|
Algorithm: Matching Input: An access request <access_req> Output: A decision list <decision_list>
|
The following is the conflict resolution algorithm, which does not use precedence values at all.
|
Algorithm: Conflict Resolution Input/Output: A decision list <decision_list>
|
The following is the basic evaluation algorithm that uses the above matching and conflict resolution algorithms. This algorithm deal with both propagation and conflict resolution, where precedence values are not used at all. This algorithm outputs exactly one access decision.
|
Algorithm: Basic Evaluation Input: An access request <access_req> Output: Exactly one decision, i.e., one permission (grant or deny) with possibly one or more associated provisional actions Step 1: Find the Applicable Acls
In Case 2, skip this step (since the propagation processing has been done in the Matching algorithm), otherwise, enforce the propagation policy as follows (The non-precedence-based propagation along the object hierarchy is processed here):
|
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 xmlns="http://www.trl.ibm.com/projects/xml/xacl" type="query">
<object href="/contents/list/entry[2]"/>
<subject>
<uid>Alice</uid>
</subject>
<action name="read"/>
</access_req>
<decision_list xmlns="http://www.trl.ibm.com/projects/xml/xacl">
<access_req type="query">
<object href="/contents/list/entry[2]"/>
<subject>
<uid>Alice</uid>
</subject>
<action name="read"/>
</access_req>
<decision href="/contents/list/entry[2]" permission="deny"/>
<decision href="/contents/list/entry[2]/name" permission="deny"/>
<decision href="/contents/list/entry[2]/officeTel" permission="deny"/>
<decision href="/contents/list/entry[2]/homeTel" permission="deny"/>
</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".
Here is the schema for access request, policy, status, and decision list.
| [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,'' 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," 7th ACM Conference on Computer and Communication Security, 2000. |
| [KH01] | M. Kudo and S. Hada, "Access Control Model with Provisional Actions," 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. |
| [Schema1] | World Wide Web Consortium (W3C), "XML Schema Part 1: Structures," http://www.w3.org/TR/xmlschema-1/, W3C Recommendation 2 May 2001. |
| [Schema2] | World Wide Web Consortium (W3C), "XML Schema Part 2: Datatypes," http://www.w3.org/TR/xmlschema-2/, W3C Recommendation 2 May 2001. |
| [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 Recommendation 12 February 2002. |