KR101007681B1 - Method of Evaluation of Predicates for Access Control - Google Patents

Abstract

Disclosed are a conditional calculation method for access control. The method of calculating a conditional expression for access control includes detecting a first node corresponding to the first conditional expression in a conditional graph, determining whether a result value of the first node is determined, and determining a result value of the first node. And extracting the resultant value as the result value of the first conditional expression. According to the present invention, the same partial conditional expression is prevented from being repeatedly calculated, thereby reducing the load on the electronic device and reducing the time required for the access control rule.

XML, XForms, XPath, Access Control, Conditional Expression

Description

Conditional expression calculation method for access control {Method of Evaluation of Predicates for Access Control}

The present invention relates to a method of calculating a conditional expression for access control, and more particularly, to a method of efficiently calculating avoiding iterative calculation of a shared conditional expression for access control.

 XML (eXtensible Markup Language) access control was handled mainly on the server, allowing only limited data access to the user. Recently, however, the concept of allowing selective actions with user interface elements as the target of access control has been introduced around the web-based system. In particular, access control techniques are often used to create pages that match the user's rights in a website. A server-based technique for describing access control on XML data through an access control rule using XPath, a query language for XML trees, and generating a web page is known.

Meanwhile, with the spread of service-based architecture, XForms-based client design method, the next generation web form language standard, has appeared as a useful method for describing communication with web servers. An XForms page can be viewed as a set of queries for an XML model instance, and can be viewed as a browser or client application processing the query in the order of the interface elements.

According to the conventional method, in calculating a conditional expression to apply an access control rule using XPath, even if the same partial conditional expression is used as part of several conditional expressions, it is calculated repeatedly for each conditional expression, thereby burdening the central processing unit or other components. There is a problem that the time required until the application of the access control rule is completed is delayed.

SUMMARY OF THE INVENTION The present invention has been made to solve the above-described problem, and an object thereof is to reduce the load on the electronic device and shorten the time required for an access control rule by preventing the same partial conditional expression from being repeatedly calculated.

According to one aspect of the invention there is provided a conditional calculation method for access control.

According to an exemplary embodiment of the present invention, a method of calculating a conditional expression for access control includes detecting a first node corresponding to a first conditional expression in a conditional graph, determining whether a result value of the first node is determined, and When the result value is determined, the method may include extracting a result value of the first node as a result value of the first conditional expression.

According to the present invention, the same partial conditional expression is prevented from being repeatedly calculated, thereby reducing the load on the electronic device and reducing the time required for the access control rule.

Hereinafter, exemplary embodiments of a method for calculating a shared conditional expression for XML data access control according to the present invention will be described in detail with reference to the accompanying drawings. In the following description with reference to the accompanying drawings, the same or corresponding components are the same drawings. The numbering and duplicate description thereof will be omitted.

1A is an exemplary diagram of a task list XML tree.

1B is an illustration of a DTD tree.

The example task list XML tree 100 and the example DTD tree 150 have structures corresponding to each other.

For convenience, the attributes of the instance node and the name of the node in the example task list XML tree are only represented by the first one or two letters. @ Represents an attribute.

For example, the @author node 151 of the DTD tree and the @author node 111 of the XML instance tree may correspond to each other.

Example Task List In the ellipse of the XML tree 100, an attribute name or an element name is written, and a corresponding attribute value or element content is written outside the circle.

The @author node 111, which is a child node of the first task 110, represents the author attribute 151 and the author attribute of the first task 110 has a value of 'seo'.

A description node 112, which is a child node of the first task 110, represents a description element 152, and the description element of the first task 110 has content starting with 'SU-'.

XML data instance is a tree and tree T _XML It can be expressed as = ( N _XML , E _XML ) . N _XML represents a node included in the XML instance tree, and E _XML represents an edge included in the XML instance tree. Node x ∈ N _XML can be either a terminal node that is a node with text () (a text node, a node whose content is text) or an internal node. Attributes can be treated as terminal nodes.

Schema can be defined as DTD (Document Type Definition) tree D = ( N _DTD , E _DTD ) . N _DTD is a node of the DTD tree and E _DTD is an edge of the DTD tree. The recursive element definition of a DTD can be removed by extending the path of the DTD tree to the same depth as the XML instance tree. This method can ensure that the depth does not exceed the depth of the XML instance tree without the DTD tree having recursion.

The set L can be said to be a set of node labels defined in the tree D. Mapping l to node label is defined for node x in XML instance tree and node v in DTD tree, so l (x) ∈ L and l (v) ∈ L. The consecutive p ∈ L * of the node labels are called paths, and the paths from root for paths x and v in the XML and DTD trees are path (x) and path (v) , respectively. Here '*' is used as the Kleene star or Kleene closure used in regular expressions. A set of descendant nodes in the tree can be defined with the descend function for a given path p descend L * and expressed as descend (v, p) ⊂ N _DTD , descend (x, p) ⊂ N _XML . If tree T is a valid tree for tree D, then map to N _XML M _{X-> D} (x) = {v ∈ D | path (v) = path (x), x ∈ N _XML } can be defined.

