Erik,
Yes, content category or something like it is required.
xml:id will not work.
I will summarize this discussion into some specific proposals
on a new wiki page.
Regards,
--Paul
Paul,
An alternative for Request/Content would be to define
a new standard attribute category, such as "common" or "shared" attributes. (I
can't think of a good name). Then you can do:
<Attributes
Category="common"> <Content> ...
</Content> <Attributes>
In this manner we would avoid
the special construct and we could use the same mechanisms in this case as for
"normal" content.
Why do you think xml:id is better than the attribute
category?
The xml:id in the request and the reference in the policy
must match, so the id values must be standardized. In this case I think we can
just make use of the attribute category which is there already
anyway.
And I think that xml:id would cause trouble. xml:id must be
unique, meaning that it is no longer possible to write multiple requests with
multiple <Attributes> elements since they would need to contain the same
xml:id value in order to work with the policy.
If I understand your
xpath-based-context handler proposal correctly, you mean something like
this.
original <Request> with XML <Content>
-> Gets transformed with xpath into a request with
<Attributes> -> is evaluated by the PDP
This still
has the problem that one needs to run XPath in reverse in order to answer
queries such as "What kind of original request would allow access to
X?"
Best regards, Erik
On 2009-12-03 16:00,
Tyson, Paul H wrote:
3898C40CCD069D4F91FCD69C9EFBF096041323F0@txamashur004.ent.textron.com
type="cite">
I'm not suggesting AttributeSelector xpath expressions be
allowed to span the entire Request. Each AttributeSelector should
specify which Content element it refers to. I think xml:id or some
other element-specific referencing mechanism would be better than referring
to the Content's parent category.
I see how Content found its current place under
Attributes, and maybe that needs to be preserved for compatibility.
But Request/Content would allow much more flexibility. Take the
case when the Content is a web service request: the XML contains
subject, action, and possibly resource
information. Such content does not belong in any one
category.
In general, the XML content in a Request is not likely to
contain only resource, subject, or action information. XML is
typically used for heterogeneous collections of data. So it doesn't
make sense for XACML to only provide for "resource" XML, "action" XML, and
"subject" XML.
Regarding your concern about auditing policies or
predicting their effect when xpath is involved: this could be
mitigated by providing a standard mechanism for mapping XML
content to XACML attributes--using xpath, of course! Having such a
standard would provide other benefits also. A use case is this:
email-address might be used as a key attribute by the PIP to look up other
subject attributes such as affiliation, nationality, etc. The
enterprise uses a few different schemas, each of which has a different way
of encoding email address. One option is to code or configure your
attribute-finders to get email-address from each instance type.
But another option is to specify a way in the Request or Policy
model to bind an xpath expression to a XACML attribute. Then you
can write all your matches and conditions using AttributeDesignator,
and rely on the context handler to provide those from the XML content and
the PIP.
Regards,
--Paul
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.
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), b) it will no longer be possible to evaluate subjects
individually from resources. (At least for a PDP which does xpath based
policies)
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:
3898C40CCD069D4F91FCD69C9EFBF09604132002@txamashur004.ent.textron.com
type="cite">
"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
|