OASIS eXtensible Access Control Markup Language (XACML) TC

All, I see no reference to a combining algorithm (CA) in the Hierarchical Resource profile. Are policy writers expected to use the core CAs, or are they expected to write their own CAs specific to this profile? I expected there to be some CA that gives precedence to rules that match lower in the tree. For example, given the following tree of resources: A +-- B +-- C +-- D And two rules that target resource-ancestor at A and D, respectively, I expected the one at D to take precedence for a request with resource-id=D, but I can find nothing in the profile that actually makes that happen. Am I missing something? Thanks, Ray

Hi Ray, I think your question may be a bit outside the scope of the hierarchical profile for the following reason. You have defined 2 independent rules, Rule-A and Rule-D that identify separate resources. Since when one traverses the hierarchy, one first encounters node A, it would seem that should take precedence before continuing the path to node D. i.e. if rejected at node A, you are done, if accepted then you get to try node D. A lot depends on how you construct the Policy. If you used ordered rule-combining then you could place either rule first to achieve whichever effect you preferred. The hierarchical profile is primarily about how to represent the nodes in a hierarchy and addresses a variety of common use cases. It builds on top of the Multiple profile and the core spec, so it is expected that one would use the node representations in that context. If there is another specific context that you have in mind, I would be interested to learn more about it. The use case you have described does not seem to me to have any particular motivation except trying to define some precedence order for applying the Rules which I do not quite understand. Thanks, Rich On 9/5/2011 10:24 AM, remon.sinnema@emc.com wrote: > All, > > I see no reference to a combining algorithm (CA) in the Hierarchical Resource profile. Are policy writers expected to use the core CAs, or are they expected to write their own CAs specific to this profile? > > I expected there to be some CA that gives precedence to rules that match lower in the tree. For example, given the following tree of resources: > > A > > +-- B > > +-- C > > +-- D > > And two rules that target resource-ancestor at A and D, respectively, I expected the one at D to take precedence for a request with resource-id=D, but I can find nothing in the profile that actually makes that happen. Am I missing something? > > > Thanks, > Ray > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >

Rich, >
Original Message----- > From: rich levinson [ mailto:rich.levinson@oracle.com ] > Sent: Monday, September 05, 2011 11:30 PM > To: xacml@lists.oasis-open.org > Subject: Re: [xacml] Combining Algorithms & the Hierarchical Resource > profile > > Hi Ray, > > I think your question may be a bit outside the scope of the > hierarchical profile for the following reason. > > You have defined 2 independent rules, Rule-A and Rule-D that identify > separate resources. > > Since when one traverses the hierarchy, one first encounters node A, it > would seem that should take precedence before continuing the path to > node D. i.e. if rejected at node A, you are done, if accepted then you > get to try node D. If my example resources are file system directories, and the action is write, then I hope this is not the case. No OS should allow me to write in the root, but I certainly should be able to write in my home directory. > A lot depends on how you construct the Policy. If you used ordered > rule-combining then you could place either rule first to achieve > whichever effect you preferred. I guess. I'm not a big fan of rule ordering, though. It just seems fragile. > The hierarchical profile is primarily about how to represent the nodes > in a hierarchy and addresses a variety of common use cases. It builds > on top of the Multiple profile and the core spec, so it is expected > that one would use the node representations in that context. > > If there is another specific context that you have in mind, I would be > interested to learn more about it. The use case you have described does > not seem to me to have any particular motivation except trying to > define some precedence order for applying the Rules which I do not > quite understand. I think that in many cases the precedence order follows quite naturally from the hierarchy, either top overrides as in your example, or bottom overrides as in mine. That's why I expected the Hierarchical Resource profile to define some CAs that implement such precedence. Thanks, Ray

Hi Ray, I think what you are describing is the difference between default = deny (everything denied unless permitted) vs default = permit (everything permitted unless denied). This can usually be accomplished by having permit-overrides combining alg with a final rule of deny (default=deny) vs having a deny-overrides combining alg with a final rule of permit (default=permit). This appears to me to be an orthogonal property wrt hierarchical traversal. Thanks, Rich On 9/6/2011 1:22 AM, remon.sinnema@emc.com wrote: > Rich, > > >>
Original Message----- >> From: rich levinson [ mailto:rich.levinson@oracle.com ] >> Sent: Monday, September 05, 2011 11:30 PM >> To: xacml@lists.oasis-open.org >> Subject: Re: [xacml] Combining Algorithms& the Hierarchical Resource >> profile >> >> Hi Ray, >> >> I think your question may be a bit outside the scope of the >> hierarchical profile for the following reason. >> >> You have defined 2 independent rules, Rule-A and Rule-D that identify >> separate resources. >> >> Since when one traverses the hierarchy, one first encounters node A, it >> would seem that should take precedence before continuing the path to >> node D. i.e. if rejected at node A, you are done, if accepted then you >> get to try node D. > If my example resources are file system directories, and the action is write, then I hope this is not the case. No OS should allow me to write in the root, but I certainly should be able to write in my home directory. > > >> A lot depends on how you construct the Policy. If you used ordered >> rule-combining then you could place either rule first to achieve >> whichever effect you preferred. > I guess. I'm not a big fan of rule ordering, though. It just seems fragile. > > >> The hierarchical profile is primarily about how to represent the nodes >> in a hierarchy and addresses a variety of common use cases. It builds >> on top of the Multiple profile and the core spec, so it is expected >> that one would use the node representations in that context. >> >> If there is another specific context that you have in mind, I would be >> interested to learn more about it. The use case you have described does >> not seem to me to have any particular motivation except trying to >> define some precedence order for applying the Rules which I do not >> quite understand. > I think that in many cases the precedence order follows quite naturally from the hierarchy, either top overrides as in your example, or bottom overrides as in mine. That's why I expected the Hierarchical Resource profile to define some CAs that implement such precedence. > > > Thanks, > Ray >

Rich, >
Original Message----- > From: rich levinson [ mailto:rich.levinson@oracle.com ] > Sent: Tuesday, September 06, 2011 3:04 PM > To: Sinnema, Remon > Cc: xacml@lists.oasis-open.org > Subject: Re: [xacml] Combining Algorithms & the Hierarchical Resource > profile > > I think what you are describing is the difference between default = > deny (everything denied unless permitted) vs default = permit > (everything permitted unless denied). > > This can usually be accomplished by having permit-overrides combining > alg with a final rule of deny (default=deny) vs having a deny-overrides > combining alg with a final rule of permit (default=permit). > > This appears to me to be an orthogonal property wrt hierarchical > traversal. Yes, everything can be implemented with the current combining algorithms by creating a hierarchy of policies. I was hoping to avoid duplicating the resource hierarchy in the policies: I have a gut feeling there is some coupling there that maybe shouldn't exist, which will make maintenance of policies harder than necessary. Thanks, Ray