[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] The context node of an attribute selector plus issue87
Hi Rich, See some discussion inline. Regards, Erik Rich Levinson wrote: > Hi Erik, > > This looks like a good approach to me. This should clear up a bunch > of problems including those in issue 87. My conclusion is that when > XACML 2.0 went out there was some unfinished business having > to do with AttributeSelector and *AttributeDesignator. > > AttributeSelector appears to be meant to pull attributes out of the > ResourceContent node, although line 2715 says their location in > the "request context", which I think is a mistake. Line 2715 is not a mistake. According to Anne it is a deliberate design choice to allow pulling of attributes from the full request context. This is made to support easy access to attributes consisting of structured XML. Basically it's a form of syntactic sugar. However, I don't think it was realized that this makes strict conformance with the spec difficult unless the request context is kept in XML form at all times. So I think we should change this. > The reason I think it is a mistake is because *AttributeDesignator is > already sufficient to pull an attribute out of anywhere in the request > context except the ResourceContent. > > Combine this with Erik's analysis that I think is very valuable that > by confining the xpath lookups to the ResourceContent we can > avoid having to reconstruct XML Request documents where they > have been optimized to higher performing formats. > > It is unlikely that the ResourceContent data would have been changed > from its original format since it can have any xml format and should > be preserved since there is nothing to be gained by changing it. In fact, > we should probably require that this data be delivered to the PDP in > its original form and not be allowed to be restructured except for > possible compression or encryption while in transit from PEP to PDP. > > This provides a nice division of responsibility between xpath lookups > in ResourceContent using AttributeSelector and direct lookups in > the main Request document using *AttributeDesignator. Exactly. This separation allows for easier optimization of the *Designator part. Without this separation, it's very complex to do optimizations. > The only left-over appears to be the somewhat redundant use > of "resource:target-namespace" and "resource:xpath", which team > up to allow a *AttributeDesignator to specify an xpath to an > attribute, again, only sensibly to be located in ResourceContent. > Maybe this provides a way out for systems that do not support > the "optional" AttributeSelector, to be able to xpath into the > ResourceContent. The resource:xpath attribute does provide a different kind of functionality than attribute selectors. With attribute selectors you can write a policy which allows/denies access if the resource content document contains some particular values. For instance, "allow access if the medical record <Patient> element contains 'John'". In this case John is not the resource itself, rather an attribute of the resource. With resource:xpath you can write a policy which allows/denies access to the resource content document itself, based on its XML structure. For instance, "access is allowed for to the <Medications> section of a patient record only". Here the <Medications> element is the resource itself. I think we should keep this attribute identifier. There isn't really any cost with keeping it either since the PDP doesn't need to do anything special with this attribute. It's just clever use of the xpath matching functions. BTW, we should also change the context node of the xpath matching fuctions to the content element. This means that in 3.0 we need to add another parameter to all these functions which will specify which category <Content> element it applies to. (Of course, we should change the identifier of the function id when do this.) So I propose that for 3.0 we will replace the following functions: urn:oasis:names:tc:xacml:1.0:function:xpath-node-count urn:oasis:names:tc:xacml:1.0:function:xpath-node-equal urn:oasis:names:tc:xacml:1.0:function:xpath-node-match with new identifiers: urn:oasis:names:tc:xacml:3.0:function:xpath-node-count urn:oasis:names:tc:xacml:3.0:function:xpath-node-equal urn:oasis:names:tc:xacml:3.0:function:xpath-node-match where the behavior is the same as in 1,x/2.0, except they all take an additional URI argument which specifies the category of the <Content> element where the xpath is applied, and that the context node of all the xpaths is the <Content> node of the given category, not the request element. > Bottom line, I think that this collection of stuff, along with > tidying up the examples to match the now clarified intents, > very likely will put things in the shape that the original > designers may have intended, but never quite cleaned > up all the loose ends. > > Finally, I suggest we drop the XPointer from the examples. > This appears to me to be a spec that has fallen thru the > cracks as the technology has evolved and really doesn't > appear to be needed for anything anymore, except possibly > some legacy implementations of things that are outside the > scope of xacml. Since the examples are non-normative, > our removal of it from the examples should not cause anyone > to claim that we have broken something that was committed > to work, since there is no commitment in any normative part > of the spec. > > Thanks, > Rich > > Erik Rissanen wrote: >> Hi again, >> >> To clarify the two approaches I suggested below, here are examples. >> For instance, assume that someone has defined a structured attribute >> type describing a book, and we have a request like this: >> >> <Request> >> <Attributes Category="resource"> >> <Attribute AttributeId="resource-id" DataType="book"> >> <AttributeValue> >> <Book><Title>This is the title</Title><ISBN>123456</ISBN></Book> >> </AttributeValue> >> </Attribute> >> </Attributes> >> ... >> </Request> >> >> Currently an attribute selector can refer to the isbn number like this: >> >> <AttributeSelector >> RequestContextPath="Attributes[@Category="resource"/Attribute[@AttributeId="resource-id"]/AttributeValue/Book/ISBN"/> >> >> >> (The patch is paraphrased and not strictly correct xpath, but you get >> the idea.) >> >> An expression like this is tricky to handle since the request context >> might not be in XML form and might be dynamically created by the >> context handler. The PDP would need to either a) dynamically fetch >> all possible attributes that could occur in the request context, form >> an XML document of the request and use a standard xpath >> implementation, or, b) use a custom xpath implementation which works >> on the optimized version of the request context and figures out which >> parts of the request need to be generated given a particular xpath >> expression. >> >> Now assume that we do not allow reference to the <Attribute> element >> with the attribute selector and make the <Content> the context node. >> It would no longer be possible to access the isbn number of the book >> with an attribute selector. However, the same effect can be achieved >> by rewriting the policy and/or request. >> >> The first alternative which I suggested is the "explicit accessor >> function". It means that whoever implemented the Book data type also >> implements matching and/or accessor functions to refer to the various >> parts of the book data type. For instance: >> >> <Match> >> <AttributeDesignator MatchId="book-isbn-equals" ...> >> <AttributeValue>... >> </Match> >> >> The second alternative is to place the structured data type in the >> <Content> element (note that the <Content> element is available in >> all categories, not just resource, in 3.0): >> >> <Request> >> <Attributes Category="resource"> >> <Content> >> <Book><Title>This is the title</Title><ISBN>123456</ISBN></Book> >> </Content> >> </Attributes> >> ... >> </Request> >> >> This can the be referenced by an attribute selector (so a bunch of >> accessor/matching functions need not be implemented). But we still >> have the benefit that the rest of the request context can be in an >> optimized/dynamic form, while the content element alone can be held >> in XML form, for easy reuse of existing xpath implementations. >> >> /Erik >> >> Erik Rissanen wrote: >>> All, >>> >>> I got an email from Anne who remembers that the choice of context >>> node was made like this to allow references to nodes in regular >>> attributes whose values were structured XML. >>> >>> I would still be inclined to change this since such references could >>> be done with explicit accessor functions, or those structured >>> attributes could be put in the Content element instead of being >>> "normal" attributes. So there is no real loss in functionality. >>> >>> Regards, >>> Erik >>> >>> Erik Rissanen wrote: >>>> All, >>>> >>>> I have question and perhaps a suggestion, depending on how you >>>> answer the question. >>>> >>>> In XACML 2.0 the context node of the xpath expression in an >>>> attribute selector is the <Request> element. Why is it so, rather >>>> than being the <ResourceContent> element? >>>> >>>> Since it is the <Request> element, it is possible to use the >>>> attribute selector to reference the "regular" attributes outside >>>> the resource content document. Has this been a design goal? >>>> >>>> My concern with this is that I don't really see the need for using >>>> attribute selectors for accessing the regular attributes since they >>>> can be accessed with attribute designators. But making it a >>>> possibility is a problem for an optimizing PDP which does not keep >>>> the full request in the form of an XML document. If we don't do >>>> deeply arcane analysis of the xpath expression in an attribute >>>> selector, potentially an attribute selector could refer to any part >>>> of the request document, and the request document has to be >>>> instantiated as soon as an attribute selector is used, despite them >>>> usually only been used to access the resource content. (Or one has >>>> to implement a custom xpath library which works on the non-XML form >>>> of the request context.) >>>> >>>> This represents quite a significant implementation hurdle and would >>>> also slow down a conforming PDP whenever attribute selectors are used. >>>> >>>> Was there some major benefit seen from the current functionality, >>>> which is seen as more important than these concerns, or is this >>>> just something that nobody thought about? >>>> >>>> Since we are changing the schema for 3.0, which "breaks" the xpaths >>>> in the current policies anyway, I think we should reconsider the >>>> context node in 3.0. I would propose that we make the context node >>>> the <Content> element and use an XML attribute in the selector to >>>> indicate the attribute category of the <Content> element it refers >>>> to. Also, we should say that the xpath expression MAY NOT "climb >>>> out" from the content element to refer to other parts of the >>>> request document. This allows the content to be a stand alone >>>> document for optimization purposes and the rest of the request can >>>> remain in optimized, non-XML form. (And I can imagine that there >>>> are still other kinds of optimizations which can be done once the >>>> resource content is decoupled from the rest of the request.) >>>> >>>> This would also decouple the resource content from the XACML >>>> schema, which would make any future schema change simpler. BTW, if >>>> we want to improve this decoupling even more, we might want to >>>> disallow referencing the <Content> element name or namespace as >>>> well in the xpath expression. >>>> >>>> This also has the benefit to make the xpath expressions somewhat >>>> more readable since we don't need to "dig in" to the content >>>> element using the expression. >>>> >>>> Regarding backwards compatibility with 2.0, XACML 2.0 policies and >>>> requests would still be interoperable with 3.0 in the manner which >>>> we have discussed previously. However, if someone has used >>>> attribute selectors to refers to subject attributes for instance, >>>> these policies cannot be forward ported to 3.0 using attribute >>>> selectors, rather they must be rewritten to use designators >>>> instead. However, I don't see this as a major concern. >>>> >>>> What do you think? >>>> >>>> Regards, >>>> Erik >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe from this mail list, you must leave the OASIS TC that >>>> generates this mail. You may a link to this group and all your TCs >>>> in OASIS >>>> at: >>>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe from this mail list, you must leave the OASIS TC that >>> generates this mail. You may a link to this group and all your TCs >>> in OASIS >>> at: >>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >> >> >> --------------------------------------------------------------------- >> To unsubscribe from this mail list, you must leave the OASIS TC that >> generates this mail. You may a link to this group and all your TCs >> in OASIS >> at: >> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. You may a link to this group and all your TCs in > OASIS > at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]