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



Thanks for the feedback on this issue.


I have collected the following proposals:

(1) model the action hierarchy with enums

(2) model the action hierarchy in an ontology and extend the policy/request with semantic technology

(3) model the action hierarchy like the resource hierarchy with an action-ancestor-or-self attribute retrieved by a PIP


My criteria for evaluating these proposals are (in order of importance):

(1) Ease of policy authoring

(2) Possibilities for performance optimizations

(3) Ease of implementation


My scoring of the proposals on these criteria is as follows:







Author must use integers instead of action names

Business as usual

Author must use different attribute when there is a hierarchy


Functions other than type-equals may be harder to optimize in some implementations


Slightly slower due to PIP lookup






Based on these scores the semantic approach looks the most promising to me and I will start implementing it in our PDP.


Do people on the TC feel that this is something worth standardizing in a profile?






> -----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 4:01 PM

> 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



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