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