To TC:
In order to make this issue concrete, I gave an example earlier that
we can
discuss that I think will address this problem:
http://lists.oasis-open.org/archives/xacml/201105/msg00036.html
"... if I am in a deny-overrides PolicySet,
and there are 10 child (deny-override) Policy elements, for
example,
and I "evaluate" the first Policy and it in turn evaluates its
child Rules,
if its first, or any other, rule returns a Deny, then the first
Policy will return a Deny,
and there is no need to "evaluate" the other 9 Policy elements
since the
decision will be a Deny regardless of what they return."
I think that C.2, as written, insists that the other 9 Policy
elements must
be calculated, since the input to the algorithm is an array of
Decisions,
presumably the Decisions resulting from evaluating the child
Policies of
the PolicySet.
The question is: how are the child Policies selected for input? I
would think
that is exactly what the combining algorithm determines. i.e. it
combines
the Policies according to a script and determines which decision
from which
Policy governs its result.
If that is not the case, then what determines the contents of the
input array?
i.e. I believe the algorithm must clearly state what the inputs are
that it is
processing.
As written, it appears to me that C.2 effectively requires running
the algorithm
on the child Policies before passing the results in to run the
algorithm.
Thanks,
Rich
On 5/19/2011 8:44 AM, rich levinson wrote:
4DD51097.6030209@oracle.com" type="cite">
Hi Erik,
In principle, I would agree that if the p-code produces the same
results from
an end user perspective that the details of the implementation
(namely the
p-code translated to a native language) would be incidental.
However, the way the spec is currently set up, the verbal
description, lines 5727-5738,
is defined to be:
"a non-normative informative description of this
combining algorithm."
whereas the p-code, following line 5739 is defined to be:
"the normative specification of this combining
algorithm."
Therefore, I think it is necessary to raise an issue as to what
aspects of this
combining algorithm are normative. For example, is it necessary to
calculate
all the decisions prior to entering the algorithm.
Thanks,
Rich
On 5/19/2011 6:02 AM, Erik Rissanen wrote:
4DD4EAC0.8050300@axiomatics.com" type="cite">
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
|