Hi Erik,
Just to answer your question (see mtg minutes for overall issue
disposition), I will try again
to make the point:
- Assume the current processing location is that the PolicySet
has just been
called for evaluation, and it "knows" it needs to obtain a
decision by sending
an array of Decisions from its children to the combining
algorithm.
- So, the code that knows it needs to send the array of
Decisions to the combining
algorithm now needs to "evaluate" each Policy that it wants a
Decision from and
add that Decision to the array it is going to pass.
- If it wants to send Decisions from all its children, then
there are no issues because
it doesn't have to "know" very much to take this approach.
- However, if it wants to send the minimum Decisions that it can
get away with
evaluating then it must decide which Policies to evaluate, and
it will have to have
some basis for selecting a subset of the full set of 10 Policies
in the example.
- One way to achieve this is for the code to know it is
calling a deny-overrides
combining algorithm, and it can then only evaluate Policies
until it finds a
Deny, and then only submit that one Decision or whatever set
of Decisions
it has accumulated up to that point.
- However, I claim that by requiring the caller to know about
the algorithm
that it is calling and to prune its policy selection
accordingly has a multitude
of undesirable effects, such as:
- It now becomes very unclear to anyone analyzing the
PolicySet, what
criteria are going to be used to select the Decisions to
send to the
algorithm, and as a result makes the PolicySet nearly
impossible to
analyze by simply looking at the Policy and not knowing
details of
the implementation.
- Things get even more obscure when one considers changing the
algorithm for
the PolicySet. If I change to permit-overrides, then which
Policies will then be
selected to send to the algorithm?
- Clearly I can't use the same criteria as above where I
stopped when I found
the first Deny.
- The overall point is that this structure of passing in the
processed nodes as opposed
to the unprocessed nodes puts the burden on the implementer to
decide which nodes
to send in, and, even worse, in my opinion, makes it nearly
impossible for an
administrator to clearly say what the behavior is going to be
based only on the
XACML language of the PolicySet and its descendants.
On the other hand, I believe the proposal I sent earlier, which
requires some modest
changes, with some defined benefits, makes all these potential
issues go away.
This is for the record only, not to impact the decisions made at the
meeting today.
Thanks,
Rich
On 5/19/2011 11:03 AM, Erik Rissanen wrote:
4DD53145.2040602@axiomatics.com" type="cite">
Hi Rich,
Sorry, but I don't understand your second point. The PDP would
just the different algorithm code, right?
Regards,
Erik
On 2011-05-19 16:23, rich levinson wrote:
4DD527E8.9030608@oracle.com" type="cite">
Hi Erik,
Another way to see what the problem is, for the example in prev
email, is the following:
- Let's say I had a really "smart PDP" that knew the
algorithm was deny-overrides,
and so when it first encountered a child Policy in the
PolicySet that produced
a deny, then it would submit only that Decision to the
algorithm.
- That sounds like it might be reasonable as an
"optimization".
- However, let's assume instead that someone changed the
combining-algorithm
to permit-overrides.
- Now it would seem the PDP would have to smart enough to
pick a
different result to submit to the algorithm. i.e. it would
have to
look for a Permit and then stop processing the rest of the
Policiesl.
The overall point is that, as written, I think the algorithms
are going to end causing
a lot more question of the type we have been discussing.
The proposal I submitted, I believe, makes all these types of
problems go away:
http://lists.oasis-open.org/archives/xacml/201105/msg00043.html
Thanks,
Rich
On 5/19/2011 9:42 AM, Erik Rissanen wrote:
4DD51E54.6010802@axiomatics.com"
type="cite">
Hi Rich,
Yes, I noticed too that there is nothing which says what the
input array is. It should be said that it's the result of
evaluating all the child nodes which are to be combined.
But just because the semantics of the algorithm are specified
like this, does not mean that an implementation has to
actually act like this to get the result. As I said in my
other email, the way you wrote it is not necessarily the most
efficient implementation and a PDP may be smarter than that.
The spec is not intended to put restrictions on the
implementation, as long as it gets the same result as
specified.
Best regards,
Erik
On 2011-05-19 15:31, rich levinson wrote:
4DD51BA2.6000709@oracle.com" type="cite">
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
|