[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: 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] | [Elist Home]
Powered by eList eXpress LLC