OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [xacml] wd-19 indeterminate policy target handling


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:
  1. it uses "nodes" as input rather than decisions, where a "node" can be
    any of: {Rule, Policy, PolicySet}
  2. 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)
  3. 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.
  4. 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.
  5. 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:
  1. it uses "nodes" as input rather than decisions, where a "node" can be
    any of: {Rule, Policy, PolicySet}
  2. 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
  3. it preserves(and makes explicit) the logic whereby the D or P status of
    Indeterminate is established
  4. 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




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]