"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
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:
3898C40CCD069D4F91FCD69C9EFBF0960410332C@txamashur004.ent.textron.com
type="cite">
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
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
|