Hi Rich,
You are right about that. I think of the target as something to
whether to apply the policy at all. If it applies, then the
combining algorithm happens.
So, yes, my statement was incorrect regarding the policy as a whole.
Typically one would put an open target in cases where one wants to
eliminate all N/A or Indeterminates.
But I do think this is the right way. It's simple and useful. It
would get more complex if one took in the target into the combining
algorithm, so it not only has to combine decisions from its
children, but also the target.
Best regards,
Erik
On 2012-02-25 00:28, rich levinson wrote:
Hi again, Erik,
One lingering question I have about your comment:
" It would be confusing if a policy with
permit-unless-deny
could return not-applicable since this algorithm was
specifically
introduced to guarantee that N/A or Indeterminate are
never returned."
According to the table that you referred to in the current spec,
that you included in your email, it appears to me that if the
Target evaluates to "No-Match" or "Indeterminate" then the
Policy can return "NotApplicable" or a variety of
"Indeterminate"s.
As usual, I expect I have missed something, but Table 5 looks
pretty definitive to me.
Thanks,
Rich
On 2/24/2012 12:08 PM, rich levinson wrote:
Hi Erik,
It looks to me like there has been a subtle shift of emphasis
from
the contents of the Policy determining the Decision to the
combining
algorithm becoming more active in coming to a Decision
regardless
of what's contained in the Policy. This is not necessarily a bad
thing,
but it is a shift of emphasis when considering Policy
evaluation. In fact,
it is probably a good thing, because the algorithm can clearly
state
what all the special cases are and we don't have to rely on a
bottom
up analysis of the individual Rules.
So, the bottom line is that the value of a Policy is equal to
either
a value of NotApplicable or Indeterminate returned from Target
evaluation, or a value determined by the rule-combining
algorithm
applied to a set of Rule nodes, which may have length 0->n.
Personally, I think it is important in this situation that each
combining algorithm explicitly state its intent wrt to 0-length
arrays, or at least there should be an introductory section
to the combining algorithm section that makes this situation
clear. i.e. there is a specific argument passed to the combining
algorithm (Node[] children, where Node can be either Rule or
Policy) and the details of what this argument can contain
and how the algorithm behaves based on that should be clear.
Thanks,
Rich
On 2/24/2012 4:12 AM, Erik Rissanen wrote:
Rich,
You are reading an old version of the spec. The current table
looks like this:
Target Rule values Policy Value
“Match” Don’t care Specified by the rule-combining
algorithm
“No-match” Don’t care “NotApplicable”
“Indeterminate” See Table 7 See Table 7
The change was introduced in wd 20 in order to make sure the
new combining algorithms were always invoked. It would be
confusing if a policy with permit-unless-deny could return
not-applicable since this algorithm was specifically
introduced to guarantee that N/A or Indeterminate are never
returned.
Best regards,
Erik
On 2012-02-23 21:58, rich levinson wrote:
To TC:
To collect the info from today's discussion, which was ref'd
in the
Feb 9 minutes:
the "latest email" I thought Erik and I had agreement that a
statement
would be made in the "implementor's guide" that a Policy w
no Rules
may be ignored by developers:
http://lists.oasis-open.org/archives/xacml/201202/msg00000.html
"It would seem to me that at a minimum, we
could include
an advisory note to developers that a PDP may ignore
a Policy that contains no Rules, since there is no point
from a XACML functional perspective to provide any logic
to do anything specific with such Policies.
Such an approach would remove any questions from
developers,
and could leave the schema unchanged."
During today's discussion, the notion was introduced that
somehow a
combining algorithm could effectively introduce a decision
despite the
fact that there were no Rules in the Policy.
However, I think that interpretation is wrong for the
following reason.
For Policy evaluation, we have to refer to section 7.11
"Policy Evaluation".
According to Table 5 there, the following is normative
behavior:
The policy truth table is shown in Table 5.
Target |
Rule values |
Policy Value |
“Match” |
At least one rule value is its
Effect |
Specified by the rule-combining
algorithm |
“Match” |
All rule values are “NotApplicable”
|
“NotApplicable” |
“Match” |
At least one rule value is
“Indeterminate” |
Specified by the rule-combining
algorithm |
“No-match” |
Don‟t care |
“NotApplicable” |
“Indeterminate” |
Don‟t care |
“Indeterminate” |
Table 5 Policy truth table
I think we can agree that the Target is a "Match", since, by
section 7.7, even
an empty Target matches any request.
Also, I think that rows 1 and 3 that begin with "At least
one rule ..." do
not apply since there are "zero Rules" in the use case we
are discussing.
Since those rows are the only places that cause the
rule-combining
algorithm to be invoked, I think we can assume that even
combining
algorithms, such as "Deny-unless -permit" (section C.6) or
"Permit-unless-deny" (section C.7) will not get invoked.
Therefore, the only thing that is left is row 2, which
states:
"All Rule values are "NotApplicable"". I believe this
statement
is TRUE, because in order to be false there must be at least
one Rule which has a value other than "NotApplicable", which
is FALSE, and therefore the statement is TRUE.
Therefore, a Policy w no Rules must evaluate to
NotApplicable.
QED. :)
Thanks,
Rich
|