[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] combining algorithm paper
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-overridesThe 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)>:The "asymmetry" is:
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.
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-overridesThe 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)>:The changes are the following (between corresponding use cases:
i.e. UC1->UC5, UC2->UC6, ...:
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
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:
this slightly larger structural representation, we could introduce
My suggestion is that people look at it and consider one of 3 courses of action:
to "fixing" anything that is wrong. I think any of these configurations may be
desirable for some situations and not for others.
On 6/29/2011 2:15 PM, Bill Parducci wrote:
F06B67CA-7FE6-45F3-8087-6427ABD8D1C4@parducci.net" type="cite">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