Re: [xacml] Hierarchical actions

[Stefan Bohm <Stefan.Bohm@ic-consult.de>]

I don't think that these actions (read, write, ...) are hierarchically, since hierarchies typically model "is a"
relationships (as in object-oriented design) or supervisor-subordinate relationships (as in organizational hierarchies).
If a subject has write access to some resource, it does not necessarily mean that the subject has also read
access to the same resources. An example for this scenario is the Bell-LaPadula mandatory access control model
where a subject is not allowed to read objects at a higher classification level, but is allowed to write to these objects.

In my opinion the question is, how a typical access control matrix, where a subject has more than one right to an object,
can be efficiently modelled in XACML.


Best regards,

Stefan

Am 26.10.2011 um 18:04 schrieb Erik Rissanen:

> 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
>> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xacml-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: xacml-help@lists.oasis-open.org
>