OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[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]