Re: [xacml] The context node of an attribute selector

[Erik Rissanen <erik@axiomatics.com>]

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