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

[rich levinson <rich.levinson@oracle.com>]

Hi Ray (and Paul, and TC),

(Part 1 is to Ray/TC, Part 2 is rsp to Paul re: yesterday's mtg
about whether this discussion is part of issue raised on list, and
Part 3 is some "items" I found in the spec that might be quick
fixes. Decided to combine to 1 email because none of the parts
really represent a separate issue and all are loosely related to
the current issue)

Hi Ray,

Thanks for taking the time to comment on the email where I tried
to explain my ongoing concern (which I basically agreed at yesterday's
meeting to defer to an implementation guide document that we have
had an ongoing "commitment" to produce at some unspecified future
time :) ).

In any event, the primary reason I am looking for closure on this
issue is that I get questions from developers on a regular basis
about XACML, and now that 3.0 is imminent those questions are
turning in that direction and I need to be able to explain
what's going on.

That being said, maybe we can rephrase the issue as to what it
means when it says on line 5739:

"The following pseudo-code represents the normative
  specification of this combining algorithm."

The first line of the algorithm that follows appears to be some kind of
interface signature:

Decision denyOverridesCombiningAlgorithm(Decision[] decisions)

It sounds to me like what you are saying is that when a software
development organization sees that in the specification,
that said organization will be completely comfortable by implementing
the parameter, Decision[] decisions, by passing in an Iterator to a collection
of Decision objects that have not yet been resolved.

In other words, if a development organization first implements
this algorithm by passing in a precalculated array as represented
by the normative interface signature, and then they complain
that it is too inefficient, that I can tell them to pass in an
Iterator to a collection of unprocessed nodes and just calculate
the Decision objects in the first line of the loop. For example,
I could suggest that the first line of the loop look something
like:

    Decision denyOverridesCombiningAlgorithm(Iterator decisions)
    ...
    for ... {
        Decision decision = evaluate(decisions.next())

where Iterator.next() returns a PolicySet, Policy, or Rule, and "evaluate()"
produces the Decision.

If that is what you are suggesting and people agree, then I am ok with that,
as well, I think, assuming people really believe that this is an acceptable
view of the specification.

    Thanks,
    Rich

*******************************  end part 1

Part 2: re: Paul's comment at yesterday's mtg that original question was
Target, and not what yesterday's discussion was about:

    Also, to Paul's comment at yesterday's meeting that this
    discussion was originally about the Target, which I agree
    with, my response at mtg was that this aspect we are currently
    discussing arose from the analysis of the Target. In particular,
    one of the key issues w the Target, was whether or not
    the underlying Rules (or Policies or PolicySets) needed to
    be evaluated. My initial inclination was that they did not,
    but the following discussion convinced me otherwise.

    What ultimately convinced me was the realization that
    w/o looking at the rules, since the rules are the only
    place where D and P are defined, that there was no way
    to then assign D,P,or DP to the Indeterminate found by
    the Target.

    Then, based on that understanding, it became clear to me
    that it was not sufficient to just look at the list of
    D's and P's, because, if the Target had not been
    Indeterminate, then rules would be evaluated and the
    result might be completely different than if one did
    not evaluate the Rules. It seemed to me a bad idea that
    the collection of rules could produce a different
    result dependent on whether the Target was Indeterminate
    or not. Therefore, since we have to evaluate the Rules
    when the Target is not Indeterminate (and not NotApplicable),
    then for consistency, if we wanted a D, P, or DP to come
    out of the Rules, then in both cases, regardless of the
    result of the Target, we had to evaluate the Rules.

    It was while going thru this analysis of what it meant
    whether or not we evaluated the rules that this other
    aspect of the issue that we are discussing came up.
*******************************  end part 2

Part 3: some minor issues that could possibly be quickly addressed:

    1. line 569:
        "A policy comprises four main components"
       should be:
        "A policy comprises five main components"
    (because Advice was added)

    2.  I found some lack of clarity wrt "Named Attribute" in a few spots:

    section 5.9 (1609-10) is somewhat ambiguous wrt to what it is
    trying to say, and clarification needed to section 5.29 as
    to what is the "named attribute" vs the "attribute"; i.e.
    the named attribute appears to be specified by the subelements
    of the AttributeDesignator element (which turn out to be consistent
    w defn in sec 7.3, but not particularly w glossary).

    also lines 47-50 should probably change:
        "the identity of the attribute holder
         (which may be of type:
         subject, resource, action or environment)"
    to:
        "the category of the entity holding the attribute
         (which may be of category:
         subject, resource, action, environment, or other)"
    note: see 2b below for usage of term "entity"

       2a. Named attribute: best defn appears sec 7.3, lines 3220-3221:
        "A named attribute is the term used for the criteria
         that the specific attribute designators use to refer
         to particular attributes in the <Attributes> elements
         of the request context."
        recommend ref'ing this in section 5.29, end of 1st para.

    2b. I think, in general that the Attributes element is missing a noun. i.e. an
    Attributes element is a collection of Attribute elements, where the
    Attributes element specifies the Category to which this collection
    belongs. The question is: Category of what?

    i.e. there is no word to collectively refer to Subject, Resource, Action,
    Environment, etc. Simply saying they are the name of a Category
    is incomplete.

    In any event, my suggestion is we start referriing to a collection of
    a specific category of attributes as collectively referring to an "entity".
    This is pretty much consistent with the document as is, but could
    use a couple of tweaks, which could be quickly identified if people
    agree to this change.

    4. line 3093: should last word of first sentence be "undefined"
        rather than "defined"?


*******************************  end part 3






On 5/20/2011 2:34 AM, remon.sinnema@emc.com wrote:

2B109622CFC23D4BA8349254A011FBE001497D4E20@MX27A.corp.emc.com" type="cite">

Rich,


From: rich levinson [mailto:rich.levinson@oracle.com] 
Sent: Thursday, May 19, 2011 11:38 PM
To: xacml@lists.oasis-open.org
Subject: Re: [xacml] wd-19 indeterminate policy target handling

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. <<

The current WD presents a conceptual explanation of how the algorithm should work, not an actual implementation. Therefore, the "array" of Decisions is not an actual array in the programming language sense. Instead, the algorithm could be implemented in a programming language to receive an iterator of Decisions, and the iterator could be lazy, meaning it will only evaluate the next Decision when that Decision is requested by the combining algorithm.

This is an implementation detail, one that we should leave to vendors implementing the spec. All we should care about is that we have a description that allows vendors to implement the algorithms in a consistent manner, and that there is at least one efficient implementation imaginable. Since I've given one above, I think our work here is done. Do you agree?

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. <<

This is not true, see my comment about lazy iterators above.

* 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. <<

No, the combining algorithm should drive which subset to evaluate.

o 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.
o 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. <<

Not at all. The current WD specifies the conceptual workings of the algorithm, and that should be enough to analyze the PolicySet.

* 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?
o 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 <<

No, see my comment about lazy iterators above.

, 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. <<

I don't understand that claim at all. The current description is clear to me as to what effect the combining algorithm should have. What do you think an administrator will not understand?

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. <<

I agree with that statement, but I still prefer a conceptual description over one that is implementation-centric. We should not steer vendors in a certain direction, but give them as much freedom as possible to come up with innovative solutions.


Thanks,
Ray