Hi Rich,
I would also like to add to this post that I made the point during
the discussion that I think that this model, with the asymmetry, is
probably desirable, although I have not analyzed it in detail yet.
In some cases you want the obligations from all the policies in a
policy set and in some cases you only want them from one of the
policies. With the current model you can achieve both by selecting
the right algorithm.
As an example, you would want obligations from only one policy in a
case when there are "clubs" in which you can be a member to get
access to a resource. There are a red and a blue club, both of which
charge for resource use through an obligation. If someone is a
member of both red and blue, we would not want to charge him twice.
This case can be handled with the permit-overrides algorithm, which
short circuits when it finds on match. You get obligations from only
one potentially applicable policy.
A case where you do want obligations from multiple policies would be
a case where there are multiple conditions which all have to apply
to grant access. For instance, the access must be granted by the
export control policy, the IPR policy and the RBAC policy, and in
each case you want to make an audit record through an obligation. In
this case you can handle this by exploiting the asymmetry of the
deny-overrides algorithm. You would get obligations from all
applicable policies.
Also not that in these examples the asymmetry in the obligation
collection exactly corresponds to the desirable priority in the
effect of the combining algorithm. So it seems we have the right
model. In any case, the model is well defined, and I have not seen
examples of it being wrong. By choosing the right level of nesting
of policies and the right combining algorithm, you can control which
obligations you get. There might be cases where we need more power
though, but that's for beyond 3.0.
Best regards,
Erik
On 2011-06-29 23:43, rich levinson wrote:
4E0BF0E7.2050002@oracle.com" type="cite">
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:
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
|