Re: [xacml] Hierarchical actions

[Erik Rissanen <erik@axiomatics.com>]

Ray,

Do you really need a full hierarchy? That is, several levels of depth. 
If so, doings something similar to the hierarchical resource profile 
ancestor attributes would be a way to go: "action-ancestor-or-self", 
etc. I guess it could be standardized too.

If you don't need a full hierarchy, you could just group actions. It 
sounds to me from your example that this would be sufficient for your 
case. You would need a small piece of code in the PEP or context handler 
which fills in the group memberships of the specific action being 
performed. In that case you can write your policies in terms of the 
groups, not only the action-id if you prefer.

The augmented XACML request would contain both the action-id and the 
action-group. For example, since the write group of actions also 
includes read, when a read action is performed:

action-id = "read"
action-group = "write"

Best regards,
Erik

On 2011-10-21 16:01, remon.sinnema@emc.com wrote:
> 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