2A and 2B are exemplary views of a user interface screen provided according to an embodiment of the present invention.

Given the access rules, the browser system can configure the screen according to the permissions, such as showing only the data items that are allowed, or just text if the input control does not have write permission and only read permission. Buttons such as add or delete can only be activated if the permission is granted.

2A and 2B, the SU task is visible to both user seo and kim, but seo can modify all fields and kim can only read. In addition, seo can only read BOU tasks, but can add comments.

XForms is the World Wide Web Consortium (W3C) standard. XForms is an XML application that represents the next generation of forms for the Web. By dividing the traditional Extensible HyperText Markup Language (XHTML) form into three parts: the XForms model, instance data, and the user interface, the expression was separated from the content, allowing reuse, providing device independence and reducing the need for scripting.

XForms is not a document type used by itself, but is intended to be used with other markup languages such as XHTML or Scalable Vector Graphics (SVG).

A detailed description of XForms is available on the web at http://www.w3.org/TR/xforms.

When an XForms element is bound to an XML instance element, access rights can determine whether the action is allowed. The elements can be computed in the order in which they appear on the screen. An XForms element can be allowed or prohibited depending on the value of a user or context variable or on the value of an XML instance element.

XPath (XML Path Language) is a W3C standard that describes how to construct and process items using the syntax specified above the path through the structure of an extension-generated language document. It is easier and abbreviated than the XML representation, and is the language used for eXtensible Stylesheet Language (XSL) translation and XML Pointer Language (XPointer). XPath uses path expressions to define the nodes of an XML document, including mathematical functions and other extensible expressions.

A detailed description of XPath is available on the web at http://www.w3.org/TR/xpath20/.

The XPath formula used in this specification may be defined as follows.

XPath p can be defined as:

p = p | p '*' | p '//',

p : = p '/' p | l [ expr ] | l, l ∈ L

Expr condition can be defined as follows:

expr : = expr op expr | term , term : = p | value | variable ,

Where op is a logical or comparison operator value and variable can represent literal values and variable names starting with $, respectively.

'*' Is used to mean wildcards as defined by XPath.

For example, / A / * can refer to all child nodes of A.

'//' refers to itself or its descendants, as defined by XPath.

For example, / A // can refer to A and all descendants of A.

Variables are used to refer to system-defined values in conditional expressions. For example, user ID, date, and time can be used as variables. Variables are usually determined before their XPath calculation, so they can be treated the same as literal values.

For convenience, the * or // appearing at the end of the XPath is indicated as 'tail'.

Path p = p ₀ e0 p ₁ . p _k e _k Set the result set of nodes for tail target (p) = {v ∈ N _DTD | path (v) matches p ₀ p ₁ . p _k tail } and the conditional formula is expr (p) = e ₀ and e ₁ . and e _k Can be displayed as The set of nodes represented by XPath p can be called answerset (p) . It must satisfy all the condition part for a given XML node x x satisfies p can be expressed as follows.

answerset (p) = {x | M _{X → D} (x) ∈ target (p) expr (p) is true for x}

The set of DTD nodes corresponding to the conditional expression e _i is base ( e _i ) = {w ∈ N _DTD | p ₀ p ₁ . pi = path (w)} .

To describe access control, rules can be expressed in terms of action type and target node set. A rule typically describes an allowable condition through a conditional expression that uses the value of an XML instance and the value of a context variable.

The action type for access control may be defined as T = {Read, Update, Create, Delete}. Read may mean read permission for the node. Update may mean an update authority for the node. Create may mean create permission of the node. Delete may mean the right to delete a node.

An access control rule can be represented by r = (t, p) , where t ∈ T, p is XPath. The set of access control rules is called an access control policy and can be denoted by P.

The access control policy can be assumed to list all operations that are restricted. By default, all access to all nodes is allowed, and access is restricted only to nodes that meet the access control rules included in the access control policy.

It is also possible to assume that some access control rules with a certain priority policy allow access to nodes that satisfy those rules, while others restrict access to nodes that satisfy those rules.

For convenience, it is assumed below that the access control policy lists all allowed operations. Basically, all access to all nodes is restricted, and it is assumed that only nodes satisfying the access control rules included in the access control policy are allowed access.

Table 1 is an example of an access policy for the XML tree of FIG. 1A.

r1 = (Create, / list / task)
r2 = (Delete, / list / task [@ author = $ user])
r3 = (Read, / list / task [@ level = 1 | @ author = $ user or (@level! = 3 and (group / user = $ user | @ super = $ user))] / *)
r4 = (Update, / list / task [@ author = $ user] / {@ type, @duedate, description, @level})
r5 = (Create, / list / task [@ author = $ user | (@level! = 3 & (group / user = $ user | @ super = $ user))) / comments / comment)
r9 = (Read, / list / task [@ author = $ user | (@level! = 3 & (group / user = $ user | @ super = $ user))] / comments / comment / *)

