OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [xacml] Action implication and propagation in XACML

I think Seth's message includes an insight into the propagation problem,
that is an "optimization problem". While this problem is difficult to solve
in generic manner, there is a way to tackle each use case basis. It will
work in some cases but may not work in other cases.

Taking UFS for example, I assume that the PEP knows the implicit UFS
resource model that requires two checks: a read permission on the target
resource and an search permission on all the ancestor directories.
My idea is that PEP issues two access requests to the PDP: one for the read
permission and the other for the search permission (but not for all the
ascendant directories). This is partially optimized because the PEP does
not have to issue the request on all the ascendant directories. Now I
assume that the PDP supports one more new value for "scope" attribute:
"Ascendants". Thus, the PEP issues the first request with "Immediate" value
of the scope attribute on the requested resource and it issues the second
request with "Ascendants" value of the scope attribute on the requested
resource, that results in returning multiple access decisions up to the
root node. Then, the PEP checks multiple access decisions and finally
determines whether the access is granted or not. One of the advantage of
this solution is the consistency with the current semantics of the "scope"


                      Seth Proctor                                                                                                      
                      <Seth.Proctor@Sun        To:       Anne.Anderson@Sun.COM                                                          
                      .COM>                    cc:       XACML TC <xacml@lists.oasis-open.org>                                          
                                               Subject:  Re: [xacml] Action implication and propagation in XACML                        
                      2003/05/21 23:54                                                                                                  

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.


You may leave a Technical Committee at any time by visiting

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]