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: 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]