r1 means that it is allowed to create tasks that are children of the list node.

r2 means that if you want to delete a task that is a child of the list node, delete permission is allowed if the task's author property value is the same as the current user (which can be implemented as a web page login, etc.).

The r3 to r9 rules can also be understood as r1 and r2 according to the XPath standard.

XForms lets you write action templates in a language that describes the user interface. An action template is a template specification for user actions, and an XForms page is a collection of action templates. An action template can be expressed as at = (t, p) in the same way as an access rule.

In the XForms page, user interface elements such as input, select, and output are action templates. In addition, action elements such as insert and delete also represent action templates. The relationship between XForms elements and action types is as follows:

Type of action to respond to XForms elements e e. type can be expressed as:

if l (e) = output e. type = Read ,

if l (e) = input , select , textarea e. type = Update ,

If l (e) = delete, e. type = Delete ,

if l (e) = insert e. type = Create .

In order to simplify the relationship between XForms elements and action types, we've chosen insert and delete elements as action templates instead of triggers. In general, insert and delete elements appear as child elements of a trigger or submit.

In addition, interface elements such as group and repeat represent a structure that traverses the instance tree. Action template elements appear as children of this structure element. DTD nodes corresponding to the structure element may be referred to as template base nodes. Action template elements in XForms represent relative paths from the context base node with the ref or nodeset attributes. Action templates defined in the XForms language can be expressed as at = (t, v _b , ref ) for the action type t, the template base node v _b , and the relative path ref .

Table 2 shows part of the example XForms page code.

<table>
<xf: repeat ref = 'task'>
<tr>
<td><xf: input ref = '@ type'></td>
<td><xf: output ref = '@ author'></td>
<td><xf: input ref = 'description'></td>
<td><xf: input ref = '@ state'></td>
<td><xf:trigger><xf: delete ref = '.'/></ xf: trigger></td>
</ tr>
</ xf: repeat>

The XForms page code in Table 2 defines the @type, description, @state Update and @author Read actions, and the deletion of the task element. In Table 2, the template base node is a 'task' node.

An action instance can be created by binding an action template with an instance node. Even the same action template may have different access depending on the instance node. For example, the delete button of the task element on the screen of FIGS. 2A and 2B may be activated or deactivated according to the task.

FIG. 3 is part of a conditional graph for the XML example of FIGS. 1A and 1B and the access policy of Table 1. FIG.

A path automata A (P) can be created for a set P of XPaths. In this automata, each edge can represent the label of the node test portion, not the conditional expression. Assuming that XPath only allows * or // at the end, this automata will be a tree with some nodes of the DTD tree. Nodes belonging to target (p) of each XPath p in A (P) may be called final nodes. However, even if * or // is included at the end of the XPath, the present invention may be applied.

Conditional expressions in XPath can be represented by Boolean operations and in subconditions. For example, if p1 = / a / b [c = '1'] / d [e = '3'], then expr ( p1 ) = (c = '1') and (e = '3') . For an XML instance node x to be included in answerset (p) , x ∈ target (p) and x must satisfy expr (p) . whether or not x is satisfies the expr (p) is eval (expr (p), x ) is calculated in this subexpression e _i, for _1≤i≤m ∧ 1≤i≤m constituting the p True when eval ( e _i , x)

Not only do a large portion of conditional formulas be common between XPath rules, but the results of conditional formulas can often be reused between XML instance nodes. For example, in Table 1, the XPaths of the access rules share the conditional part of the value of the @level attribute.

In this case, a conditional graph representing all common conditional expression parts may be presented in order to reuse the calculation result of the partial conditional expression as much as possible.

The conditional graph may include a path node corresponding to the path expression (hexagonal node of FIG. 3), an operator node corresponding to the operator of the conditional expression, and a value node corresponding to the literal or variable.

The conditional graph may include an edge from the operator node to the node corresponding to the root of the operand subtree of the operator node of that operator node. A conditional graph is not a tree, but can be expanded into a tree if it only extends along the edge direction at one node, and the conditional graph can be viewed as a composite of several of these trees. Operand subtree refers to the tree from this point of view.

The result of an operator node can be a value calculated by using the operator of that operator node as an operator and the result of the root node of the operand subtree as an operand.

Each node in the conditional graph can hold the result of that node.

The result of an operator node can be the value of a conditional expression represented by a tree extending from the operator node along the edge direction.

The result of the path node may be the value of the node located in the path indicated by the path expression of the path node in the current context node. The value node can be a literal itself or a variable value itself. The context node refers to the node currently used for access control. For example, when an access control decision on an attribute or an element of the first task 110 is made, the context node is the first task 110 node.

The node of the conditional graph is initially in an undetermined state, and you can use '⊥' as a symbol. Later, the conditional expression corresponding to that node is calculated and the result of that node can be determined. If the result value included in the node of the conditional graph becomes invalid due to the change of the context node, the result value may become undetermined again.

