[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] wd-19 indeterminate policy target handling
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)
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 normativeThe first line of the algorithm that follows appears to be some kind of
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
Decision denyOverridesCombiningAlgorithm(Iterator decisions)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.
******************************* 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
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"
"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)"
"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
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, email@example.com wrote:
2B109622CFC23D4BA8349254A011FBE001497D4E20@MX27A.corp.emc.com" type="cite">Rich, From: rich levinson [mailto:firstname.lastname@example.org] Sent: Thursday, May 19, 2011 11:38 PM To: email@example.com Subject: Re: [xacml] wd-19 indeterminate policy target handlingJust to answer your question (see mtg minutes for overall issue disposition), I will try againto 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 combiningalgorithm 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 becauseit 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-overridescombining 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 forthe 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 anadministrator 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 modestchanges, 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