MHonArc v2.5.2 -->
xacml message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Subject: RE: [xacml] Proposed semantics for operations involving INDETERMI NATE
Didn't we go over all this stuff ad nausem a while ago?
I thought our resolution was that if you encountered something that was
considered "unavailable" in your evaluation, depending on the function
evaluates to true or false yeilding the "effect" according to the rule.
I don't see what is the benifit of ERROR in any case. I believe we should
not be thinking operationally when specifying policy.
It is the job of the PDP to deliver Access Decisions, period, and it is
the job of XACML to specify that access decision. It is not the job of the
PDP to evalautate the consistency, availability, or correctness of that
policy.
If there is an error with the policy, quite possibly due to some transient
condition, then the PDP should deliver an Access Decision, which is one of
Permit, Deny, or Indeterminate.
Errors with the PDP should be limited to operational ones, such as
communication/invocation problems with the PDP and/or unparsability of the
output (from bad PDPs).
Cheers,
-Polar
On Mon, 22 Jul 2002, Daniel Engovatov wrote:
> I suggest the following evaluation strategy.
>
> 1) The is no distinctions made for different functions - order of evaluation
> is determined by the implementation.
>
> 2) Rule, not matching the Subject/Resource/Action head yields NOTAPPLICABLE
> (UNKNOWN) result. No evaluation is performed.
>
> 3) All attributes mentioned in a single condition must be present/computable
> when the rule is evaluated. The case of ordered-OR (logically - not the
> internal optimization) can be handled by defining separate rules and by rule
> recombination algorithm.
> Missing attributes or any other error condition during the rule evaluation
> yield UNDETERMINATE (ERROR) result for this particular rule. I prefer
> "ERROR" moniker..
>
> 4) Following result recombination algorithm choices defined in the standard:
>
> a)ERROR precedence: at least one rule evaluated to
> ERROR(UNDETERMINATE) returns ERROR. Otherwise, DENY override is
> followed.
> b)DENY precedence: if UNDETERMINATE result is reached the
> evaluation is guaranteed to proceed. If at least one DENY is present
> - DENY is returned. If no deny, but at least one UNDETERMINATE -
> UNDETERMINATE is returned, if at least one PERMIT - permit returned,
> otherwise NOTAPPLICABLE (UNKNOWN) is returned.
> c)DECISION precedence: if DENY, of PERMIT is reached, it is
> returned. If no decision, if there is UNDETERMINATE evaluation - it is
> returned, otherwise NOTAPPLICABLE is returned.
>
> So the precedence of results are
> A) ERROR - DENY - PERMIT - UNKNOWN
> B) DENY - ERROR - PERMIT - UNKNOWN
> c) DENY - PERMIT - ERROR - UNKNOWN
> - meaning - at least one rule evaluating to a result with higher
> precedence, returns that decision.
> Evaluation is guaranteed not to stop until all rules, that can yiled
> a result with higher precedence
> are tried (so in a case B, even if a single PERMIT is obtained, and
> no DENY - rules are evaluated to check if no one yield ERROR
> (UNDETERMINATE), case C is our regular DENY override recombination with
> errors ignored: but NOT withing the same condition (see item 3).
>
> 5) Any decision may (including ERROR/UNDERTERMINATE and
> UNKNOWN/NOTAPPLICABLE) may return advice.
>
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Powered by eList eXpress LLC