Re: [xacml] Action implication and propagation in XACML

[Seth Proctor <Seth.Proctor@Sun.COM>]

I've been thinking about this problem for a while
from a couple different points of view, and I'll add
some comments.

First off, I think Anne raises some good issues.
Implication and Propigation (and she labels the two
cases) are difficult problems, and probably useful
to support in one way or another. I would argue,
however, that there is already support of a kind in
XACML, namely the PEP. The PEP is supposed to have
application and environment specific code, and so it
will understand the resource models and know what
action is being requested. When a user wants to read
a UFS file, the PEP can recognize that also requires
execute permission up the tree, and issue requests
for all the execute checks as well as the read
action. Now, I'll admit, this is pretty inefficient,
but it does support the problem we're looking at.

So, I would argue that what we're really trying to
look at is an optimization problem. Some way to let
the PEP issue one request and have that in turn
trigger all the right checks. This also, obviously,
puts common logic in the PDP rather than in all the
PEPs, but after thinking this, I don't think it's a
substantial issue. Of course, this problem about
effectively issuing multiple requests was hashed out
a long time ago in this TC when multiple actions and
resources were considered in a Request. If that was
supported, I would argue, this issue is solved.
Since we can't put multiple actions and resources in
a request, however, we have to dig deeper.

There's another problem here, and that's complexity.
Much of this conversation involves policy elements
that will do a lot of non-obvious things behind the
scenes. This makes it much harder to understand what
a policy is actually doing. Good tools should ease
the burden for most users, but it's still something
to consider.

Finally, there's something that I haven't heard
anyone raise (though I think Anne was getting at
this at the end of her mail). Let's say the action
is read on some UFS file. In order for the PDP to
check on execute permission up the tree, it
effectively needs to form a new Request with the
right attributes, and evaluate that (presumably
recursing until the base case, ie the root, is met).
I'm really not sure how this would be done. It would
either be something that the PDP does right away
because it recognizes the original request for what
it is, or there would be some new function that
knows to issue a new request and wait until that's
been satisfied before continuing with evaluation.
Both of these approaches make me nervous, though the
second one makes a little more sense to me. The
problem with using a custom function is that it must
be explicitly included in the policy, so you lose
the whole implicit model handling which is really at
the core of what's trying to be solved here.

I don't think I've offered any solutions here, but I
wanted to throw out these thoughts for discussion.
Ultimately, I agree with Anne that I don't see a
good solution to this problem, but I'm more than
willing to work towards a solution if a path
presents itself.


seth