For example, the operator of the first operator node 320 is | (or) and the node corresponding to the root of the operand subtree of the operator is the second operator node 321, the third operator node 310, and the fourth operator. Node 322. The edges from the first operator node 320 to the second to fourth operator nodes are the first edge 323, the second edge 324, and the third edge 325.

The conditional expression expr (p) for XPath p ∈ P { e ₁ , e ₂ ,... , e _m }, the conditional graph G (p) = ( Q _p , E _p , { q _p }) according to an embodiment of the present invention may be defined as follows.

i) Q _p = Q _op ∪ Q _lpath Represented by ∪ Q _value and can be, for each operator and the anti-node of the expression corresponds as follows.

A. Q _op = { q | nodes corresponding to the operators of and , or , op q },

B. Q _lpath = { q | lpath The node q } corresponding to the path expression,

C. Q _value = { q | Node q corresponding to literal value or variable v}

ii) for each subexpression e _i If ast ( e _i ) = ( Q ⁱ _p , E ⁱ _p , { q ⁱ _sp }) and q ∈ Q ⁱ _op, then the roots of the left and right operand subtrees of this operator are q _l and q _r , respectively. (Q, q _l ), (q, q _r ) ∈ E ⁱ _p can be added as an edge.

iii) ( q _p , q ⁱ _s ,) ∈ E ⁱ _p , 1 ≦ i ≦ m.

Here, the lpath path expression is a path expression except for the expr (p) part of the xpath path expression. For example, the lpath path expression of xpath p1 = / a / b [c = '1'] / d [e = '3'] could be / a / b / d.

Here, ast stands for abstract syntax tree and ast (e) can refer to a tree representing only the syntax of e.

For convenience of notation, ref (q) and base (q) can indicate relative paths and base context nodes when q ∈ Q _lpath . If the subcondition to which q belongs is e _i, then base (q) = base ( e _i ) . For example From 3 base ( l ₁ ) = v _task and base ( l ₂ ) = v _comment . Where l ₁ is an @level node 330 and l ₂ is a writer node 340.

On the other hand, when q ∈ Q _op op (q) is a comparison or logical operator.

When G ( p _k ) = ( Q _pk , E _{pk ,} { q _sk }), p _k ∈ P It can be said that N = ∪ ₁ ≤ _k ≤ _m Q _pk . Two nodes q ₁ , q ₂ ∈ When N meets the following conditions, it is called equal. Q ₁ ≡ q ₂ can be indicated.

i) base ( q ₁ ) = base ( q ₂ ) and

ii) if q ₁ , q ₂ ∈ Q _value value ( q ₁ ) = value ( q ₂ ),

iii) if q ₁ , q ₂ ∈ Q _lpath then base ( q ₁ ) = base ( q ₂ ) ref ( q ₁ ) = ref ( q ₂ ),

iv) q ₁ , q ₂ ∈ If Q _op, then p ( q ₁ ) = op ( q ₂ ) and q ₁ . left ≡ q ₂ . left and q ₁ . right ≡ q ₂ . right .

When the access policy is P = {( t ₁ , p ₁ ), ..., ( t _n , p _n )} , the conditional graph G = (Q, E, Q _start ) is the conditional graph G ( p of the individual XPath. _k ) = ( Q _pk , E _{pk ,} { q _sk }), Q = ∪ Q _pk , E = ∪ E _pk , Q _start for 1 ≤ k ≤ n = { Q _s1 , ..., Q _sn } where the nodes are equal to one another.

Given an access policy, you can create route automata and conditional graphs.

Access policy P = {( t _k , p _k ) | Suppose we have a graph G that combines the conditional graph G ( p _k ) of 1 ≤ k ≤ n} and p _k . In the conditional graph G ( p _k ) for the rule ( t _k , p _k ) , the starting node is q _k and the target node set is V _i = target ( p _i ) , the corresponding rule can be expressed as:

R = { ( t _k , V _k , q _k ) | V _k = target ( p _k ), 1 ≦ k ≦ n}.

3 is a representation of a path automata, a conditional graph, and access authority. The rectangles marked C, D, R, and U represent the add, delete, read, and modify permission rules, respectively. The rectangles marked C, D, R, and U are displayed on DTD nodes that allow this action.

The conditional expressions of these rules can be represented by nodes in the conditional graph. At this time, it can be seen that the nodes of the conditional graph are shared for the common partial conditional expression. Meanwhile, the conditional graph is divided into an operator node (circular node of FIG. 3), a path node (hexagonal node of FIG. 3), and a node having a literal value, and has one starting node for each rule. The start node is an operator node.

The access control of an action is a calculation to find out whether there is an access rule that satisfies bound XML data. On the other hand, the calculation of static access control examines the target node of the access rule and the target node of the action template without considering the XML data and conditional expression. It cannot be accessed without a corresponding rule for the action template.

Let's say that a given action template is at = (t, p) . If no rule r = ( t _r , V _r , q _r ) ∈ R satisfies t = t _r , target (p) ⊂ V _r, then at will not be accessible to any XML instance node.

