[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, –
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). 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 •
no pointers to XACML
decision request data inside an XPath predicate •
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 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? 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 Comment 6: Line 157: usefulness Comment 7: Line 162+163: overloaded and therefore
misleading formulation (critical) 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) 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. Best regards Jan ________________________________________ |
OWS-6_GeoXACML_Engineering_Report-0.1.4.doc
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]