Re: AW: [xacml] Proposal to clean up xpath

[Erik Rissanen <erik@axiomatics.com>]

Jan,

I joined the TC after 2.0 was just ready, so I don't know the history.

But given my own reasoning, to me the main benefit of the attribute designator approach is that it is much more limited than the xpath approach and therefore lends better to be run "in reverse".

To understand the performance issue, imagine a multiple request like this (in "pseudo syntax"):

<Request>
  <Attributes Category="subject">
    ...
  </Attributes>
  <Attributes Category="resource">
     resource-id = foo/descendant:node()
     scope = xpath
    <Content>...</Content>
  </Attributes>

(I am using the current model, not any of the proposed rewrites of the multiple profile.)

The request must be rewritten into individual requests such as this:

<Request>
  <Attributes Category="subject">
    ...
  </Attributes>
  <Attributes Category="resource">
     resource-id = foo/bar[2]/etc[2]
    <Content>...</Content>
  </Attributes>

If the attribute selector can be used to select the resource-id, then these new individual requests must be constructed in a form suitable for xpath evaluation, which typically means DOM trees. Evaluating the attribute selector on the original XML would give an incorrect result.

On the other hand, if the attribute selector can only refer to the <Content> element, then the original <Content> element DOM can be reused for each individual request whenever an attribute selector is to be used. The attribute designator function can be implemented with a special table, constructed from the original request. Updating this table with the resource-id only for each individual request is fairly easy/cheap to do.

What "individual evaluation", I meant to say "independent evaluation". Sorry. I simply meant that one can use the subject to find the applicable policies for the request and since the subject is the same for each individual decision request, the same policies can be reused, without having to find the applicable policies multiple times. Without a clear separation about which xpath in the policy refers to the subject respective the resource, it would not be possible to do this matching.

Best regards,
Erik


On 2009-12-03 12:51, Jan Herrmann wrote:

6E5078C991A7485D9EDDD15FEE91CF0F@lapschlichter55" type="cite">

Hi Paul, Erik,

I added some questions inline (see below).

Another but related question:

The XACML Attributes/AttributeDesignator approach is just a special case of the content/AttributeSelector approach. What was the original reasoning behind adding the XACML Attributes/AttributeDesignator mechanism as a second alternative?

 

Regards

jan

 

---

Von: Erik Rissanen [mailto:erik@axiomatics.com]
Gesendet: Donnerstag, 3. Dezember 2009 11:27
An: Tyson, Paul H
Cc: xacml@lists.oasis-open.org
Betreff: Re: [xacml] Proposal to clean up xpath

 

Paul,

Yes, there are some limitations (some of which we should fix) and some complexity. Maybe we should reconsider them, but there are motivations and I will try to explain why it is as it is currently.

<Content> is under <Attributes> for historical reasons. The <Content> is free form XML to describe the attributes of the resource, or even the subject and so on in 3.0. So it appears conceptually related to <Attributes>. I suppose it won't make much difference where we put the <Content> element in the schema as long we tie it to an attribute category. However, there is a difference between XML content which is not categorized into attribute categories and XML content which is categorized.

Naturally, we could put a single uncategorized <Content> element directly under <Request> and then the PEP can put any XML in it and the policy can then use XPaths to match against the content element. As long as the request contains the XML which the policy expects, this will certainly work as an access control policy engine. (Correct me if I am mistaken, but I think the original work done by Michiharu was something similar to this. It was all XPath based, wasn't it?) You could freely put any information about the resource, subject, or whichever, in this combined XML content.

Making Content categorized has both benefits and drawbacks. The most important drawback is probably that you won't be able to use xpath functions to match across categories. You need to pull up the values with XPath into the XACML functions and do the matching there.

But there are some benefits of categorized XML content as well. One such benefit is that it gives structure, but this might be mostly philosophical, although good structure and architecture often makes things easier in the long run.

The main benefit of the categorized XML content has to do with optimization of multiple decisions. If the XML content is categorized, the XML fragments are independent of each other. This means that the fragments can be referenced independently to generate the individual requests, without the need of combining them into a full XML of the individual request. Also, since the subject and resource are independent blocks, the common subject of all the individual decisions can be evaluated against the policies independently of the resources, leading to much improved performance.

 

I have problems understanding the performance improvements you get if you have separate content elements.

 

If we remove the restriction that xpaths may not span the entire <Request> element, then a) it becomes necessary to construct individual multiple requests in XML form (an XML DOM is usually required for off the shelf xpath implementations),

 

isn't this necessary anyway as you can use xpath on the individual multiple requests

 

 

b) it will no longer be possible to evaluate subjects individually from resources. (At least for a PDP which does xpath based policies)

what do you mean by individual evaluation? There can be semantics where you check if the requesting subject is the owner of a resource (encoded as the owner property of a resource object).

