Patent Publication Number: US-7913172-B2

Title: Fine-grained, label-based, XML access control model

Description:
BACKGROUND OF THE INVENTION 
     1. Field of the Invention 
     This invention relates to XML access control and more particular to fine-grained, label-based, XML access control models. 
     2. Description of the Related Art 
     XML has rapidly emerged as the prevalent standard for representing and exchanging business and other sensitive data over the Internet. The current trend to add XML support to database systems, however, poses new security challenges in an environment where both relational and XML data coexist. In particular, fine-grained access control methodologies may be even more important for XML data than for relational data, given the more flexible and less homogeneous structure of XML data compared to relational tables and rows. 
     Controlling access to XML data may be more difficult than controlling access to relational data for several reasons. First, the semi-structured nature of XML data, where a schema may be absent, or, even if present, may allow significantly more flexibility and variability in the structure of the document than is allowed by a relational schema. Second, the hierarchical structure of XML may require specifying how access privileges to certain nodes propagate to and from the nodes&#39; ancestors and descendants. 
     In almost all models for controlling access to XML, the smallest unit of protection is a node of an XML document, which is typically specified using an XPath fragment. Access to ancestor/descendant and sibling relationships among nodes has typically not been considered. In general, an access control policy consists of positive or negative authorization rules that grant or deny access to selected nodes of an XML document. The main difference between most XML access control models lies in privilege propagation. For example, some models forbid access to entire sub-trees that are rooted at inaccessible nodes. 
     In other models, an ancestor node for which access is denied may be masked as an empty node if access is granted to a descendant node. However, this model may make the literal of the forbidden ancestor visible in the path from the root node to the authorized node. In some cases, this situation may be improved by replacing the literal of an ancestor node literal with a dummy value. However, this still does not solve the problem that different descendant nodes may require their ancestor&#39;s literal to be visible or invisible in a different manner. Accordingly, each of the above models makes it difficult to define a view that precisely describes the path leading to an authorized node. 
     In view of the foregoing, what is needed is an access control model for XML that provides a more fine-grained level of control. Ideally, such a model would be able to protect relationships between nodes as opposed to the nodes themselves. Further needed is a model that utilizes security labels to protect these relationships. 
     SUMMARY OF THE INVENTION 
     The present invention has been developed in response to the present state of the art, and in particular, in response to the problems and needs in the art that have not yet been fully solved by currently available methods for controlling access to information in XML documents. Accordingly, the present invention has been developed to provide a fine-grained, label-based model for controlling access to XML documents that remedies various problems in the art. 
     Consistent with the foregoing and in accordance with the invention as embodied and broadly described herein, a method for controlling access to an XML document includes referencing a schema definition comprising a path security label definition associated with a path of an XML document. As used herein the term “path” in an XML document refers to an ancestor-to-descendent path, a sibling-to-sibling path such paths, edges, and relationships between nodes of an XML document. An XML document with security labels may then be validated by comparing it with the schema definition. This validation may include verifying that the XML document has a path security label associated with a path that is at least as restrictive as that specified by the path security label definition. Similarly, an access security label may be defined for a user seeking to access a sibling-to-sibling path. In one embodiment, the security administrator may define the access security label for a user. The path security label and the access security label may be compared, using pre-determined access rules, to determine whether the user is authorized to access the sibling-to-sibling path. Access to the sibling-to-sibling path may then be granted or denied according to the access rules. 
     In a second aspect of the invention, a computer program product may be provided to control access to an XML document comprising a plurality of nodes and a plurality of paths, or relationships, between the nodes. The computer program product may include a computer-readable medium storing a program of computer-readable instructions. When executed, these instructions may cause a computer to generate a schema definition comprising a path security label definition associated with a sibling-to-sibling path of an XML document. The instructions may further enable an XML document to be validated by comparing it with the schema definition. This validation may include verifying that the XML document has a path security label associated with a sibling-to-sibling path that is at least as restrictive as that specified by the path security label definition. These instructions may further cause the computer to reference an access security label to a user seeking to access the sibling-to-sibling path of the XML document and compare, using pre-determined access rules, the path security label to the access security label to determine whether the user is authorized to access the sibling-to-sibling path. In one embodiment, these instructions may cause the computer to assign an access security label to an XML document that fails to comply with a given Document Type Definition (DTD) or XML Schema Definition (XSD). The access security label assigned may be at least as restrictive as a path security label designated in the DTD or XSD. Finally, the instructions may cause the computer to grant or deny access to the sibling-to-sibling path according to the access rules. The present invention provides novel methods for controlling access to XML documents. The features and advantages of the present invention will become more fully apparent from the following description and appended claims, or may be learned by the practice of the invention as set forth hereinafter. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       In order that the advantages of the invention will be readily understood, a more particular description of the invention briefly described above will be rendered by reference to specific embodiments illustrated in the appended drawings. Understanding that these drawings depict only typical embodiments of the invention and are not therefore to be considered limiting of its scope, the invention will be described and explained with additional specificity and detail through use of the accompanying drawings, in which: 
         FIG. 1  illustrates one embodiment of an XML document tree structure that includes multiple nodes and paths between the nodes; 
         FIG. 2  illustrates one embodiment of an SQL/XPath extension, or statement, to attach a path security label to a parent-to-child path; and 
         FIG. 3  illustrates one embodiment of an SQL/XPath extension, or statement, to attach a path security label to a sibling-to-sibling path. 
     
    
    
     DETAILED DESCRIPTION OF THE INVENTION 
     It will be readily understood that the components of the present invention, as generally described and illustrated in the Figures herein, could be arranged and designed in a wide variety of different configurations. Thus, the following more detailed description of the embodiments of systems and methods in accordance with the present invention, as represented in the Figures, is not intended to limit the scope of the invention, as claimed, but is merely representative of certain examples of presently contemplated embodiments in accordance with the invention. The presently described embodiments will be best understood by reference to the drawings, wherein like parts are designated by like numerals throughout. 
     Referring to  FIG. 1 , one embodiment of an XML document tree structure  100  is illustrated to provide a basic understanding of the invention. Here, the document tree structure  100  stores account and item information associated with an online seller. As shown, the document tree structure  100  includes a plurality of nodes  102  arranged in a hierarchical tree structure. The relationship between the nodes  102  may be represented by a plurality of paths  104  traveling between each of the nodes  102 . As mentioned previously, the smallest unit of protection in most conventional XML access control models has been the node  102 . This method of protection, however, may violate various security principles such as the “need-to-know” and “choice” security principles by leaking unnecessary or confidential information. 
     For example, consider the sub-tree rooted at node  102   a  and represented by the literal “VIP Accounts.” Suppose that the security policy is such that access to node  102   b  is authorized while access to node  102   c  is unauthorized. Using a node-based security approach, granting access to node  102   b  will normally require granting access to the root node  102   a . Once access is granted to the root node  102   a , access will normally be automatically granted to the child node  102   c . Thus, it may be very difficult to implement a node-based security approach that can grant access to node  102   b  while simultaneously denying access to node  102   c . As a result, many node-based security approaches violate the “need-to-know” or “choice” security principles because they leak information about the node  102   c.    
     In selected embodiments in accordance with the invention, a path- or relationship-based security approach may be used to provide a more fine-grained, expressive, and effective access control model to protect information in the XML document  100 . In such a model, ancestor/descendant and sibling relationships  104 , or paths  104 , may be considered legitimate elements to be protected. Such a model may also better comply with security principles such as the “need-to-know” and “choice” security principles. 
     In certain embodiments, one or more of the paths  104  may be protected with a “security label” associated with a label-based access control (LBAC) implementation. In such an implementation, the path security label may be compared to an access security label granted to a subject (e.g., a user) attempting to access or traverse the path. Whether access is authorized may be determined based on pre-determined set of label access rules. Access to the path may then be denied or granted based on the label access rules. 
     For example, consider again the sub-tree rooted at node  102   a . If the security policy is such that access to node  102   b  is authorized while access to node  102   c  is unauthorized, a security label  106   a  may be attached to the parent-to-child path between the root node  102   a  and the child node  102   c . A second security label  106   b  may be attached to the sibling-to-sibling relationship between node  102   c  and node  102   b . As a result, access may be granted to the path between the root node  102   a  and the child node  102   b  while simultaneously denying access to all paths leading to the child node  102   c.    
     In selected embodiments, an SQL extension, also referred to herein as a command or statement, may be provided to enable an access security label to be granted to a user. Such an extension may already be available in various database management systems, such as IBM&#39;s DB2 version 9. For example, one embodiment of an extension may be implemented using the following SQL statement: 
                                            GRANT ACCESS LABEL label-name           TO USER user-name FOR READ ACCESS                        
