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

•        
filtering

•        
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.

Solution:

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? 

Solution:

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:

Input:

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

Output:

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

 

 

________________________________________

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

www11.informatik.tu-muenchen.de

________________________________________

 

OWS-6_GeoXACML_Engineering_Report-0.1.4.doc