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: [xacml] combining algorithm paper


Thanks Rich for the summary.

I listened to much of the conversation yesterday and today on the phone, and while I could not follow along with the references to whatever was written on the board, I was able to get the gist of what was being discussed. This added detail is quite helpful, however.

While I think it is important to reach resolution on the mechanics of combination as you suggest, I offer that it is equally important to create a mechanism by which the definition of what an Obligation is can be referred to. I don't mean this in the specification sense, but in terms of "Ob1P (to use your terminology) means do ________". When XACML V3 introduced the ability to federate systems, it also introduced the potential for orthogonal (or even competing, for that matter) Obligation sources of reference. 

Permit and Deny are obvious and unambiguous, so are dealt with cleanly in this situation, but just look at the level of rigor that has gone into Indeterminate and you start to get a feel for the challenge the unbounded space of Obligations creates. Heck, the Obligations themselves are opaque strings with no normative form. It is fine for us to say that a PEP must understand the Obligation or throw an error, but that is a far cry from interoperability IMHO. 

I liken the problem to trying to validate XML without a schema. Sure, you can say it is invalid if it doesn't meet some preconceived notion of how it should be constructed, but that does little to facilitate adoption. This is why I think if we are to seriously take Obligations to the next level we need to look beyond combination and into naming, referencing and construction of the Obligations themselves. Preferably this information would be accessible by querying a PDP/PEP for this type of information so that the situation raised during the meeting of, "You don't even know if the PEP is going to be able to handle the Obligation..." can be addressed prior to the decision. The ephemeral Meta Schema comes to mind as a possible vehicle for this. I am sure there are other options.

Does this make sense?

thanks

b

On Jun 29, 2011, at 8:43 PM, rich levinson wrote:

