[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] obligations & error conditions
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]