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] RE: Hierarchical actions


> -----Original Message-----
> From: Tyson, Paul H [mailto:PTyson@bellhelicopter.textron.com]
> Sent: Wednesday, October 26, 2011 2:39 PM
> To: Tolbert, John W; Sinnema, Remon; xacml@lists.oasis-open.org
> Subject: RE: [xacml] RE: Hierarchical actions
> 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).  

I don't think so. There are no Subjects Who Can Delete, there are only subjects that can delete *a given resource*.

> 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.

*From an authorization standpoint*, that's exactly how Documentum works. 

> 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.

I have two problems with this approach:
1) The 0, 1, etc. make the policies harder to understand
2) The greater-than-or-equal makes the policies harder to optimize (at least for my current implementation)

> 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.

This sounds really interesting. Could you elaborate?


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