[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml-comment] Comments on the Hierarchical and Multiple ResourceProfile of XACML 3.0
Thanks again Jan,
I have incorporated your feedback into the sheet of the comments we have
received. We will discuss them in the TC.
Best regards,
Erik
Jan Herrmann wrote:
>
> *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
> <outbind://8-00000000E95EB49608892D41BB762B4A0356A3FD844D2000/www11.informatik.tu-muenchen.de>
> ________________________________________
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]