> Hi Bill,
> 
> I don't think we have got that far yet in our discussions on this. At this
> point my assumption is that all Obligations are equal, and that the only
> determining factor re: their return is that they have been evaluated as
> part of a Policy or Rule and that their FulfillOn attribute has the same
> value as the Decision being returned.
> 
> We started discussing the following example today:
> Policy: combining alg = deny-overrides
> <rule-name>: <effect>: <obl-id>
> R1: Permit: Ob1P
> R2: Permit: Ob2P
> R3: Permit: Ob3P
> R4: Deny: Ob4D
> R5: Deny: Ob5D
> R6: Deny: Ob6D
> The first thing to notice is the "asymmetry" of Permit and Deny in terms
> of which obligations are returned.
> <use case #>: <request #>: <applicable(rule list)>, <not appl (rule list)>:
> 
> UC1: Req1:  A(R6), NA (R1,R2,R3,R4,R5): 
>           result: Deny + Ob6D
>           (determinate: always same result)
> 
> UC2: Req2:  A(R4,R5,R6), NA (R1,R2,R3):
>           result: Deny + anyone and only one of {Ob4D,Ob5D,Ob6D}
>           (indeterminate wrt which of the 3 Ob*D is returned)
> 
> UC3: Req3:  A(R1), NA(R2,R3,R4,R5,R6):
>           result: Permit + Ob1P
>           (determinate: always same result)
> 
> UC4: Req4: A(R1,R2,R3), NA(R4,R5,R6):
>           result: Permit + Ob1P + Ob2P + Ob3P
>           (determinate: always same result)
> The "asymmetry" is:
> 	• When multiple Deny Rules are applicable,
> there is only one Obligation returned,
> however, which one is returned is Indeterminate.
> 	• When multiple Permit Rules are applicable (and no Deny Rules),
> all the applicable Obligations are returned,
> and, obviously, which ones are NOT Indeterminate.
> The intent of further investigation is to determine whether there are
> other reasonable sets of Obligations to be returned instead of the
> prescribed sets above.
> 
> It is not to say the above is "wrong". However, it is not symmetric, and
> may not be intuitive, especially from the point of view of policy designers.
> 
> There were some very good points made at today's meeting in the
> first afternoon session by David Choy, some of which were captured
> in the minutes. One thing I picked up on was that David said that
> legacy models have been largely driven by administrators with ease
> of administration and comprehension being primary requirements,
> and that the resulting models may not fit what a computer science
> trained engineer might think of as good design.
> 
> With that thought in mind, it is now appropriate to look at the paradigm
> above and ask if that is the way administrators would want results to
> be returned from these combining algorithms. Or are there other ways
> to return the results, that the administrators might find more acceptable.
> 
> For example:
> 	• why when multiple denies are applicable is only one ob returned, whereas,
> 	• why when multiple permits are applicable are multiple obs returned?
> A more intuitive result might be to return only one ob. Which one? It doesn't really
> matter because you don't know which one of the multiple denies is returned either.
> 
> This might be viewed as a more user friendly result to return.
> 
> However, I expect, there are others who would think the way it currently is,
> should be satisfactory since it makes programmatic sense, and that maybe
> people should learn more about the algorithm before changing the
> results it returns.
> 
> However, I expect at the end of the day, some people will change their minds
> one way, and some the other, and some will stick with their original intuition,
> which, imo, could be either approach depending on your point of view and
> what you view as sensible and orderly, which varies from person to person.
> 
> So, what I have been suggesting we do, but haven't had time yet, is to consider
> the possible sets of obligations that could be returned for each of the use
> cases above, plus also the ordered cases as well.
> 
> For reference, the ordered case looks like this:
> 
> Policy: combining alg = ordered-deny-overrides
> <rule-name>: <effect>: <obl-id>
> R1: Permit: Ob1P
> R2: Permit: Ob2P
> R3: Permit: Ob3P
> R4: Deny: Ob4D
> R5: Deny: Ob5D
> R6: Deny: Ob6D
> The first thing to notice is the "asymmetry" of Permit and Deny in terms
> of which obligations are returned.
> <use case #>: <request #>: <applicable(rule list)>, <not appl (rule list)>:
> 
> UC5: Req1:  A(R6), NA (R1,R2,R3,R4,R5): 
>           result: Deny + Ob6D
>           (determinate: always same result)
> 
> UC6: Req2:  A(R4,R5,R6), NA (R1,R2,R3):
>           result: Deny + Ob4D
>           (determinate: always same result)
> 
> UC7: Req3:  A(R1), NA(R2,R3,R4,R5,R6):
>           result: Permit + Ob1P
>           (determinate: always same result)
> 
> UC8: Req4: A(R1,R2,R3), NA(R4,R5,R6):
>           result: Permit + Ob1P + Ob2P + Ob3P
>           (determinate: always same result)
> The changes are the following (between corresponding use cases:
> i.e. UC1->UC5, UC2->UC6, ...:
> 	• UC1: UC5 is the same, since only one Deny exists,
> ordering is not a factor.
> 	• UC2: UC6 removes the indeterminacy and always returns Ob4D
> because it is always encounters R4 as the first Deny, which
> terminates the loop.
> 	• UC3: UC7 is the same, since only one Permit exists,
> ordering is not a factor.
> 	• UC4: UC8 is the same, since all the Permits are returned,
> then all the Permit Obs will be returned,
> and ordering is not a factor.
> For the "ordered" case one could say that the asymmetry is even worse
> than in the unordered case. One could reasonably ask: why return only
> one Deny in UC6, but 3 Permits in UC8? If you just returned the first one,
> then it would always be the same and things would make more sense.
> 
> Again people could argue this until the cows come home and never come
> up with the "right answer", which is because there is no "right answer".
> One could argue the "right answer" is to return the results according to
> what the algorithm dictates. But then one could equally validly argue
> back that it would make more sense to change the algorithm so that
> it returns intuitive results rather than least lines of code programmatic
> results.
> 
> With that in mind, my suggestion is that we look at the possibilities that
> are available within the constraints of the parameters of the current
> algorithms, and that where there are uncertainties and asymmetries,
> that we look at these as properties that can be controlled. For example:
> 	• in UC4 we could say only one Permit will be returned instead of 3,
> and it will be the first one encountered, although the others,
> of necessity will also be evaluated.
> This removes the asymmetry between UC2 and UC4.
> This also introduces indeterminacy to UC4, but at least
> UC2 has the same type of indeterminacy, which users might
> find more intuitive and desirable.
> 	• In UC8 we could say only one Permit will be returned instead of 3,
> and it will be the first one encountered, although the others,
> of necessity will still be evaluated.
> This removes the asymmetry between UC6 and UC8.
> It also has the desirable effect that the ordered-deny-overrides
> becomes both determinate and symmetric.
> In order to retain the current behavior and to also think in terms of
> this slightly larger structural representation, we could introduce
> a parameter:
> 	• Parameter: only-one-rule-selected
> when this parameter is false, any rule that is part of the final effect
> will have its obligations included.
> when this parameter is true, then only one rule that is part of the final effect
> will have its obligations included.
> We might then want to think of "ordered" being a 2nd parameter:
> 	• Parameter: ordered
> when this parameter is false we use the deny-overrides results
> when this parameter is true we use the ordered-deny-overrides results
> We could also consider "effect" as a parameter:
> 	• Parameter: effect
> when this parameter is deny we use the deny-overrides results
> when this parameter is permit we would use the permit-overrides results
> That pretty much covers the scope of situations I have been thinking about.
> My suggestion is that people look at it and consider one of 3 courses of action:
> 	• do nothing
> 	• put comments in to current spec to indicate that we are aware of
> these "intuitive" considerations, and explicitly say that the spec
> identifies explicit algorithms for "ordered" = true and "ordered" = false.
> and that the "only-one-rule-selected" is defaulted to false.
> 	• consider expanding/modifying the algorithms to incorporate these
> concepts, possibly along the suggested guidelines above.
> Personally, I see this more as an exercise of cleaning up loose ends as opposed
> to "fixing" anything that is wrong. I think any of these configurations may be
> desirable for some situations and not for others.
> 
>     Thanks,
>     Rich
> 
> On 6/29/2011 2:15 PM, Bill Parducci wrote:
>> On Jun 29, 2011, at 10:32 AM, rich levinson wrote:
>> 
>> 
>>> However, if the policy is ordered-X-overrides, then things are deterministic.
>>> 
>> Thanks Rich, 
>> 
>> The problem is that there is no context for serialization in a mixed environment. Multiple Obligation "namespaces" cannot be resolved. Consider two Obligation Families that must be combined in an ordered fashion:
>> 
>> Obligation Family 1:
>> X < Y < Z
>> 
>> Obligation Family 2:
>> A < Z < Y
>> 
>> If Z & Y are returned whch is enforced?
>> 
>> I offer that there much be something with awareness that spans PolicySets (and therefore federated systems) that can address this. 
>> 
>> b
>> 
>> 



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