xacml — archive
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
— [Date Index]
| [Thread Index]
| [Month Index]
| [List Home]
Re: [xacml] Discussion summary and revised post-condition proposa l
yes, i agree. i think that this is the only way we will be able to
effectively define policy scope (the whole 'applicability' thing: the
former example) and rule evaluation (the latter) in a single schema. i
had try to propose something similar a while back, but not so well
thought out (the 'join' vs. 'add' proposal). the trick now is to be able
to convert this into english :o)
b
Polar Humenn wrote:
> Hi Bill,
>
> I think taking a singular evaluation strategy will not work. You need many
> different combinators to get what you want, and we can make some of them
> standard.
>
> The first and foremost rule/policy combinator I see, is the first
> determinate decision combinator, which is the easiest to evaluate and the
> most intuitive, given the worlds familarity with imperative programming.
> The rules have order, and are listed in order of preference, giving
> implementers the familiar if-then-else-if-then-else-if... strategy.
>
> take-first-decision-and-obligations
>
Takes the first Permit or Deny decision the specified order.
>
Which means for the Combinator T consisting of Policies
>
P1,...,Pn, this combinator T(S,A,R) (where
>
S=subject,A=action,R=resource) returns
>
>
Indeterminate if all Pi evaluates to Indeterminate for all i, 1<=i<=n.
>
OR,
>
Permit with Qk obligations,
>
where Pi(S,A,R) evaluates to Indeterminate for all i, 1<=i<k<=n,
>
and Pk(S,A,R) evaluates to Permit with Qk obligations,
>
and k<j
>
OR,
>
Deny with Dj obligations,
>
where Pi(S,A,R) evaluates to Indeterminate for all i, 1<=i<j<=n,
>
and Pj(S,A,R) evaluates to Deny with Dj obligations
>
and j<k.
>
>
I.e. the rule evaluates to either
>
>
Permit with Qk obligations
>
Deny with
Dj obligations
>
Indeterminate.
>
>
This strategy has the effect of only evaluating the needed policies.
>
Other combinators I fear require evaluating all policies, which
>
is okay, but you have to want it.
>
> The only combinator I see much use for is the following, which is the
> one Bill keeps on about. (All policies must return Permit, (no Denies,
> no Indeterminates).
>
> all-must-permit
>
MUST evaluate *all* policies regardless.
>
>
If all rules evaluate to Permit gather all their
>
obligations for Permit, but if one rule emits a Indeterminate
>
or a Deny, only the Deny obligations are gathered.
>
>
For a set of policies P1,...,Pn, this combinator, C(S,A,R) results in
>
>
Permit with J obligations
>
if for all Pi(S,A,R) evaluates to Permit
>
where
>
J = { Qi | Pi(S,A,R) evaluates to Permit with Qi obligations,
>
for all 1<=i<=n }
>
or,
>
>
Deny with K obligations
>
if *any* Pi(S,A,R) evaluates to
>
Deny with Di obligations or
>
Indeterminate
>
where
>
K = { Di | Pi(S,A,R) evaluates to onDeny with Di obligations,
>
for all 1<=i<=n }
>
>
> Note, any combinator we invent MUST only evaluate to Permit with Q
> obligations or Deny with D obligations.
>
> Cheers,
> -Polar
>
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
— [Date Index]
| [Thread Index]
| [Month Index]
| [List Home]