Given an action template at = (t, p) and an XML instance x, let M _{X → D} (x) = v . Action instance at (x) can be allowed if the following conditions are met :

(1) an access rule that satisfies t = t _r , target (p) ∈ V _r, and r = ( t _r , V _r , q _r ) ∈ R

(2) evalExpr ( q _r , x) = true is satisfied.

4 is a block diagram of a client system according to an embodiment of the present invention.

The client system may have an access control module 420 that is independent of the user interface generation module, such as the browser 410, and may be responsible for calculating whether a given action instance is allowed. The XForms page 430 can hold user interface elements and server communication information. The browser 410 visits the XForms elements in turn and creates an action instance for all the XML data 440 bound to. In this case, the access control module can be queried whether or not to allow access by providing navigation information and context information for each action instance.

Table 3 includes an algorithm of an access right control process according to an embodiment of the present invention.

[Algorithm 1] Access Check (e, x, vb, v)
Input-e: XForms element
x: the current context node
vb: template base node
-v = M _{X → D} (x)
Output-returns true if the action instance is allowed access, false otherwise
static: xprev ← null
(1) reset (v, M _{X → D} (xprev))
(2) xprev ← x;
(3) if e.name ∈ {input, output, delete, insert, ...}:
(3-1) t ← e.type
(3-2) for all r = (t, Vr, qr) st v ∈ Vr
(3-2-1) if evalExpr (qr, v, x) return true;
(3-3) return false;

According to Algorithm 1, access control can be calculated using XForms element and context information. The access check function can check that the DTD context node has been changed in the next call, keeping the xprev variable. If changed, the reset function is called, which can reset the conditional expressions that have been invalidated among the preliminary calculated results for the new context node (algorithm 2). The evalExpr function also computes the conditional part corresponding to node qr in the conditional graph for the given instance node x. At this time, the reusable calculation result is not recalculated (Algorithm 3).

An XForms page is a tree of action templates structured as repeats or groups. If the calculation of access control follows the sequential visit order of the XML instance tree, much of the result of the conditional expression can be reused.

Action template at Given q (t, v) and contiguous binding instance nodes x ₁ , x ₂ , if q is computed for at (x ₁ ) , then at (x ₂ ) can reuse the computed result of q .

i) ∃ (t, V, q _s ) ∈ R st v ∈ V,

ii) q _s has a path to q

iii) base (q) is an ancestor of v and base (q) ≠ v

The general conditions for reusing the calculation result of the conditional node for any two action instances are as follows.

Given the action templates at ₁ = ( t ₁ , v ₁ ) and at ₂ = ( t ₂ , v ₂ ) and M _{X → D} (x ₁ ) = v ₁ , M _{X → D} (x ₂ ) = v ₂ Assume that the binding instance nodes x ₁ and x ₂ are given. If the conditional node q is computed for at ₁ (x ₁ ) and is valid, then at ₂ (x ₂ ) can reuse the computed result of q .

i) ∃ ( t ₁ , V ₁ , q _s1 ), ( t ₂ , V ₂ , q _s2 ) ∈ R st v ₁ ∈ V ₁ , v ₂ ∈ V ₂ ,

ii) q _s1 and q _s2 have paths to q

iii) base (q) ≠ v ₁ or v ₁ ≠ v ₂ and base (q) is a common ancestor of v ₁ and v ₂

Therefore, when a binding instance node changes, all calculations that are not reusable can be reset. That is, when the base node is not the ancestor of the new node among the conditional graph nodes, it may be reset. The intermediate calculation results can be divided into two types. Operator nodes have either true or false, and they have a value if they have not yet been computed or are not reusable. In addition, an lpath node may have a computed node set or have a value. For convenience of expression, the following can be defined for the nodes of the conditional graph.

nodeset (q) ⊂ N _XML or nodeset (q) = ⊥ if q ∈ Q _lpath

evalValue (q) ∈ { ⊥ , true , false } if q ∈ Q _op

Using the above result, the reset algorithm when the context node is changed is as follows. The reset algorithm may receive, as input, a DTD node corresponding to the original context node x1 and the new context node x2. The same case of two DTD nodes entered is when another instance node is bound to the same action template. If v1 and v2 are different, the action template is changed or moved to another interface element such as repeat or group.

Table 4 includes algorithms for resetting conditional nodes that need to be reset when the context node changes.

