RE: [xacml] RE: Hierarchical actions

["Tyson, Paul H" <PTyson@bellhelicopter.textron.com>]

I understand the motivation for this, but the analysis is a bit tricky.

When I hear "hierarchy of actions" I think of a class hierarchy, such
that 'swim' is a superclass of 'dog-paddle', 'crawl', 'butterfly',
'backstroke', etc.  I might want to write rules about swimming in
general, and about crawling in particular, and I would like the requests
pertaining to crawlers to invoke the rules for swimmers without having
to include action-id=swim as well as action-id=crawl in my original
request.

From Remon's list, we have "those who can Delete are a subclass of those
who can Write", etc.  In other words, we are back to a subject
hierarchy, which can be expressed with roles (not always easily or
elegantly).  It is a hierarchy of permissions, not of actions.  Remon
wants to write rules about deleting, and make them automatically apply
to requests about writing, versioning, etc. based on the (non-XACML)
subclass relationships between classes of subjects.

If it were a type hierarchy of actions, we could say "all acts of
deletion are acts of writing; all acts of writing are acts of
versioning;", etc.  I suppose you could construct an artificial ontology
to support some such statements, but that would not be to the point.
And we would still have the problem of how to inform the policy
evaluator about the type hierarchy.

I see two approaches to meeting this use case.  The simpler, more
conventional approach would be to define some sort of "enum" declaration
in a policy.  This would allow the policy writer to associate "Delete"
with "0", "Write" with "1", etc.  Then the rules to allow deletion would
say "if action-id greater-than-or-equal 'Delete'".  This capability
would address other use cases as well, such as rules about resource
sensitivity that use terms like "PUBLIC", "CONFIDENTIAL", "SECRET", "TOP
SECRET" to indicate increasing levels of sensitivity.

A more general approach would specify semantic extensions to the policy
and request languages, and specify semantic behavior of the context
handler and/or policy evaluator.  This would allow XACML components to
read an externally-defined ontology and infer extensions to rules and
request contexts based on class and property axioms found in the
ontology.

Regards,
--Paul

> -----Original Message-----
> From: xacml@lists.oasis-open.org [mailto:xacml@lists.oasis-open.org]
On
> Behalf Of Tolbert, John W
> Sent: Tuesday, October 25, 2011 12:31
> To: remon.sinnema@emc.com; xacml@lists.oasis-open.org
> Subject: [xacml] RE: Hierarchical actions
> 
> Yes.  It sounds like it could simplify policy authoring.  I would be
> interested in seeing a more detailed proposal and comments from
others.
> 
> -----Original Message-----
> From: xacml@lists.oasis-open.org [mailto:xacml@lists.oasis-open.org]
On
> Behalf Of remon.sinnema@emc.com
> Sent: Friday, October 21, 2011 7:01 AM
> To: xacml@lists.oasis-open.org
> Subject: [xacml] Hierarchical actions
> 
> TC,
> 
> We support hierarchical subjects through the RBAC profile and
> hierarchical resources through the Hierarchical Resource profile.
> However, we don't support hierarchical actions yet. I mean support for
> systems where e.g. granting write ALWAYS implies granting read. For
> instance, EMC Documentum uses the following hierarchy for actions:
> 
> Delete	The user can delete the object
> Write 	The user can write and update the object
> Version 	The user can version the object
> Relate 	The user can attach an annotation to the object
> Read 		The user can read content but not update
> Browse 	The user can look at property values but not at
associated
> content
> 
> Writing XACML policies in such a system creates a lot of duplication,
> as each rule targeting Delete must also target Write, Version, Relate,
> Read, and Browse, and so on and on.
> 
> Is standardizing hierarchical actions of interest to anyone else?
> 
> 
> Thanks,
> Ray
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xacml-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: xacml-help@lists.oasis-open.org
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xacml-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: xacml-help@lists.oasis-open.org