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] Issue: Hierarchical profile appears ambiguous andinconsistent

In the call, Seth stated that few used it. 

I stated that in my experience, systems may initially be set up in such a way that the hierarchy is congruent with the security properties of the Resources, but over time this relationship is lost and hierarchy becomes much less useful than attributes that categorize Resources directly, such as "Public", "Company Confidential", etc.

I also stated that in my career I had seen a wide variety of schemes used to control access to hierarchical resources, some of which had extremely non-intuitive behavior.

Seth agreed with both of these points.

The question remains. Are people not using this profile because it is not a practical strategy after the demo/initial installation phase or because the profile needs more features to be able to emulate more complex hierarchical schemes? In any event, unless a champion for this appears, I expect we will simply try to clarify the existing functionality and leave it at that.

However, this means we need to try to educate the rest of the world, as many people expect to see some kind of hierarchical scheme as a part of an access control policy.


> -----Original Message-----
> From: Anil Saldhana [mailto:Anil.Saldhana@redhat.com]
> Sent: Tuesday, January 20, 2009 9:05 PM
> To: xacml
> Subject: Re: [xacml] Issue: Hierarchical profile appears ambiguous and
> inconsistent
> A question I have is how many folks are really using this hierarchical
> profile in practice.
> Daniel Engovatov wrote:
> >
> > On Jan 14, 2009, at 10:54 PM, Rich.Levinson wrote:
> >
> >>    * There needs to be a definition of "hierarchy". In particular, a
> >>      "hierarchy" defn should state that the fundamental properties are
> >>      that there must be a single root node with no parent, and that
> >>      every other node in the hierarchy must have one and only one
> >>      parent, and can have zero, one, or more children.
> >
> > I am not sure why do you think this is a requirement.   It is a normal
> > use case to inherit policy from more then one parent, and "ancestors"
> > attribute approach allows such models without undue restrictions.
> >
> >>    in order to submit a request  one has to somehow identify all the
> >> hierarchies the given node
> >>      belongs to, all the hierarchies the node's parent(s) and
> >> ancestors to, and include an Attribute element for each.
> >
> > And why is that a problem?   Yes, if one wants "inheritance", graph
> > needs to be defined, and attributes is a natural way to define it.
> >
> >>  I suspect that at most one would need to collect all the normative
> >> representations of only the resource-id node (i.e. identify all the
> >> hierarchies it belongs to), then for each hierarchy, one would
> >> evaluate the policies that apply to that hierarchy.
> >>
> >
> > Policy evaluation does not need to know anything about hierarchies
> > that are represented with an "ancestor" attribute.
> >
> > Daniel;
> ---------------------------------------------------------------------
> 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

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