Here, label-name designates the name of the access security label and user-name designates the name of the user who is granted the access security label. Similarly, the phrase “FOR READ ACCESS” may be replaced with the phrase “FOR WRITE ACCESS” or “FOR ALL ACCESS” to grant either read access, write access, or both types of access to the user.
 
     Referring to  FIGS. 2 and 3 , various SQL/XPath extensions may also be provided to enable security labels to be attached to paths  104  between nodes  102 . For example,  FIG. 2  shows one embodiment of an SQL statement that may be used to attach a security label to an ancestor/descendant path (including a parent-to-child path) of an XML document. In this embodiment, path 1  and path 2  are XPath expressions designating the nodes at each end of the path, with path 2  being an XPath expression relative to path 1 . Path-label may be used to designate the name of the security label that is attached to the path. 
     For example, the following statement may be used to attach a path security label having the name “EXISTENCE” to the relationship between the node  102   a  and the node  102   c  of  FIG. 1 : 
     
       
         
           
               
               
             
               
                   
                   
               
             
            
               
                   
                 ATTACH EXISTENCE 
               
               
                   
                 ANCS //VIP Accounts 
               
               
                   
                 DESC /Account[Customer/Name = “Barbara”] 
               
               
                   
                   
               
            
           
         
       
     
       FIG. 3  shows one embodiment of an SQL statement that may be used to attach a security label to a sibling-to-sibling path of an XML document. In this embodiment, path 1 , path 2 , and path 3  are XPath expressions, with path 2  and path 3  being XPath expressions relative to path 1 . Path 2  and path 3  specify relationships between the node specified by path 1 , and the node&#39;s preceding and following siblings. If the node does not have preceding siblings, the PRECEDING-SIBLING expression may be deleted from the statement. Similarly, if the node does not have following siblings, the FOLLOWING-SIBLING expression may be deleted from the statement. Like the extension illustrated in  FIG. 2 , path-label may designate the name of the security label attached to the sibling-to-sibling path. 
     For example, the following statement may be used to attach a path security label with the name “VALUE” to the sibling-to-sibling relationship between the node  102   b  and the node  102   c  of  FIG. 1 : 
     
       
         
           
               
               
             
               
                   
                   
               
             
            
               
                   
                 ATTACH VALUE 
               
               
                   
                 NODE //Account[Customer/Name = “Barbara”] 
               
               
                   
                 PRECEDING SIBLING /Account 
               
               
                   
                   
               
            
           
         
       
     
     In addition to providing support for the above SQL/XPath statements, an extension may be provided to the SQL compiler. This extension may ensure that the access plan generated to fetch a column of type XML in a database table also includes the access rules for evaluating a user&#39;s access rights with respect to the content of the XML column. The goal is to allow users to label node relationships and let them be sure that what they want to conceal is truly concealed from the users whose access labels do not satisfy the label access policy with the path labels. Unfortunately, it is impossible to guarantee concealment for any arbitrary set of relationships. Sometimes, it is possible to infer a concealed relationship from the relationships that are not concealed. 
     Let us consider an example of four cases where a relationship could be inferred from a pair of non-concealed relationship. Referring to  FIG. 1 , suppose it is known that Account Node  102   b  is a descendant of VIP Accounts Node  102   a  and Customer Node  102   d  is a descendant of Account Node  102   b . Then, there is no point to conceal the ancestor-descendant relationship between VIP Accounts Node  102   a  and Customer Node  102   d . Suppose it is known that Customer Node  102   d  is a descendant of VIP Accounts Node  102   a  as well as Account Node  102   b . Since there is only one path from the root of the document to Account Node  102   b , there is no point to conceal the ancestor-descendant relationship between VIP Accounts Node  102   a  and Account Node  102   b.    
     Suppose it is known that Account Node  102   b  and Account Node  102   c  are the children of VIP Accounts Node  102   a , then there is no point to conceal the sibling relationship between Account Node  102   b  and Account Node  102   c . Suppose it is known that VIP Accounts Node  102   a  has a descendant Customer Node  102   d  and the customer has a sibling Account ID  102   e , then there is no point to conceal the ancestor-descendant relationship between VIP Accounts Node  102   a  and Account ID  102   e . We say a set of labeled relationships/paths in an XML document D is not secure with respect to a path label L if one of the following four cases occurs. 
     1. Case 1: D has three nodes, n 1 , n 2  and n 3  s.t. the ancestor-descendant path from n 1  to n 2  and the ancestor-descendant path from n 2  to n 3  have labels L 12 &lt;L and L 23 &lt;L. The ancestor-descendant path from n 1  to n 3  has a label L 13 ≧L. 
     2. Case 2: D has three nodes, n 1 , n 2  and n 3  s.t. the ancestor-descendant path from n 1  to n 3  and the ancestor-descendant path from n 2  to n 3  have labels L 13 &lt;L and L 23 &lt;L. The ancestor-descendant path from n 1  to n 2  has a label L 12 ≧L. 
     3. Case 3: D has three nodes, n 1 , n 2  and n 3  s.t. n 1  is the parent of n 2  and n 3 , the parent-child path from n 1  to n 2  and the parent-child path from n 1  to n 3  have labels L 12 &lt;L and L 13 &lt;L. The sibling path from n 2  to n 3  has a label L 23 ≧L or the sibling path from n 3  to n 2  has a label L 32 ≧L. 
     4. Case 4: D has three nodes, n 1 , n 2  and n 3  s.t. the ancestor-descendant path from n 1  to n 2  has a label L 12 &lt;L, and either the sibling path from n 2  to n 3  has a label L 23 &lt;L or the sibling path from n 3  to n 2  has a label L 32 &lt;L. The ancestor-descendant path from n 1  to n 3  has a label L 13 ≧L. 
     There is a simple test to verify that a set of labeled relationships/paths in an XML document D is not secure with respect to a path label L. The test starts by computing three ternary relations R 1 , R 2  and R 3 . The first two columns store the start/end nodes of paths. The third column stores the label associated with paths (if a label is missing, then it is a NULL value). In particular, R 1  stores all ancestor-descendant paths in D, R 2  stores all parent-child paths in D, and R 3  stores all sibling paths in D. 
     1. Case 1 is true for a path label L if and only if the expression π $1, $5 (R 1,L *$2=$1 R 1,L )−R 1,L  is not empty where R 1,L  is σ $3&lt;L (R 1 ). 
     2. Case 2 is true for a path label L if and only if the expression π $1, $4 (R 1,L *$2=$2 R 1,L )−R 1,L  is not empty where R 1,L  is σ $3&lt;L  (R 1 ). 
     3. Case 3 is true for a path label L if and only if the expression π $2, $5 (R 2,L *$1=$1 R 2,L )−R 3,L  is not empty where R 2,L  is σ $3&lt;L  (R 2 ) and R 3,L  is σ $3&lt;L  (R 3 ). 
     4. Case 4 is true for a path label L if and only if the expression π $1, $5 (R 1,L *$2=$1 R 3,L )−R 1,L  is not empty where R 1,L  is σ $3&lt;L  (R 1 ) and R 3,L  is σ $3&lt;L  (R 3 ). 
     Furthermore, we give intuitive conditions to construct a secure set of labeled relationships for an XML document. If we ignore the directions of ancestor-descendant and sibling paths, all these paths form cycles in an XML document. To assign a path label L to a relationship between two nodes n 1  and n 2  in an XML document D, we must make sure, for every cycle that includes the path from n 1  to n 2 , either there is another path whose label L o ≧L, or n 1  and n 2  are descendants of some nodes in the cycle and n 1 , n 2  are not children of the same parent. Both cases ensure there is uncertainty whether a relationship between two nodes n 1  and n 2  exists: the first case by having another path missing in the cycle, while in the second case, the fact that n 1  and n 2  are descendants of some nodes in the cycle introduces uncertainty except when they are children of the same parent, in which case the sibling relationship between n 1  and n 2  is leaked. 
     In certain embodiments, a DTD may be used to verify that certain security labels are assigned to paths of an XML document  100 . In the event one or more paths of an XML document  100  do not include the security labels specified in the DTD, these security labels may be added to the XML document  100  to make it conform to the DTD. This feature may be provided to ensure that protected information in an XML document  100  is truly concealed from users lacking the required authority. This feature may also reduce the chance that users will infer the existence of a concealed relationship from other relationships that are not concealed. 
     For example, in certain embodiments, security labels may be validated in an XML document  100  using an attribute declaration in a DTD having the following form: 
     
       
         
           
               
               
             
               
                   
                   
               
             
            
               
                   
                 &lt;!ATTLIST N SecurityLabel (Path1 Label1 | Path2 Label2 | . . .), 
               
               
                   
                 #REQUIRED/#IMPLIED&gt; 
               
               
                   
                   
               
            
           
         
       
     
     Here, N can be instantiated to be a set of nodes in an XML document  100  (e.g., VIP Accounts), Path 1 , Path 2 , etc. identify instantiated paths relative to each of the nodes to be protected by a security label, and Label 1 , Label 2 , etc. identify security labels to be attached to the instantiated paths of Path 1 , Path 2 , etc., respectively. In selected embodiments, N, Path 1 , Path 2 , etc. may be identified using XPath expressions. Similarly, Path 1 , Path 2 , etc. may designate ancestor/descendant, sibling-to-sibling, or other desired paths in the XML document  100 . The #REQUIRED/#IMPLIED syntax may be used to designate whether the security labels identified in the attribute declaration are required (e.g., #REQUIRED) or are merely optional (e.g., #IMPLIED). 
     In operation, when validating an XML document  100  with the DTD, the above-identified attribute declaration may be checked against the attributes in the XML document  100 . This may be performed to verify that the XML document  100  has path security labels at least as restrictive as those designated in the DTD. If the XML document  100  does not include path security labels that are at least as restrictive as those designated in the DTD, path security labels may be inserted into the XML document  100  to make it conform to the DTD. Conversely, path security labels of the XML document  100  that are more restrictive than those designated in the DTD may be left alone. Thus, the DTD may be used to impose a set of minimum security requirements on paths of the XML document  100 . 
     In certain embodiments, when attempting to access an XML document  100 , a user&#39;s security label may be compared to the path security labels designated in the DTD as opposed to comparing it with the path security labels of the XML document  100 . This may improve efficiency because a DTD is typically much smaller than the XML document  100  it is associated with. If the user is not authorized to access the paths specified in the DTD, the user will not be authorized to access the corresponding instantiated paths in the XML document  100 . This is because the XML document  100  will have security labels that are at least as restrictive as those specified in the DTD. 
     On the other hand, if the user is authorized to access paths designated in the DTD, the user is not necessarily authorized to access the corresponding paths in the XML document  100 . This is because the XML document  100  may have security labels that are more restrictive than those specified in the DTD. If this is the case, the user&#39;s security label may also be compared to the path security labels of the XML document  100  to determine whether the user is authorized to access the paths. 
     It should be recognized that the features and advantages discussed above with respect to a DTD may also be applied to other languages for describing the schemas of XML documents, such as the XSD language. 
     The present invention may be embodied in other specific forms without departing from its spirit or essential characteristics. The described embodiments are to be considered in all respects only as illustrative and not restrictive. The scope of the invention is, therefore, indicated by the appended claims rather than by the foregoing description. All changes which come within the meaning and range of equivalency of the claims are to be embraced within their scope.