If we remove the restriction that <Content> is categorized, then it will no longer be possible to evaluate subjects individually from resources.

I think the performance of multiple decisions is important for XACML. (Almost everybody wants to do it.) So I think it is worth keeping these restrictions and see if we can fix the issues in use cases we have by other means.

Regarding your point about using XPath functions rather than XACML functions, I think limited expressiveness is in a form one of the goals of an access control policy language. If you wanted as much power as possible, at the extreme you could do it all in Java by defining a request/response API and implementing dynamic loading of the java based "policies".

However, the expressive power also has its drawbacks. For an access control language being able to say Permit/Deny is only part of it. The language must also be auditable and it will often be necessary to run the language "in reverse" to answer questions such as "who can access X", "which resources can Y access", "is there anybody who can access both Z and W", and so on. XACML without XPath is sufficiently restricted so it is possible do this (and indeed Axiomatics has a product for it). However, with XPath it is much, much harder to do this (if it is even possible). The question essentially becomes "which XML content would lead to that this policy with xpaths evaluates to Permit", which is very hard to answer.

I don't understand you last point 3 in the "processing specifications". Could you elaborate?

Thanks,
Erik


On 2009-12-02 20:31, Tyson, Paul H wrote:

"Broken" is too strong a word.  I should say "extremely limited and overly complicated".

 

I'm afraid I must extend the discussion even further, to include consideration of the <Content> element.  Does <Content> belong under <Attributes>?  XML content is supplied by the PEP to the PDP because it is of some interest to the authorization decision.  "Some interest" means: 1) the PEP wants a decision regarding all or part of the XML content; or 2) the XML content contains information required for the decision; or 3) both of the preceding.

 

The goal is to have a request model, a policy model, and processing specifications to satisfy all these use cases.  Here are few points about each of these (more could certainly be added).

 

Request model:

    1. What does it mean to have Attributes[@Category = "foo"]/Content, vs. Attributes[@Category = "bar"]/Content?  Why not allow Request/Content (instead of, or in addition to, Attributes/Content)?

    2. How does the request specify particular items of interest in Content?  (What items of interest does the PEP want to indicate?  What does it expect the PDP to do with them?)

 3. (Multiple) How does the PEP request several authorization decisions with one request?

 

Policy model:

    1. How to allow full xpath functionality for testing XML content?  (Consider multiple Content elements in same request context.)

 2. Does xpath lack any capability for writing rules?  Only add XACML xpath functions to fill gap where xpath fails. 

   

Processing specifications:

 1. Evaluation of AttributeSelector in targets and conditions.

 2. Expanding a multiple decision request into individual requests.

 3. Model must not require close coupling between PEP and PDP--that is, the minimum shared knowledge should be XACML attribute vocabulary and XML schemas of Content instances.  (Implementations are free to couple modules closely, but should not be required to.)

Regards,

--Paul

---

From: Erik Rissanen [mailto:erik@axiomatics.com]
Sent: Wednesday, December 02, 2009 08:34
To: Tyson, Paul H
Cc: xacml@lists.oasis-open.org
Subject: Re: [xacml] Proposal to clean up xpath

Paul,

If it is fundamentally broken, we should fix it, but dropping XPathCategory in favor of an xpath for the context node would break other things.

I understand that an offset xpath needs to be without XPathCategory since the context node is defined by the offset "concatenation" operation. We should perhaps differentiate between an absolute xpath (with XPathCategory) and a relative xpath for offsets/concatenation and make two distinct data types for them. And we might need a concatenation function which can work on these xpaths in order to handle all uses cases. But I don't know whether a fundamentally different approach would be necessary. (Maybe we just disagree on the meaning of the words "fundamentally different". :-))

Best regards,
Erik



On 2009-12-02 14:50, Tyson, Paul H wrote:

I don't want to delay feature freeze, if that is the sense of the TC.  But the proposed 3.0 spec is broken with respect to xpath.  This will limit XACML's usefulness and delay or prevent its adoption in real world applications.

At first I thought it could be fixed with some small incremental changes.  But now I believe it can only be fixed with a coordinated set of changes such as I have outlined.  It is necessary to fix the core features to provide a good foundation for the hierarchical and multiple profiles.

 

--Paul

 

---

From: Erik Rissanen [mailto:erik@axiomatics.com]
Sent: Wednesday, December 02, 2009 03:34
To: xacml@lists.oasis-open.org
Subject: Re: [xacml] Proposal to clean up xpath

Paul,

I am not sure if I understand the proposal, but I have some comments and questions inline.