[Algorithm 2] reset (v1, v2)
Input-conditional graph G = (Q, E, Qstart),
Old and current template base nodes v1 and v2
Output-resets invalidated conditional nodes
(1) if v1 = null or v1 is an ancestor of v2, then return;
(2) if v1 ≠ v2, w ← common ancestor node of v1, v2;
(2-1) else w ← v1.parent;
(3) v ← v2;
(4) repeat
(4-1) for all q ∈ Q _lpath st base (q) = v,
(4-1-1) nodeset (q) ← ⊥;
(4-1-2) for all q 'st (q', q) ∈ E
(4-1-2-1) evalValue (q ') ← ⊥;
(4-2) v ← v.parent;
(5) until v ≠ w;

Table 5 contains algorithms for calculating whether conditional subexpressions are true.

For a given conditional graph node q , a context-based DTD node v , and an XML instance node x , the algorithm in Table 5 calculates whether the conditional subexpression corresponding to q is true for x .

Algorithm 3 evalExpr (q, v, x)
Input-q ∈ V, G = (Q, E, Q _start ) is a conditional graph,
-v ∈ N _DTD (Template base node)
x: An XML instance node that satisfies M _{X → D} (x) = v
Output-returns true if the subcondition for q is satisfied for x, false otherwise
(1) result ← false;
(2) if evalValue (q) ≠ unknown, return evalValue (q).
(3) if q ∈ Q _start ,
(3-1) result ← true;
(3-2) for all q '∈ next (q),
(3-2-1) if eval_expr (q ', x) = false
(3-2-1-1) result ← false; break;
(4) if q ∈ Q _lpath ,
(4-1) if nodeset (q) = unknown
(4-1-1) nodeset (q) ← evalNodeSet (q, x)
(4-2) result ← (nodeset (q) ≠ Φ)
_{(5) if q ∈ Q op} and op (q) ∈ {and, or},
(5-1) Let q _left , q _right ∈ next (q),
(5-2) result ← op (q) (evalExp (q _left , x), evalExpr (q _right , x)).
(6) if q ∈ Q _op and op (q) is an comparative operator,
(6-1) pathdiff ← path (v, base (q _left ));
(6-2) for all x'∈ decsendent (x, pathdiff);
(6-2-1) for all x "∈ evalNodeSet (q _left , x ')
(6-2-1-1) if op (q) (x ", q _right )
(6-2-1-1-1) result ← true;
(6-2-1-1-2) break;
(7) evalValue (q) ← result;
(8) return result;
evalNodeSet (q, x) = descendents (x, lpath (q))

Algorithms 1, 2, and 3 above can process XForms elements in the following steps:

i) The repeat or group node sets up a new context node.

ii) If the context node changes, reset the invalidation result through the reset function.

iii) Calculate whether or not the action template element is bound to access to the action node for the action template element. At this time, the node with the calculated value is used as it is.

iv) In each calculation step, the calculation result is set in the conditional graph node.

Table 6 shows the calculation or reuse of conditional nodes for the xml nodes bound by XForms elements for the XForms page portion of Table 2 and the xml tree instance in Figure 1.

Target node
Relative path Binding context node Calculation Node recycle reset result repeat task task task SU input (*) @type R4 c, d X output (**) @type R3 a, b, e O input @state R4 d X output @state R3 e O output @author R3 e O ... insert comments / comment R7 f, g, h, k, m, n d X delete . task BP R2 d X task BP a, c, f-> b, d, g,
-> e, h, m, n input @type R4 f, c X output @type R3 e, b, a X

5A to 5C are graphs showing performance test results of the method for calculating an access control rule according to an embodiment of the present invention.

5A illustrates the number of conditional graph nodes according to the number of access control rules.

5B shows the number of shares of the conditional graph node according to the number of access control rules.

 5C shows the number and rate of reuse nodes as the number of action instances of an XForms page increases. As shown in this graph, we can see that the calculation result of the proposed conditional graph is calculated once and then reused when the binding context node changes.

The access control method according to an embodiment of the present invention can be applied as an adaptive user interface technique. For example, if the action template element for Update is denied access (see Table 6 (*)), it can be recalculated with the Read operation to see if it is possible to show the data without providing any modifications. **)). On the other hand, if the browser does not allow all user interface elements to be included for groups, repeats, etc., it is possible to hide the whole. For example, in Table 6, it is possible to omit the entire repeat because the action instances of all xforms elements for task BP are rejected. This can be implemented by extending the call to the access control module in the browser.

The present invention can also be applied to an eXtensible Stylesheet Language (XSL), an eXtensible User Language (XUL), or another user interface description language based on XML. The present invention is applicable to all system models that view user interface elements as action templates and calculate access rights to XML data. In addition, the proposed XPath-based user interface access control method can be used in the field for adaptive user interface generation.

6 is a flowchart of a conditional expression calculation process according to an embodiment of the present invention.

In operation S605, a first node corresponding to the first conditional expression may be detected in the conditional graph. As the detection method, a method using a hash or the like can be considered.

The conditional graph includes a path node corresponding to a path expression, an operator node corresponding to an operator of the conditional expression, a value node corresponding to a literal or variable, and an edge from the operator node to a node corresponding to a subexpression of the conditional expression corresponding to the operator node. may include edges.

The method of generating the conditional graph is as described above.

In operation S610, it is determined whether a result value of the first node is determined.

For example, the result node corresponding to the conditional expression '@ author = $ user' in '/ list / task [@ author = $ user]' which is the XPath of r2 of Table 1 is the first node 310 of FIG. 3. When the result value of the first node 310 is determined, the process may proceed to step S630.

When the result value included in the first node is ⊥ (not determined), the process may proceed to step S620.

