Hi Rich,
If it has the same results as the current specification, I would
prefer to not make any changes at this stage. There is always the
risk that we introduce some error by making changes.
Also, I prefer the way the current algorithm is more uniformly
described. It does not need to do a cast to a Rule for instance. It
should not be necessary since the base case for a Rule is already
covered in another section.
Best regards,
Erik
On 2011-05-19 08:01, rich levinson wrote:
4DD4B23B.3050106@oracle.com" type="cite">
Hi Erik,
As I indicated in prev email, this 2nd draft is a slight cleanup
of the syntax, with some
additional comments at the end:
Decision denyOverridesRuleCombiningAlgorithm(Node[] nodes) { // see 1 below
Boolean atLeastOneErrorD = false;
Boolean atLeastOneErrorP = false;
Boolean atLeastOneErrorDP = false;
Boolean atLeastOnePermit = false;
for ( i=0; i<lengthOf(nodes); i++ ) {
Decision decision = evaluate(nodes[i]); // see #2 below
if (decision==Deny) {
return Deny; // loop breakout (#2 below)
}
// the next two "if"s are the same as C.10:
if (decision==Permit) {
atLeastOnePermit = true;
continue; // i.e. skip the rest of the logic for current
// iteration of loop, and start next iteration
}
if (decision==NotApplicable) {
continue;
}
// Ind{} (no qualifier) can only be returned for rules (#3 below)
if (decision==Indeterminate) {
// cast node to Rule, then get its effect
if ( effect((Rule)nodes[i])==Deny) ) {
atLeastOneErrorD = true;
}
else {
atLeastOneErrorP = true;
}
continue;
}
it (decision == Indeterminate{D}) {
atLeastOneErrorD = true;
}
it (decision == Indeterminate{P}) {
atLeastOneErrorp = true;
}
it (decision == Indeterminate{DP}) {
atLeastOneErrorDP = true;
}
} // end for loop
if (atLeastOneErrorD==true &&
(atLeastOneErrorP==true || atLeastOnePermit==true) {
atLeastOneErrorDP = true;
}
if (atLeastOneErrorDP==true) {
return Indeterminate{DP};
}
if (atLeastOneErrorD==true) {
return Indeterminate{D};
}
if (atLeastOnePermit==true) {
return Permit;
}
if (atLeastOneErrorP == true) {
return Indeterminate{P};
}
return NotApplicable;
} // end algorithm
It is intended to produce the same results in every case as the
current C.2 algorithm.
The differences that it embodies are:
- it uses "nodes" as input rather than decisions, where a
"node" can be
any of: {Rule, Policy, PolicySet}
- it preserves the original logic from 2.0 that shows the
evaluate done in each
iteration, which enables the loop breakout as soon as a
certain final result
is obtained (i.e. the explicit "biased" decision type of the
algorithm)
- it preserves(and makes explicit) the logic whereby the D or
P status of
Indeterminate is established; i.e. the qualifiers D,P
originate from the
effect of rules. DP is a result of combining.
The only place an unqualified Indeterminate (Indeterminate{})
can appear
is in the decision that results from evaluation of a Rule, or
from the
evaluation of a Target. However, the unqualified Ind from a
Target will
always be "combined" to a qualified decision, as shown in WD19
Table 7.
Also note, that the above algorithm should be consistent w
Table 4 in
section 7.10, because it is the statement at the beginning of
the loop,
evaluate(nodes[i]), which, when nodes are rules, will produce
a decision
that is an unqualified Ind{}. However, an unqualified Ind{}
can never escape
the algorithm because after the end of the loop on qualified
Ind{D,P,DP} can
be returned.
- It should reduce to the 2.0 algorithms when the
"constraints" that were
implicit in 2.0 are applied (i.e. that the property does not
apply to policy)
This objective needs to be qualified by the fact that in 2.0
deny-overrides
and permit-overrides were not completely symmetric, as d-o did
not
allow any Indeterminate to be returned, whereas p-o did. I
believe the TC
decided when we chg'd to qualified Indeterminates that we
would drop
this "anomaly" as being unnecessary, so it does not appear in
new algs.
- Note that the "evaluate(nodes[i])" is recursive, and this
algorithm should
be viewed as being applied starting with the top PolicySet,
and processing
all children as required by the evaluations. Note also that
there is an
intermediate layer of selecting a combining algorithm before
the next
recursive "evaluate(nodes[i])" is called.
Note also that the recursion must proceed down to the leaf
Rules, because
"evaluate(nodes[i])" will not get any results until a Rule is
reached which
effectively stops the recursion.
While the above comments might appear complicated, they are only
included
for guidance for anyone who is interested in delving deeply into
the mechanisms
that are implicitly present in the evaluation of XACML PolicySets.
Bottom line: the proposal is the algorithm. The comments that
appear in the
list that follows the algorithm are to help people understand the
algorithm.
I believe the algorithm should be able to be inserted as is in
Section C.2, and,
if there is agreement, corresponding algorithms can be prepared
for sections
C.3 -> C.7. Note C.8, C.9, and the legacy sections can
probably remain as they
are, since they do not appear to deal with qualified
Indeterminates.
Thanks,
Rich
On 5/18/2011 11:12 AM, rich levinson wrote:
4DD3E1F5.8060303@oracle.com" type="cite">
Hi Erik,
The algorithm w proposed changes in my earlier email in "first
draft form" was this:
Decision denyOverridesRuleCombiningAlgorithm(Node[] nodes) { // see 1 below
Boolean atLeastOneError = false;
Boolean atLeastOneErrorD = false;
Boolean atLeastOneErrorP = false;
Boolean atLeastOneErrorDP = false;
Boolean atLeastOnePermit = false;
for ( i=0; i<lengthOf(nodes); i++ ) {
Decision decision = evaluate(nodes[i]); // see #2 below
if (decision==Deny) {
return Deny; // loop breakout (#2 below)
}
// the next two "if"s are the same as C.10:
if (decision==Permit) {
atLeastOnePermit = true;
continue; // i.e. skip the rest of the logic current iteration of loop
// and start next iteration
}
if (decision==NotApplicable) {
continue;
}
// see #3 below
if (decision==Indeterminate) { // this can only be returned for rules
if ( effect((Rule)nodes[i])==Deny) ) { // cast to Rule to get effect
atLeastOneErrorD = true;
}
else {
atLeastOneErrorP = true;
}
continue;
}
// the following is same as C.2 and will evaluate the 3 types
// of Indeterminate, which can only be returned for Policy and PolicySet
... same as lines 5762->5776 (not repeated here)
} // end for loop
if (atLeastOneErrorD==true &&
(atLeastOneErrorP==true || atLeastOnePermit==true) {
atLeastOneErrorDP = true;
}
if (atLeastOneErrorDP==true) {
return Indeterminate(DP);
if (atLeastOneErrorD==true) {
return Indeterminate(D);
}
if (atLeastOnePermit==true) {
return Permit;
}
if (atLeastOneErrorP == true) {
return Indeterminate(P);
}
return NotApplicable;
} // end algorithm
It is intended to produce the same results in every case as the
current algorithm.
The differences that it embodies (that do not impact the final
results) are:
- it uses "nodes" as input rather than decisions, where a
"node" can be
any of: {Rule, Policy, PolicySet}
- it preserves the original logic from 2.0 that shows the
evaluate done in each
iteration, which enables the loop breakout as soon as a
certain final result
is obtained (i.e. the explicit "biased" decision type of the
algorithm
- it preserves(and makes explicit) the logic whereby the D
or P status of
Indeterminate is established
- It should reduce to the 2.0 algorithms when the
"constraints" that were
implicit in 2.0 are applied (i.e. that the property does not
apply to policy)
I think it needs one more pass to get the syntax of the
Indeterminates consistent
w the current defns in the doc, but otherwise I am pretty sure
it does the same
as the current. (I will try to clean it up a bit, later today
but I am bust until then)
Thanks,
Rich
On 5/18/2011 4:01 AM, Erik Rissanen wrote:
4DD37CEB.9000706@axiomatics.com"
type="cite">Rich,
Does the algorithm with your proposed changes lead to a
different result in any case than the algorithm which is in
WD-19?
Best regards,
Erik
On 2011-05-17 15:36, rich levinson wrote:
This is not a performance issue. It is
a change from XACML 2.0 that implies
that the combining algorithm has as input a set of decisions
as opposed to 2.0
where the combining algorithm had as input a set of Rules,
Policies, or PolicySets,
that had yet to be evaluated.
The change implies that the algorithm is working on a
different state, which is not
the case.
Thanks,
Rich
On 5/17/2011 5:07 AM, remon.sinnema@emc.com
wrote:
From: Erik Rissanen [mailto:erik@axiomatics.com]
Sent: Tuesday, May 17, 2011 9:35 AM
To: xacml@lists.oasis-open.org
Subject: Re: [xacml] wd-19 indeterminate policy target
handling
The spec should strive for the
simplest possible explanation of the behavior, not the
most efficient implementation.
+1 We can leave it up to vendors to come up with some nice
performance tricks.
Thanks,
Ray
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the
OASIS TC that
generates this mail. Follow this link to all your TCs in
OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS
TC that
generates this mail. Follow this link to all your TCs in
OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS
TC that
generates this mail. Follow this link to all your TCs in
OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
|