OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xacml-comment message

[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).


Background information:

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:


         declaration of:

        fine grained, positive and negative access rules for Web Service

         Note that access rules referring to element, attribute or text nodes must be possible

        content dependent access rules

         it must be possible to express access rights for a node,
that are dependant on the value of other nodes. Here it is especially important that arbitrary information (i.e. node sets) under the Content element can be selected & serve as input for functions in XACML rules

        spatial access rules

         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.

        context dependent access rules

         pre- & post-processing access control

         It must be possible to define rules referring to a Web Service request or response


         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.” ([3], S.3).
If access to an interior node is denied but access to children nodes is possible implies that the XML tree structure will get destroyed by deleting the access restricted interior node. Therefore the tree structured XML resource becomes a forest (at least two trees whereby the new trees are the sub-trees under the restricted interior node) and thus will not conform to the original XML schema of the request or response anymore. We argue that in the OWS use case such a behavior is not needed or wanted.
Conclusion: In the OWS use case it is possible to say that: An authorization decision that denies access to an interior node does imply that access to its descendant nodes is also denied.


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.” ([3], 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:

/Request[1]/Resource[1]/ResourceContent[1] /wfs:FeatureCollection[1]/gml:featureMember[1]/Building[1]

A rule e.g. allowing access to building nodes will have a predicate like the following:

regexp-string-match( resource-id, /Request[1]/Resource[1]/ResourceContent[1]/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:

         only predicates supported by XPath can be used to define content dependant authorizations
àlimited expressiveness

         no pointers to XACML decision request data inside an XPath predicate
(e.g. permit access if /bulding[owner = subject-id])
àlimited expressiveness

         filtering is not possible

        the XACML decision response refers to the Web Service request or response as a whole



Comment 3: Line 188-191: interoperability problem
The relaxation softens the guidelines of the profile. As the profile is mandatory anybody not willing to follow the profile can do so. But having this relaxation in the profile means that one can be conformant to the profile and still represent the identity of nodes in an alternative way which will destroy interoperability. A question related to this fact is the actual intend of the profile: Should it either be a best-practice document how to use XACML for hierarchical resources like XML or/and should it be a standard guaranteeing interoperability when using XACML in such scenarios? From the OWS use case both (at least the latter) would be the actually needed document in order to be able to implement interoperable access control systems for OGC Web Services.



Comment 4: Line 196: unclear usefulness
A node in an decision request is referenced by the resource-id attribute. Should the xml-node-id attribute ever be used? It seems that at least in the OWS use case this attribute is never used.

Comment 5: Line 265: unclear usefulness
How should the xml-node-req attribute ever be used?


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
In case of XML high-level resources the use of the functionality of scope:xml = Children or Immediate can also be achieved by the alternative described in section 2.2 (i.e. scope=xpath-expression and resource-id is an appropriate XPath expression; i.e. evaluating to the immediate node or some children nodes). The functionality of “descendant” can’t be achieved by the mechanism in section 2.2 and is therefore also needed for XML resources. It seems that a clearer separation of the XML and non-XML use case (like in the hierarchical resource profile or like in Section 3) might help clarify things.
XML resources:
scope = {descendant, xpath-expression} & resource-id
Note: It is an unnecessary restriction that in case of descendant, the value of resource-id has to point at exactly one node (c.p. line 164).
non-XML resources:
scope = {descendant, children, immediate} & resource-id



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
Is urn:oasis:names:tc:xacml:2.0:profile:multiple:xpath-expression a good name for the attribute value of scope? In the XACML specification the word xpath-expressions is used either in the meaning urn:oasis:names:tc:xacml:2.0:profile:multiple:xpath-expression or in the meaning urn:oasis:names:tc:xacml:2.0:data-type:xpath-expression. Without any explicit comment about the difference of the two we encountered, that this naming is confusing for people not very familiar with the specification and the profiles.
Solution: add a footnote or comment



Comment 6: Line 157: usefulness
It is unclear where to use the URI identifier urn:oasis:names:tc:xacml:2.0:profile:multiple:multiple-resource-elements. Is it just useful as kind of metadata in a description of an access control system product? If so a little note of the intended use of this URN might be helpful to clarify things.



Comment 7: Line 162+163: overloaded and therefore misleading formulation (critical)
The term individual resource request is used for two different things. In the whole profile it represents generated individual decision requests depending on the individual resources (individual nodes in the XML use case) as identified by scope and resource-id attribute values of the original global decision request for multiple resources. In this section the term individual resource request is used for requests that are derived dependant on the number of <Request> elements. . To make the problem more clear: individual resource is used as an acronym for a node and for a decision request with one <Request> element which can also be a global decision request for multiple nodes.
Solution: Reformulate section 2.3.3 or replace individual by separate in the corresponding lines. Additionally it might be helpful to add a short definition or explanation of this matter.



Comment 8:

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 error (critical)
a) bad solution: entire-hierarchy:xml should not be a possible value for the scope attribute:
The scope attribute is not the right place to specify whether the results should be combined to a single response. The scope attribute is used to specify the different ways how to process decision requests for multiple resources. The desire of combining individual results to one single result has only indirectly something to do with this (more precisely: it is just a prerequisite that the original corresponding global decision request is a decision request for multiple resources). It might for example be the desire of a user that he wants to use option 2 (i.e. 2.2 Nodes identified by XPath
àscope:xml=...multiple:xpath-expression) and to union all individual responses to a global, single combined response. Here the user is lucky as this is the special case intended by the profile (at least more or less – c.p. next problem item 9 b). What if the user wants to use option 1 (i.e. 2.1            Nodes identified by “scope”àscope:xml=Children) and wants to get the union of all individual responses to a global, single combined response. In this case the scope attribute should be on the one hand side Children but on the other entire-hierarchy:xml. Because of this source of conflict and unnecessarily reducing flexibility and expressiveness we recommend to use another attribute (e.g. combine-results-of-a-multiple-request of datatype Boolean) that acts as a switch and helps the Context Handler to decide whether to union all individual responses to a global response or to forward the individual responses directly.
b) writing error:
We strongly assume and recommend that the intended meaning of line 231+232 is like described in section 2.2. That means that the line 268, 269 should say:
“…such that the <AttributeValue> evaluates to a node set that represents multiple nodes in the <ResourceContent> element.” (instead of:…”such that the <AttributeValue> evaluates to a nodeset that represents exactly one node in the <ResourceContent> element). This correction will achieve consistency with the semantic description in line 236. Additionally it might be more precise to also explicitly name that the multiple <Resource> element case can also occur in combination with such a request and will upfront be processed as described in section 2.3.
In summary:
Baseline is the receive of a global DECISION REQUEST for multiple resources (c.p. 2.1 or 2.2) or a combined global DECISION REQUEST for multiple resources (i.e. multiple <Resource> elements that in turn represent the significant part of multiple resource requests).
Step 1: derive the individual DECISION REQUEST according to 2.1-2.3
Step 2: combine the individual response to a global response according to line 206-215 (see problem 10 for a comment on this combining algorithm).
A rewriting of section 3.1.3 after eliminating the error in Section 3.1.2 seems to be most appropriate.