Beyond that, I think now is not the time to redo everything of XPath in XACML. There are reasons why things are like they are so redoing it without careful thought could cause problems. It has also been a goal for XACML 3.0 that it is compatible with 2.0 in the sense that any 2.0 policy can be re-expressed as a 3.0 policy in a fairly straightforward way. All these issues need to be considered carefully. So this would be a major delay for the TC to do this now.

The TC has multiple times already decided on a feature freeze and I believe many of us want to finish 3.0. The fact that 3.0 is in a constant limbo is holding back other important work such as improving obligations, a standardized XACML request/response API, standardized attribute retrieval and negotiation, etc.

For the rest, see inline.

On 2009-11-29 04:15, Paul Tyson wrote:

We do not use Content, xpath, or AttributeSelector in our XACML

application, but I have been trying mightily to understand how these

features could be used in a real business situation.  I believe the 3.0

spec needs some significant changes to be useful in this area.  I'll

give my specific proposals first, followed by a discussion.

1. Deprecate the use of resource-id (and the other *-id XACML

attributes) with DataType=xPathExpression.  Reserve all *-id XACML

attributes for use as "a primary identifier in the domain of the XACML

application".

I think it's a good proposal to not use "mutating, overloaded" attribute identifiers, so I second this proposal. This already exists as a stand alone issue number.

2. Remove the 3.0 xpath-* functions from the spec.  Continue deprecation

of previous xpath-* function ids.

3. Remove XPathCategory.

The XPathCategory defines the context node of an xpath expression data type value. There is a reason for this attribute, rather than having the <Request> as the context node. Lots of  very basic and important implementation optimizations become impossible to do if any xpath can refer to XML node in the whole request. You can search the list for all the discussion. I think I posted about this just a few weeks ago. The short summary of is the by allowing XPaths to span the <Attribute> elements, all attributes must be expressed in actual XML. That means no lazy dynamic attribute retrieval by the context handler for instance. It also means that fragments of the original request cannot be used for multiple request evaluation. Full individual requests must be constructed in XML for each individual request.

4. Specify 3 new XACML attributes with DataType=xPathExpression, for the

sole purpose of selecting a sequence of nodes in the Content of their

respective categories:

    urn:oasis:names:tc:xacml:3.0:resource:content-selector

    urn:oasis:names:tc:xacml:3.0:subject:content-selector

    urn:oasis:names:tc:xacml:3.0:action:content-selector

These attributes take the place of xpath resource-id, and generalize the

concept to other categories.

5. Add an xml attribute to AttributeSelector called

"ContextAttributeId".  When present, this attribute names the attribute

in the request context that specifies (by xpath) the context node from

which to evaluate the RequestContextPath xpath expression.  This

eliminates the need for XPathCategory.

As I said above, it's a major implementation hurdle to have xpaths span the whole request context. This is why we chose to use an URI XML attribute for identifying the context node, not an xpath.

See attached zip file for Example 2, policy 1 and request rewritten with

content-selector and ContextAttributeId.  There is no need for the

xpath-node-match function, because the required test can be expressed in

the xpath expression itself, given in

AttributeSelector/@RequestContextPath.  In general, there is no need for

any of the XACML xpath-* functions, because the actual xpath language

can be used by AttributeSelector, and the results of the evaluation can

be compared using XACML operators.

Discussion:

In order to make XACML useful for XML content, the full range of xpath

expressiveness must be enabled.  As currently specified, both the

request language and the policy language are severely restricted with

respect to xpath.  Furthermore, the existing xpath features are

difficult to understand and use.

The requirements can be stated in 2 points:

1. The AttributeSelector model must allow the policy writer or the

request context to specify the starting context node for xpath

evaluation.  The concept of a context node for xpath evaluation is

fundamental to the XSLT processing model, for which xpath was developed.

I already proposed a feature to allow the policy writer to specify the

context node for AttributeSelector

(http://lists.oasis-open.org/archives/xacml/200911/msg00033.html).  The

current proposal adds a feature to set the xpath evaluation context node

from the XACML request context.

2. The Attributes model must provide a way for the PEP to indicate what

portion of the XML Content is of interest for the decision.  (In the

absence of any such indication, the assumption is that the entire

content as a whole is of interest.)  I have already mentioned the

problem of overloading "resource-id" with a different meaning when

datatype=xPathExpression.

(http://lists.oasis-open.org/archives/xacml/200911/msg00039.html.)  That

problem is eliminated by deprecating this usage and providing the

content-selector attributes.  In addition, applications can define their

own xpath-datatype attributes and use them for specialized purposes.

I believe that when xpath is fully enabled in the core spec using

features such as I have proposed, many of the other problems around

hierarchical and multiple resources will become less important or will

have obvious solutions.

Regards,

--Paul

---------------------------------------------------------------------

To unsubscribe from this mail list, you must leave the OASIS TC that

generates this mail.  Follow this link to all your TCs in OASIS at:

https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php