MHonArc v2.5.0b2 -->
xacml message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [xacml] obligations & error conditions
From: Bill Parducci <>
To: xacml <>
Date: Tue, 13 Apr 2004 14:02:47 -0700
Polar Humenn wrote:
> Now, after that. I still have this problem with the skew toward Deny
> being acceptable.
it is not that the obligations are skewed towards Deny, but that Errors are
typically considered reason for not allowing access on most systems.
the text as rewritten (with your edits) simply states that a PEP must treat the
decision response as an Error if any presented obligation is not understood or
'dischargable'.
> If obligations are not understandable by a PEP, then there is something
> wrong with the "bi-lateral agreement". I think, whether the decision is
> Permit or Deny, if there are any obligations that are not understandable
> or not dischargable, it should be considered an error, and the PEP is free
> to seek alternatives.
agreed: retries, alternate PDP requests, reframing of the question, etc. are all
acceptable mechanisms for dealing with such a situation. however, i think it is
fairly well understood that simply allowing access under such [error] conditions
is counter to developing a deterministically *applied* system (regardless of how
cold it is ;o)
> For example, Access to opening the freezer door from the inside. "Deny
> with obligation to ring security desk."
>
> Mary is denied opening the door because her card doesn't work. It's -30
> degrees in the freezer. The phone at the security desk is busy, because
> Bob, the guard, is talking to his mom.
>
> The PEP following the XACML 2.0 specification, Denies, and declaring a
> "best effort" in contacting the security desk gave up discharging its
> obligation with no consequence.
not really. two things happened:
(1) the PEP did whatever it is configured to do when it receives an error
condition (log, beep, burp, blink, turn itself off... whatever is necessary to
raise the awareness that something did not operate properly)
(2) the subject was not granted access to the resource for precisely the same
reasons why *every* other XACML v2.0 compliant PEP (without the understanding
and capabilities to discharge the obligations emanating from this PDP for this
decision) would do the same.
b