Comment 10: Line 210+211: intended functionality?
In case one individual result is indeterminate, should the combined result really be deny or maybe indeterminate?
Solution: More precise explanations how to combine the results in case of errors have to be added to the specification.



Comment 11: General comment:
What is the intention of sections referring to non-XML resources in this profile? From the OWS use case point of view the reason for a profile/specification is to achieve interoperability and clear rules how to do something. When critically examining the sections of the profile about non-XML resources, all it says is that however the hierarchical resource is represented and however the individual resources are identified, use the scope attribute to choose between option 1,2,3 and the resource-id attribute to help identify the individual resources. Clearly, that is some sort of guideline but is it of any use? It is easy to imagine how different the policies and request contexts (e.g. the scope and resource-id values) could look like following this guideline. Having in mind that the access control process will only show the intended behaviour if and only if the request contexts fit to the policies one can image that so much freedom will hardly result in interoperable solutions. The fuzziness becomes apparent if you compare how much more precise you can and have to be in the XML resource use case. What are the use cases where you use the multiple and hierarchical profile for hierarchical non-XML resources at that abstract level and what benefits result from that? Might it be helpful to separate the XML resource use case in completely separate specifications and afterwards derive an abstract profile (similar to an abstract super class in an object oriented model?). The OWS use case requires an (OGC) Web Services profile for GeoXACML that would ideally be build on top of a profile for XML resources of XACML (or alternatively on top of the XML resource relevant sections of the updated multiple and hierarchical resource profile of XACML).





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.



Best regards





Jan Herrmann
Dipl.-Inform., Dipl.-Geogr. 

wissenschaftlicher Mitarbeiter

Technische Universität München
Institut für Informatik

Lehrstuhl für Angewandte Informatik / Kooperative Systeme

Boltzmannstr. 3
85748 Garching

Tel:      +49 (0)89 289-18692
Fax:     +49 (0)89 289-18657



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]