Hi Stefan,
A couple of points on your response:
The PolicySets and Policys do not have to be fully "evaluated".
In principle, all that needs
to be done is "check" the Effects of the Rules they contain. The idea
is that a Rule with
an Effect = "Permit", for example, has the "possibility" of generating
a Permit, but it is
unnecessary to evaluate the Rule. i.e. if the Target of a Policy is
Indeterminate, then
its Rules do not need to be evaluated. However, for a higher level
policy-combining,
it is of interest whether the Policy "could have" produced a Permit,
for example.
Again, to continue this example, if the top level PolicySet contained 2
Policys, and
the policy-combining was "permit-overrides", then if Policy1 produced a
Deny,
and Policy 2 could produce a Permit, but was Indeterminate, then you
would want
the result to be Indeterminate. However, if Policy 2 could not produce
a Permit,
then you could let the Deny from Policy 1 stand.
Also, note that Indeterminate(D,P,DP) are "internal constructs"
and a final result
of Indeterminate does not carry this information to the PEP.
I also think that if the new combining algorithms are used, that
one must assume
that the Policy must be evaluated sufficiently (i.e. checking the
Effects that the
Rules can generate) to produce the required return values. The Policy
does
have to at least have the Target evaluated to determine Indeterminate,
and there
is no requirement that the Rules cannot also be pre-processed or
post-processed
to collect the necessary Effect information to produce the proper
return value.
Again, this is proposed interpretation, as indicated earlier, there is
not sufficient explicit
statements, however, the degree that implicitness can be implied may
need further
discussion to remove any ambiguities, which cannot be allowed in these
algorithms
if they are to produce reliable behavior.
Thanks,
Rich
wrote:
Hi Rich
If
I understand your proposed
solution correct you propose that in case of an Indeterminate Target
all Rules
in a Policy must be evaluated anyway. If the combined decision would be
Indeterminate(DP) the decision stays as it would be anyway. If the
decision would
be Indeterminate(P) or Permit the Policy decision is Indeterminate(P).
If the
decision would be Indeterminate(D) or Deny the Policy decision is
Indeterminate(D).
Intuitively
I would have
also chosen this solution.
But
I think it allows
multiple interpretations as 7.11 also says that if the target is
Indeterminate the
policies need not to be evaluated and the definition of the extended
Indeterminate value does also only say that a corresponding value may
occur.
So
another interpretation
could also be that the existence of a Rule with the effect is already
sufficient and the Indeterminate value is set according to the
existence of
such Rules.
The
problem I see with these
two interpretations is that a case where one interpretation leads to a
Permit
where the other leads to a Deny can be created.
For
me the answer is
sufficient, but I think it would be great if this could be cleared in
an
Erratum in a way that it isn’t a case of interpretation anymore.
Regards,
Stefan
From: Rich.Levinson [mailto:]
Sent: Montag, 3.
Januar 2011 19:41
To: Oberholzer Stefan
()
Cc:
Subject: Re:
[xacml-comment]
Extended Indeterminate values in the case of Policy Targets returning
Indeterminate
Hi Stefan,
You have raised an interesting question that appears to test some of
the limit
cases of the
combining algorithms, which may not be explicitly represented in the
spec,
although,
possibly they are implicitly covered when examining the details.
I propose that the following might resolve the issue:
Based
on section 7.11 of XACML 3.0, in order for a Policy to evaluate to
Permit or Deny,
at least one Rule must evaluate to its Effect. i.e. if a Policy
contains zero Rules it must evaluate
to NotApplicable or Indeterminate{noValue} (which, for practical
purposes, I think is
equivalent to NotApplicable, since you need an Effect to activate
Obligations or Advice)
Given
then that there are Rules of some sort (either in a Policy or below in
some Policy
contained in a PolicySet) following the Target, which was
Indeterminate, those Rules would
need to be "looked at" or "checked" to determine possible Permit or
Deny outcomes that
could have occurred if the Target had been Applicable.
The
checking needs to follow the policy and rule combining algorithms that
process the
Indeterminate{P,D,PD}cases explicitly.
Hopefully, this helps.
Thanks,
Rich
wrote:
Hi all
I have a
question about the extended
Indeterminate values in the case that the Target of a Policy or
PolicySet
matches to Indeterminate.
I can’t find
any definition
about this case in the specification.
Can you
please tell me which one of
the following solutions is correct?
All rules
appended to the Policy or PolicySet must be checked. If all of
them have the effect Permit, the indeterminate value is
Indeterminate(P). If
all of them have the effect Deny, the value is Indeterminate(P).
Otherwise the
value is Indeterminate(DP)
It can be
assumed that always a rule with a deny effect and a permit
effect is appended and therefore Indeterminate(DP) is returned
All appended
Policies must be evaluated. If all of them are
Indeterminate(P) or a Permit, Indeterminate(P) is returned. If all of
them have
the effect Deny or Indeterminate(D) Indeterminate(D) is returned. If at
least
one is Deny or Indeterminate(D) and another one is Permit or
Indeterminate(P)
Indeterminate(DP) is returned.
Indeterminate
with no value should be returned
If it is the
case that an
Indeterminate is returned I can’t see a definition how this is combined
in the Permit-overrides and Deny-overrides algorithms.
Can
anybody help me in this case?
Regards,
Stefan
