[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xacml] Obligations rear their ugly head.
Bill - I agree with you. There are many situations where the requestor should be allowed to override a "deny". In such cases, perhaps some stronger accountability mechanism kicks in. I have been expecting that policies could be written to contain an override alternative. All the best. Tim. -----Original Message----- From: Bill Parducci [mailto:bill.parducci@overxeer.com] Sent: Tuesday, April 06, 2004 9:27 PM To: XACML Subject: Re: [xacml] Obligations rear their ugly head. Polar Humenn wrote: > "PEPs that conform with v2.0 of XACML are required to deny access > unless they understand and can discharge all of the <Obligations> > elements associated with the applicable policy." > > With my dad in the operating room this weekend, I found myself stating > to myself, "Gee I hope those IT people didn't install a XACML > compliant PEP." > > All I needed was to have a previous X-ray or Sonogram denied because > somebody put an obligation, such as as in Example Rule 3 in the spec, > "A physician may ...... provided an email is sent to the patient". > > "Provided that"? What if the email system is down? Then the PEP cannot > "discharge" that obligation, and therefore denies. what if the network is down? power is out? there are many things that can lead to a PEP not being able to allow access that cannot be resolved. > First I have an issue with "provided that", of which I thought we > agreed that obligations were not supposed to mean. last i checked the intent was to mean that the PEP must understand and *be* *capable* *of* *fulfilling* the obligation in order to provide access. as to when this happens has remained intentionally undefined (to allow for 'deeply asynchronous' processes, or to a lesser extent possibly to handle situations as described above). > Second of all, what if some IT administrator added a lower level XACML > policy with that obligation without regard for all of the PEPs that > might use that policy? And then the XACML v2.0 compliant PEP denies > the request. what if the same administrator slapped on a combing algorithm on the sonogram policy that was unsolvable in the affirmative? > Furthermore, what are we writing requirements for a PEP anyway? why? deterministic *results* would be a good place to start. > XACML is > about calculating a decision. Granted that decision has semantics that > SHOULD be followed. However, it is up to the enforcement agent to > interpret the decision as it sees fit. i disagree. XACML is about being able to create policies that are interchangeable in a manner such that if applied, will yield predictable results. that is why the text in the spec was written to prevent precisely what you are suggesting; why spend so much time working toward deterministic results if those results are subject to 'interpretation'? if you are opposed to obligations, the solution is not to implement a non-standard PEP, but to implement a PDP that does not support obligations (a completely standard implementation) > I don't think categorically denying things is the answer to ALL > problems. true, which is why it hasn't been suggested here. the spec states that if you don't understand a decision you do not attempt to apply the decision. IF you are using a PDP that implements obligations, then you MUST deny if it provides you with a decision that you do not understand as a result of an obligation. supporting obligations in policies is *option*, ignoring them at enforcement is not. > > If you're looking for a good use case, I just gave you a real one. here's another: there is a buffer overrun in the request parsing on the PDP and the result is unintelligible leading the PDP to issue and ERROR response. solution: do not categorically deny on ERROR? b To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/xacml/members/leave_workgroup.p hp.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]