MHonArc v2.5.0b2 -->
xacml message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [xacml] Obligations rear their ugly head.
From: Bill Parducci <>
To: XACML <>
Date: Tue, 06 Apr 2004 18:26:40 -0700
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