In operation S620, the first conditional expression may be calculated and the conditional graph may be updated.

FIG. 7 is a detailed flowchart of step S620 of FIG. 6.

In step S710, it is determined whether the first conditional expression is a literal or a variable.

When the first conditional expression is a literal or a variable such as 'true' or '$ user', the process may proceed to step S720. In the opposite case, the process may proceed to step S730.

In operation S720, a literal value or a variable value may be extracted as a result value of the first conditional expression.

For example, when the first conditional expression is '$ user', the current user name may be a result value of the first conditional expression.

In the case of r1 in Table 1, '/ list / task' is given without any condition. In this case, the literal value 'true' (true) may be regarded as a conditional expression. In this case, the true value may be a result of the first conditional expression.

In operation S730, a second node, which is a node having an edge emerging from the first node, may be extracted. The second node corresponds to the root node of the operand tree of the first node.

Since the first conditional expression is not a literal or the variable itself, it may include an operator. Here, the operator may include an and, or operator and a comparison operator.

For example, 'true and false' includes the and operator, and can be split into two subconditions, 'true' and 'false'.

If there are multiple operators in the condition, the condition can be split based on the operator with the lowest priority. If the priority of and in the conditional expression 'A and B or C' is higher than the priority of or, the conditional expression may be split based on or and divided into two partial conditional expressions, 'A and B' and 'C'.

Multiple operators with the same priority may be split into three or more subconditions. The conditional expression 'A or B or C' may be divided into three subconditions of 'A', 'B' and 'C' by dividing the conditional expression based on two or's.

Even when a divided subexpression does not have a value of true or false, it is called a partial condition for convenience.

The second node is a node corresponding to the subcondition of the first node.

In operation S740, a result value of the second node may be calculated.

The resultant value of the second node may be calculated in the same manner as the resultant value calculation of the first conditional expression.

Even if there is more than one second node, it is not necessary to calculate the result of every second node. For example, if the result value of 'A' is true for the conditional expression of 'A or B', it is because the result value of the entire conditional expression is true without calculating the result value for B.

In operation S750, the result value of the first conditional expression may be calculated based on the result value of the second node.

In operation S760, the result value corresponding to the first conditional expression may be updated with the result value of the first conditional expression.

For example, if the result value of the '@ a = $ u' conditional expression included in the r2 control rule of Table 1 is calculated and the result value is true, the result value of the first node 310 corresponding to the conditional expression is true. Can be updated to true.

In operation S630, a result value of the first node may be extracted as a result value of the first conditional expression.

For example, if the result value of the first node 310 corresponding to the '@ author = $ user' conditional expression included in the r2 control rule of Table 1 is true, the result value of the conditional expression is true. Can be. Since the calculation for this conditional expression has already been performed, the result can be used as it is.

When the context node is changed in step S650, the result value of the node whose result value may be changed by changing the context node among the value nodes included in the conditional graph may be updated to ⊥ (undetermined state).

For example, when the conditional calculation is performed on the first task 110 of FIG. 1A, the conditional graph is generated and updated, and the context node is changed to the next task, the second task, the attribute value and the element value of the context node may be changed. have. For example, the type attribute of the first task 110 is project but the type attribute of the second task 120 is personal. In this case, the result value of the conditional expression containing the type attribute cannot be used as it is, and it must be newly calculated. All newly calculated results can be updated to ⊥ (undetermined).

In some embodiments, when the context node is changed, the result values of all nodes of the conditional graph may be updated to ⊥ (undetermined state).

Which node should be updated may be determined in the same manner as the algorithm of Table 4.

Action template at Given q (t, v) and contiguous binding instance nodes x ₁ , x ₂ , if q is computed for at (x ₁ ) , then at (x ₂ ) can reuse the computed result of q .

i) ∃ (t, V, q _s ) ∈ R st v ∈ V,

ii) q _s has a path to q

iii) base (q) is an ancestor of v and base (q) ≠ v

The general conditions for reusing the calculation result of the conditional node for any two action instances are as follows.

Given the action templates at ₁ = ( t ₁ , v ₁ ) and at ₂ = ( t ₂ , v ₂ ) and M _{X → D} (x ₁ ) = v ₁ , M _{X → D} (x ₂ ) = v ₂ Assume that the binding instance nodes x ₁ and x ₂ are given. If the conditional node q is computed for at ₁ (x ₁ ) and is valid, then at ₂ (x ₂ ) can reuse the computed result of q .

i) ∃ ( t ₁ , V ₁ , q _s1 ), ( t ₂ , V ₂ , q _s2 ) ∈ R st v ₁ ∈ V ₁ , v ₂ ∈ V ₂ ,

ii) q _s1 and q _s2 have paths to q

iii) base (q) ≠ v ₁ or v ₁ ≠ v ₂ and base (q) is a common ancestor of v ₁ and v ₂

