[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Comments on the Hierarchical and Multiple Resource Profile of XACML 3.0
Comments on the Hierarchical and Multiple Resource Profile of XACML 3.0:
The attached document (chapter 6.5 and 7) contains a detailed analyses of the multiple and hierarchical resource profile 2.0 (which has not been substantially changed in its 3.0 version). Below you find a list of the most important Change Requests derived from this document. The comments were slightly adapted to match the 3.0 versions of the two profiles and to reflect some comments we received meanwhile. Upfront I added some background information to introduce you to the specific requirements we have in our use case.
Note: These are my personal comments but they resulted from the experiences made during the work within the OGC (especially the last test bed phase OWS-6 and the work done within the GeoXACML Standards Working Group).
It is our aim to provide access control with (Geo)XACML in service oriented spatial data infrastructures based on OGC Web Services (OWS). Therefore the assets we are trying to protect are Web Service requests and responses (except OWS that return images) are usually encoded in XML. From the access control perspective this implies that a PEP intercepts XML structured OGC Web Service requests and responses (if reasonable – i.e. if XML structured) and initiates the access control process. Hence the objects for which access rights have to be verified are dynamically generated XML documents - the Web Service request and/or Web Service response respectively. In the following we call the OWS request or response the high-level resources. Obviously a high-level resource as an atomic object is a pretty coarse-grained view of the data that we are trying to protect. In order to support fine-grained and content dependant access control we have to regard the nodes of these high-level resources as the actual entities for which the access control process evaluates the access rights. Therefore the nodes of the Web Service request or Web Service response are the “real” resources. We will refer to these XML nodes simply as resources.
Currently there are two profiles for the use of XACML with resources that are XML encoded – the Hierarchical resource profile of XACML and the Multiple resource profile of XACML. As the resources in the OGC use case are hierarchically organized nodes encoded in XML, both profiles are of relevance.
Further the following requirements exist towards an access control systems for (OGC) Web Service based spatial data infrastructures:
<![if !supportLists]>• <![endif]>declaration of:
<![if !supportLists]>– <![endif]>fine grained, positive and negative access rules for Web Service
<![if !supportLists]>• <![endif]>Note that access rules referring to element, attribute or text nodes must be possible
<![if !supportLists]>– <![endif]>content dependent access rules
<![endif]>it must be
possible to express access rights for a node,
<![if !supportLists]>– <![endif]>spatial access rules
<![if !supportLists]>• <![endif]>a special type of content dependant rules that allows to use spatial functions like within, distance (c.p. the GeoXACML function set for an extensive list) in order to express the rule semantics.
<![if !supportLists]>– <![endif]>context dependent access rules
<![if !supportLists]>• <![endif]>pre- & post-processing access control
<![if !supportLists]>• <![endif]>It must be possible to define rules referring to a Web Service request or response
<![if !supportLists]>• <![endif]>filtering
<![if !supportLists]>• <![endif]>In case of insufficient access rights it must be possible to compute the intersection of requested and accessible resources.
It is our aim to develop an access control system based on XACML, GeoXACML and the multiple and hierarchical resource profile, able to meets all requirements listed above. To achieve this goal various suggestions that improve the quality and usefulness of the multiple and hierarchical resource profile profiles were derived. It is worth mentioning, that although the original motivation for the following analysis and comments comes from the geospatial problem domain (i.e. access control for OGC Web Services), most of the findings are nevertheless valid for Web Service based architectures in general. Therefore the comments will also be valuable for a broader community.
Comments on the Hierarchical Resource Profile of XACML 3.0:
Comment 1: line 34-35: informative
“An authorization decision
that denies access to an interior node does
not imply that access to its descendant nodes is denied.” (, S.3).
Comment 2: Line 56: interoperability problem
“[XPath] expressions can be used to reference nodes in this document in a standard way, and can provide unique representations for a given node in the document.” (, S. 3).
Forcing to use XPath expressions referring to exactly one node in the <ResourceContent> element limits the representation possibilities, which is a step in the right direction. But this still leaves some flexibility for no real reason and might therefore cause interoperability problems. Example:
A resource-id attribute value in an individual decision request might be:
A rule e.g. allowing access to building nodes will have a predicate like the following:
regexp-string-match( resource-id, /Request/Resource/ResourceContent/wfs:FeatureCollection\[\d+\]/gml:featureMember\[\d+\]/Building\[\d+\]$)
By using such a predicate all decision requests referring to “Building” nodes will match and the rule will get evaluated. In this example we used the abbreviated XPath syntax to refer to exactly one node. In case the Context Handler uses unabbreviated XPath syntax when deriving the individual decision requests from a global decision request the rule won’t match any more.
Conclusion: In order to get a unique representation for a node in the document it should be specified more precisely which syntax the XPath values of the resource-id attribute have to conform. We recommend to use a syntax as shown in the example (i.e. /elementNodeName[integer]/../elementNodeName [integer] in case of element nodes and /elementNodeName[integer]/../@attributeNodeName in case of attribute nodes.
Additionally the question is whether the XPath expressions should always refer to the <xacml-context:Request> element as its context node or to the content element that is additionally identified through the category attribute? If you choose option one (i.e. the <Request> element is the context node), then XPath expressions will always start with /Request... (c.p. e.g. line 4907 in the core XACML 2.0 specification).
Remark: Note that it is not possible to use the XPath node matching function in order to make the exact form of the xpath expression irrelevant. The reason is that XPath node match functions imply certain limitations in our use case like:
supported by XPath can be used to define content dependant authorizations
<![endif]>no pointers to XACML
decision request data inside an XPath predicate
<![if !supportLists]>• <![endif]>filtering is not possible
<![if !supportLists]>– <![endif]>the XACML decision response refers to the Web Service request or response as a whole
Comment 3: Line 188-191: interoperability problem
Comment 4: Line
196: unclear usefulness
Comment 5: Line 265: unclear usefulness
Comment 6: Line 286-314: unclear usefulness (critical)
Following the first way of how to represent a hierarchical resource - i.e. as an XML document included in the <ResourceContent> element - we don’t see any need for the resource-parent, resource-ancestor and resource-ancestor-or-self XACML Attributes in this XML resource case. The same information is already included in the decision request’s <ResourceContent> element where the whole XML document is included. The question is therefore why do you have to include more generalized information (you loose the detailed relationship information between the nodes) as explicit XACML Attributes in the same decision request? In our OWS use case these attributes are of no use and forcing to use them is an unnecessary burden.
Additionally it remains unclear for the reader where they are actually useful. If they refer to the second way of how to represent a hierarchical resource (remember: this alternative is not suited for the OWS use case) there should at least be some additional explanations in which situations they might or might not be useful in order to avoid confusion of the readers of the profile. Another question is if the introduction of these attributes fit into section “3.1 Nodes in an XML document” or should they be introduced in 3.2?
Comment 7: Section 4.1 and 4.2: limited functionality despite the existence of a better solution (critical)
Given the situation that the value of the resource-id attribute contains an XPath expression that refers to exactly one node of the XML document (included in the <ResourceContent> element), a policy writer can define predicates that apply to one or multiple nodes in a XML document by using the value of the resource-id attribute in a special AttributeSelector. The use of the such a Selector is described by the following example:
Selector(string-one-and-only(ResourceAttributeDesignator(resource-id), arbitraryOffset). This mechanism allows selecting arbitrary node sets relative to the currently inspected (i.e. the individual node for which the access rights are currently checked).
Conclusion: Having a simple Selector supporting the function described above allows policies to evaluate any node(s) in the XML document. This in turn means that such a general, easy to understand and implement and powerful mechanism could replace the less expressive techniques described in section 4.1 and 4.2 of the profile. Of course the xpath-node-match function section as mentioned in 4.2 can still be used but again the mechanism described above is much more expressive. E.g. assume you want to define a predicate in a rule’s condition element saying an XML node (e.g. Building) can be accessed only if one if its child element (e.g. owner) equals “Bob” and another child element (e.g. status) equals “for sale”. Trying to define predicates that refers to certain nodes in the hierarchical resource is not possible with the mechanisms included in the current version of the profile. The reason for this is that you loose the connection/relation of the nodes being evaluated in separate predicates by separate Selectors (e.g. the connection of the attributes owner and status that belong to the same building). Therefore, it is important to add another AttributeSelector making use of the resource-id attribute value in combination with an arbitrary offset.
A workaround to the problem explained is to shift the content dependant conditions inside the XPath expression (i.e. in an XPath Predicate). Unfortunately this results in strong limitations as than only Predicate functions supported by XPath can be used. Further one can’t use pointers to arbitrary XACML Attribute (e.g. subject-id).
Comments on the Multiple Resource Profile of XACML 3.0:
Comment 1: Line 71-74: interoperability problem
This block is an elegant way of achieving, that a programmer has some degree of flexibility when implementing a Context Handler supporting this profile. At the same time it restricts the flexibility so that the results are the same as if one follows the model as described in the profile.
From the interoperability point of view it is important that the syntax and semantics of a global and individual decision request are standardized. This standardization further has a direct influence on the way how to define the policies in XACML. It is very important to note the strong dependency between a decision request and the definition of rules.
The question that arises here is, does this block really ensure this interoperability?
I support that the the CTX Handler or PDO can optimize its internal processing as long as the external behaviour is the same. Is this Block realy expressing this? If the implementation of a Context Handler does not even construct individual DECISION REQUEST and uses instead a proprietary way of doing the same, than there is a risk that the policies will be defined differently. One time the rules will correspond to the needs of the proprietary alternative Context Handler implementation and one time they will follow the model described in the profile. This fact therefore results in loosing the interoperability of two XACML policies although they are both XACML and Multiple resource profile conformant.
Solution: Make it more clear that the optimization of a PDP implementation should have no side effect on how to define the decision requests AND Rules. Further it might help if the gives additionally standardized guidelines how to define XACML policies that match the derived individual decision requests (e.g. use reg-expr-match like introduced in Comment 2 in the Hierarchical Resource Profile review section). These will not only enhance interoperability but will also help understanding the intended mechanism.
Comment 2: Line 145-208 (Section 2.1 and 2.2):
redundancy, mixture of guidelines how to deal with XML and non-XML resources
Comment 3: Section 2.1 and 2.2: limited functionality (critical)
In case of XML high-level resources, the mechanisms to derive individual decision requests from a global decision request for multiple resources are too limited. Assume you want to generate an individual DECISION REQUEST for all element nodes that are descendant of the node specified by resource-id. In this case the profile in its current version is imprecise about what descendant actually means. Are all nodes (i.e. element nodes, text nodes, attribute nodes etc.) the descendants?
To clarify this either an additional attribute in a decision request (specifying the node type) is necessary or you extend the possible scope values by:
elementNode-descendant, attributeNode-descendant, textNode-descendant, commentNode-descendant,... and all possible subsets of these. The original descendant scope-value will then have the meaning of really all descendant nodes no matter of the node type.
Comment 4: Line 109: unclear or imprecise formulation (critical)
Following the profile an individual decision request shall have one resource element that refers to a single resource (in case of XML, an XML node). This node is specified by the resource-id attribute in the individual DECISION REQUEST. Therefore, it is unclear how and why a resource element of an individual DECISION REQUEST can have more than one resource-id attribute (c.p. line 174: “...at least one..”). Add explanations when and how this can occure in the XML resource use case.
Comment 5: Line 128: confusing URN
Comment 6: Line 157: usefulness
Comment 7: Line 162+163: overloaded and therefore
misleading formulation (critical)
Having the XML resource use case in mind we are wondering if there is a real use case or benefit by using multiple <Resource> elements. Basically what happens is that a PEP packs more than one XACML request element in one decision request and the corresponding Context Handler immediately un-packs this “combined” multiple resource request and generates separate global request contexts one for each request element. Is this an advantage compared to sending the global decision requests one after the other? Are there use cases where it does make sense to pack more than one global request in one “combined” multiple resource request?
Comment 9: Line 189-247: bad solution and writing
Comment 10: Line 210+211: intended functionality?
Comment 11: General comment:
So far my comments towards the new Hierarchical and Multiple Resource profile of XACML 3.0 draft. Of course I am happy to provide more input on these thoughts if need. Simply call me or contact me via email.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]