Re: [xacml] first proposal for hierarchial resources

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

> This is a draft proposal for the xacml 1.1 work
item 'Fully 
> specified hierarchial resources'.

This is an interesting proposal. It adds a lot of
complexity to the PDP, but could make things much
more efficient (the alternative being that the PEP
knows about models, knows what "search" requires,
and does separate queries "up" some tree). I'll
admit to having mixed feelings, but I'm willing to
be convinced. Unsurprisingly, I have a couple
questions. :)

First off, it seems that rather than trying to
define how you resolve hierarchical resources,
you're only defining how policies relate to each
other in some hierarchy. Is that correct? It looks
like the model URI could provide that information,
but since you then want to define some relationships
in the policy, it's not clear to me what the model
URI is used for (it would be much easier to write
these policies if the model was the only addition
and it defined everything).

> In this proposal resource model is defined for the
policy and does 
> not vary from rule to rule. For the motivation
behind this consider 
> xml document use case. One can select abstract
tree model or dom 
> model. These two models have different
requirements and different 
> syntax.

I'm a little concerned about writing policies that
only work for a particular resource framework. I
would think that I should be able to write a general
policy that says "reading requires searching" and
not have to replicate that for each resource
hierarchy I use. Why not put information about the
hierarchy model in the request instead?
 
> Resource model can specify permission
propogations. For example, 
> 'search' permission on a directory in a file
system requires 
> 'search' permission on all ancestor directories up
to the root.

How exactly will you recognize the "search" action?
There is no required or standard action attribute,
so there's no way to know what kind of action the
request is specifying. There is a line in the spec
about an action-id attribute, but there is no
description or suggestion of how to use it, and
since it's not required, there's no guarentee that
it will be in a request. It seems to me that both
the PropigationRule and Implication tags reference
some URI that is an action.

Another question: how do you know to look for "read"
or "search"? These aren't standard URIs. Are you
going to define standard action URIs to go with each
of the resource model URIs? If the models are
standard, then it seems to me that they will also
need standard actions since those actions need
standard sematics, or the models won't make sense.

> Resource model can state that 'search' permission
on a node 
> propogates 'search' permission on all ancestor
nodes, unless 
> overwritten by other rules.

Again, I'm confused about the role of the model URI.
If a policy can suddenly redefine the way that the
resource hierarchy works, what is the model
providing? Shouldn't the model be a constant that
always defines the way a hierarchy works? I can't
specify a UFS directory that doesn't require search
permission up the tree to search the current
directory. Why? Because that would confuse things,
and make it hard for software to function correctly.
 Likewise, how will policy and PEP writers know how
to handle these sudden changes?

Along these lines, how do we know what "up" or any
other direction means? This has to be something that
is defined by the model, so the model must be
something concrete that can be looked up and used to
handle some direction.Specifically, the identifier
"up" will have to be mapped to some mechanism that
can look for the resource that is "up" and get the
accompanying policy. This is non-trivial. I would
feel much more comfortable if there was a more
concrete description of how these features were
used, not just what they're supposed to mean.

Finally, while you've clearly defined how some
relationships are laid out, I don't see anything
about how policies are supposed to be enforced. For
example, do we look at the PropigationRules and
Implications as soon as a request arrives? After the
request has been satisfied? When using the model
information to lookup the next policy "up" do we
need to apply the PropigationRules to get that
resource? What if that loops or otherwise causes the
PDP to hang? There's a lot of the "what" in this
propsal, but not a lot of the "how." I'd like to see
some of that get fleshed out. Even if XACML
shouldn't be defining any of this (though I think it
should), I'd still want some convincing arguments
that this will actually work. Like I said at the
start, I'm willing to be convinced, so these are
real questions. I'm curious about how all these
details will work together. If it can be built, if
it doesn't confuse the sematics, and if it doesn't
slow down the system too drastically, I'm willing to
give it a try.


seth


ps  I'm still a little puzzled about where this
propsal came from. The original idea was just to
define a few standard models so that children and
descendant resources could be resolved in a standard
way. Once that's done we know how to find policies
for those resources. Also, everything that's being
proposed here can already be done by using policy
references (ie, if an action of "search" is issued
on a given resource, the policy can say that the
"up" policy must be referenced). There's no standard
way to map that to the resource model, but I don't
see that this is needed if the models aren't
constants that can be used to define all interactions.