OASIS eXtensible Access Control Markup Language (XACML) TC

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

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

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

Paul, >
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? Thanks, Ray

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

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 >

Stefan, >
Original Message----- > From: xacml@lists.oasis-open.org [ mailto:xacml@lists.oasis-open.org ] On > Behalf Of Stefan Bohm > Sent: Wednesday, October 26, 2011 8:57 PM > To: xacml@lists.oasis-open.org > Subject: Re: [xacml] Hierarchical actions > > 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. I'm telling you it does in Documentum. That's the use case I'm presenting here. Thanks, Ray

Erik, >
Original Message----- > From: xacml@lists.oasis-open.org [ mailto:xacml@lists.oasis-open.org ] On > Behalf Of Erik Rissanen > Sent: Wednesday, October 26, 2011 6:05 PM > To: xacml@lists.oasis-open.org > Subject: Re: [xacml] Hierarchical actions > > Do you really need a full hierarchy? That is, several levels of depth. Yes, see my original use case. Delete implies Write implies ... > 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. Yes, so I could build a Documentum-specific PIP that retrieves the values for this attribute. Thanks, Ray

All,   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:     Enums Ontology Action-ancestor-or-self Authoring Author must use integers instead of action names Business as usual Author must use different attribute when there is a hierarchy Performance Functions other than type -equals may be harder to optimize in some implementations Normal Slightly slower due to PIP lookup Implementation Trivial Doable Trivial   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?     Thanks, Ray   >
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 >  

“ Do people on the TC feel that this is something worth standardizing in a profile?”   If you mean a general approach for dealing with ontologies and semantic web technologies, I agree.  I have over the past two years mentioned  some possibilities in this direction.  If XACML is to remain a viable choice for implementing and executing rules, it must provide a standardized semantic web aspect of some sort.  See my preliminary thoughts at http://wiki.oasis-open.org/xacml/XACMLandRDF .   Regards, --Paul   From: xacml@lists.oasis-open.org [mailto:xacml@lists.oasis-open.org] On Behalf Of remon.sinnema@emc.com Sent: Monday, 28 November, 2011 10:03 To: xacml@lists.oasis-open.org Subject: [xacml] RE: Hierarchical actions   All,   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:     Enums Ontology Action-ancestor-or-self Authoring Author must use integers instead of action names Business as usual Author must use different attribute when there is a hierarchy Performance Functions other than type -equals may be harder to optimize in some implementations Normal Slightly slower due to PIP lookup Implementation Trivial Doable Trivial   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?     Thanks, Ray   >
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 >  

Paul, From: xacml@lists.oasis-open.org [ mailto:xacml@lists.oasis-open.org ] On Behalf Of Tyson, Paul H Sent: Wednesday, November 30, 2011 8:26 PM To: Sinnema, Remon; xacml@lists.oasis-open.org Subject: RE: [xacml] RE: Hierarchical actions > > "Do people on the TC feel that this is something worth standardizing in a profile?" > > If you mean a general approach for dealing with ontologies and semantic web technologies, I agree. Yes, that's what I mean. My current use case of hierarchical actions could be one example. >> I have over the past two years mentioned  some possibilities in this direction.  If XACML is to remain a viable choice for implementing and executing rules, it must provide a standardized semantic web aspect of some sort.  See my preliminary thoughts at http://wiki.oasis-open.org/xacml/XACMLandRDF . << Interesting stuff. I will start a new mail thread with some questions I have about it. Thanks, Ray