Therefore, when a binding instance node changes, all calculations that are not reusable can be reset. That is, when the base node is not the ancestor of the new node among the conditional graph nodes, it may be reset. The intermediate calculation results can be divided into two types. Operator nodes have either true or false, and they have a value if they have not yet been computed or are not reusable. In addition, an lpath node may have a computed node set or have a value.

In operation S660, an action instance may be generated according to the result value of the first conditional expression and the action template.

According to the conditional expression result of the access control policy as shown in Table 1, the action templates as shown in Table 2 can be modified or read / deleted / created by the user as shown in FIGS. 2A and 2B. Can be expressed.

The deletion of the node may be implemented when the result of the node is not determined. If the result value of a node becomes invalid, the node is deleted. If the result value is calculated later, the node is added to the conditional graph.

The terminology used herein is for the purpose of describing particular example embodiments only and is not intended to be limiting of the present invention. Singular expressions include plural expressions unless the context clearly indicates otherwise.

In this application, the terms "comprise" or "having" are intended to indicate that there is a feature, number, step, operation, component, part, or combination thereof described in the specification, and one or more other features. It is to be understood that the present invention does not exclude the possibility of the presence or the addition of numbers, steps, operations, components, components, or a combination thereof.

The terms first, second, etc. may be used to describe various components, but the components should not be limited by the terms. The terms are used only for the purpose of distinguishing one component from another.

Embodiments of the invention may include computer readable media containing program instructions for performing various computer-implemented operations. The computer readable medium may include program instructions, local data files, local data structures, or the like, alone or in combination. The media may be those specially designed and constructed for the purposes of the present invention, or they may be of the kind well-known and available to those having skill in the computer software arts.

So far I looked at the center of the present invention with respect to the embodiment. Many embodiments other than the above-described embodiments are within the scope of the claims of the present invention. Those skilled in the art will appreciate that the present invention can be implemented in a modified form without departing from the essential features of the present invention. Therefore, the disclosed embodiments should be considered in descriptive sense only and not for purposes of limitation. The scope of the present invention is shown in the claims rather than the foregoing description, and all differences within the scope will be construed as being included in the present invention.

1A is an exemplary diagram of a task list XML tree.

1B is an illustration of a DTD tree.

2A and 2B are exemplary views of a user interface screen provided according to an embodiment of the present invention.

FIG. 3 is part of a conditional graph for the XML example of FIGS. 1A and 1B and the access policy of Table 1. FIG.

4 is a block diagram of a client system according to an embodiment of the present invention.

5A to 5C are graphs showing performance test results of the method for calculating an access control rule according to an embodiment of the present invention.

6 is a flowchart of a conditional expression calculation process according to an embodiment of the present invention.

FIG. 7 is a detailed flowchart of step S620 of FIG. 6.

Claims (12)

In the conditional calculation method for access control, Detecting a first node corresponding to the first conditional expression in the conditional graph; (a) determining whether a result value of the first node is determined; And (b) if the result value of the first node is determined, extracting the result value of the first node as a result value of the first conditional expression, The conditional graph is directed to a path node corresponding to a path expression, an operator node corresponding to an operator of the conditional expression, a value node corresponding to a literal or variable, and a node from the operator node to a node corresponding to a subcondition of the conditional expression corresponding to the operator node. Conditional expression calculation method including edges. delete The method of claim 1, (c) if the result value of the first node is not determined, extracting a second node, which is a node facing an edge from the first node; (d) calculating a result of the second node; And (e) calculating a result value of the first conditional expression based on the result value of the second node. The method of claim 3, The step (d) Determining whether a result value of the second node is determined; And Extracting a result value of the second node as a result value of the subcondition when the result value of the second node is determined; If a result value of the second node is not determined, extracting a third node, which is a node facing an edge from the second node; Calculating a result value of the third node; And And calculating a result value of the second node based on the result value of the third node. The method of claim 3 The step (d) Treating the second node as the first node, wherein steps (a) to (e) are recursively performed repeatedly. The method of claim 3, And updating the resultant value of the node corresponding to the first conditional expression in the conditional graph with the calculated resultant value of the first conditional expression. The method of claim 3, And if the first conditional expression is a literal or a variable, updating a result value of a node corresponding to the first conditional expression to the extracted literal value or a variable value. The method of claim 1, And updating the result value of the node included in the conditional graph to an undetermined state when the context node is changed during the first conditional expression calculation. The method of claim 1, Include in the conditional graph when the context node is changed from the first context node to the second context node during the first conditional expression calculation and the template base node of the first context node is not an ancestor of the template base node of the second context node. And updating the result of the determined node to an undetermined state. The method of claim 1, If the context node is changed during the first conditional expression calculation, the conditional expression calculation method further comprising updating the resultant value of a node whose resultant value is changed by changing the context node among nodes included in the conditional graph. . The method of claim 1, And generating an action instance according to the calculated result value of the first conditional expression and the action template. In the recording medium on which a program of instructions that can be executed by an electronic device is tangibly implemented to perform a conditional calculation method for access control, and in which a program can be read by the electronic device, The recording medium which recorded the program which performs the method of any one of Claims 1-11.

Images