MHonArc v2.5.0b2 -->
xacml message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [xacml] WI#9 Proposal: policies referring to hierarchical resources
On 7 April, Daniel Engovatov writes: RE: [xacml] WI#9 Proposal: policies referring to hierarchical resources
> >3. Can we possibly be the first group to run up against this
> >problem? Why aren't there suitable XML schemas and functions
> >already available in some other standard? I have Google'd and
> >asked, but have not found anything so far.
>
>
> Definitely not the first, though I am also unaware on any relevant XML
> schema's designed.
>
> One problem with the proposed approach is that it assumes that structure
> of the resource hierarchy is not only well defined, but also well known
> when the policy is written.
No, it doesn't. The structure of the resource hierarchy is
supplied as part of the Request in the 'resource-content'
Attribute. The Policy merely knows key nodes that represent
roots of important subtrees that need to be protected. If the
Policy doesn't know at least that much, then I don't think you
can write a Policy to protect the hierarchy.
> I think a more flexible approach would be to address the hierarchical
> policies using some well defined profile for resource attribute
> inheritance. That will not impose any particular rigid structure on
> customer's resources.
>
> An example of such approach would be to require the "resource-id"
> attribute to be a bag that includes some resource specific value and
> values of all "parent" resources. Then using some matching and bag
> operation one can target a rule to a variety of resource hierarchy
> subsets.
>
> That does not impose performance penalty by itself, as the "hierarchy"
> can be effectively reconstructed during policy compilation at the PDP.
> But that allows the policy author not to deal with a particular resource
> structure before the policy is actually used.
Actually, I think my proposal is exactly your solution with just
one difference. Instead of "require the 'resource-id' attribute
to be a bag that includes some resource specific value and values
of all 'parent' resources", the proposal does the following:
- The 'resource-id' in the Request is still reserved for the
specific node in the hierarchy to which the Subject is
requesting access. [remember, this proposal is not the one for
addressing a request for multiple nodes in a single request]
Instead, this information is stored in the 'resource-content'
attribute. This is the same solution as that used for
requesting access to multiple nodes in a single request, so it
is consistent.
- Rather than a bag of resource-specific value and values of all
'parent' resources, this information is stored in the hierarchy
that is expressed in the 'resource-content' attribute. I tried
to point out that the 'hierarchy' information is only notional
- an implementation does not have to translate the entire file
system into an XML schema instance, but it allows the policy to
act 'as if' such an instance existed.
I think the hierarchical schema is an easier way to describe
the 'parent' resources and values associated with them than a
'bag'. You would still have to work out a syntax for the
resources in the bag and for how to associate values with those
resources.
And again, since we are already expecting the resource
hierarchy to be described in the 'resource-content' Attribute
for requests for multiple nodes, it makes sense to use the same
concept for policies that protect multiple nodes.
Anne
--
Anne H. Anderson Email: Anne.Anderson@Sun.COM
Sun Microsystems Laboratories
1 Network Drive,UBUR02-311 Tel: 781/442-0928
Burlington, MA 01803-0902 USA Fax: 781/442-1692
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]