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: [Re: [xacml] obligations & error conditions] - PROPOSAL


> First of all, obligations are NOT constraints of the decision!

if you don't understand or cannot discharge an obligation presented in a 
decision you CANNOT permit access regardless of the decision rendered. that 
isn't a constraint?

> And why isn't "Deny" means deny access *only* if you fully understand the
> ....."
 >
 > Why are they different?

because the TC has determined the XACML standard explicitly state that unless 
the PEP is presented with a "Permit" that it *fully* understands the PEP CANNOT 
ALLOW ACCESS. period. you can propose to fundamentally change the specification 
if you wish, but this is what the spec has said for quite some time now.

> The paragraph stated the PEP interpret the decision from the PDP in a
> different way. It says nothing about what the PDP thinks the PEP will
> understand.

again, if the PDP presents a Permit or Deny with an obligation and the PEP 
treats the answer as Indeterminate or NotApplicable the PEP just made and access 
control DECISION.

> It was there mainly to convey the information that if the PEP didn't
> understand an obligation, it can consider the result an "error" (which is
> not defined), so I used Indeterminate, which is defined. And since
> Indeterminate may have reasons associated with it, the PEP can consider
> the reasons for the indeterminate result the problem it has with the
> offending obligations.  That way, it may be able to do something about it,
> like ask somebody what the damn obligation means.

hey, if you are going to *change* the decision why not pick Permit? i am not 
saying that the PDP must now return a decision of "Error", i am saying that the 
PEP must treat it as if there was an ERROR condition. if your PEP wants to bark 
at the moon when there are errors in the decision request process that is fine, 
it just cannot *change* the decision because it doesn't like the answer 
(Permit/Deny w/obligation --> Indeterminate); that is most precise description 
of a standards violation i can think of.

> This paragraph is explicit. Doesn't the PDP return one of four values.
> Permit, Deny, NotApplicable, and Indeterminate? I thought it did. There
> should be interpretations for each result.

no one said that the PDP didn't return one of those answers. the point that we 
are discussing is what happens if there is an obligation with [Permit, Deny] and 
the PEP doesn't know what to do with it. in that case, i have suggested that the 
PEP treat the decision as if the result were incomprehensible (in my world that 
is typically known as an Error).

>>if the PEP makes that DECISION then you have just broken the separation
>>of concerns model that XACML is based upon pretty seriously in my mind.
>>can it try other PDPs? yes. can it rephrase the question? yes. can it
>>decide that NA/I answers will grant access?  NO. and NO.
> 
> Why not?

forgetting for a second that the spec has always specifically stated that this 
is not allowable, assigning [undefined=]unpredictable actions to discrete 
decisions removes any value from the definition of such decisions.

> You say, you grant access *only* if there is a Permit.
> That assumes you only write policies that grant access.
> 
> What if I want to only write policies that Deny Access.
> I don't see a difference of one over the other.

then it only takes ONE 'access' policy to allow you to do that to your heart's 
content:

1. let everyone in
2. don't let bill in
3. don't let fred in
(deny-overrides)

PEP: can polar get in?
PDP: Permit

PEP: can bill get in:
PDP: Deny

one little policy and we can all work together. contrast this to having a PEP 
that decides (*without* *an* *expressible* *standard* by which to communicate 
that decision) to allow everything unless expressly forbidden to do so. this is 
NOT telling anyone how to run their business. this is a practical constraint 
that allows for interoperability.

why? (beat you to it :o) because not having such a constraint removes the basis 
by which there would be any hopes of compatibility amongst compliant systems 
(which is why the spec specifically forbids it). is this mind control? no. the 
policies simply need to be written such that the desired actions are permitted 
and the undesirable actions are not *regardless* of the compliant PEP that 
enforces them. no one is trying to tell you 'how to run your business', but we 
are telling you how to write your policies so as to allow for such interoperability.

> And I then I say you've overstepped your bounds about telling me how to
> run my organization, and I can tell you that you don't have enough
> information about how I run my organization, or even what my policies are,
> and I can tell you to go take a hike. What are you going to do, sue me?
> [...]
> John Ashcroft
 > [...]
> Patriot Act
 > [...]
> duck hunting trip
 > [...]
> sales records
 > [...]
> These words and pseudo requirements are meaningless, much less out of
> scope of what the standard can enforce.
> 
> Again. You don't have enough information on those systems. You're
> guessing. I don't like your guesses.

sorry, but i am not following the hysteria here. what i can tell you is that if 
you bring your PEP to an interop where it is presented with an obligation that 
it doesn't know what to do with and then proceeds to *change* the decision to 
'Indeterminate', or decides to allow unless presented with a Deny, that it will 
not interoperate and will not be deemed compliant. no guesses there.

> For the purpose of transportability of policies and understanding amongst
> writers, the words "Deny" is meant to mean deny access and "Permit" is
> meant to grant access, NotApplicable means that the policy does not apply,
> and Indeterminate means that a decision could not be determined for
> various reasons. Period.

...and you just got done telling me that if your PEP gets a Permit with an 
obligation it does not understand that the *PEP* will CONVERT it to an 
Indeterminate. it is not possible to be any more broken than that.

> Most of that text keeps stating *the* PDP, and *the* PEP. Not multiples.

because the spec condenses down to *one* PEP talking to *one* PDP, we are not 
discussing polysynchronous communication models here. this does not mean a PEP 
cannot ask 500 PDPs for an answer, but for the purposes of how the decision is 
rendered the only way we can define the outcome is on a per decision basis.

>>heck, why stop there? why should XACML say you should Permit on Permit or Deny
>>on Deny?
> 
> It should. That's because one of the chief tenets of the standard is
> transportability of access control policy.

precisely. you are dictating how a PEP should behave in the light of these 
decisions. for the sake of transportability, what you must also do is dictate 
what a PEP does if it is presented with an incomprehensible decision. by 
definition the PEP is presented with a decision of Permit or Deny if given an 
obligation. this unequivocally precludes the PEP 'behaving as if it were given 
an Indeterminate'.

the only mechanism that i can think of that doesn't break the spirit of the 
specification is for the PEP to handle such a situation as an Error. this 
maintains the integrity of the decision and [on most systems] creates a context 
for notification that something is amiss. at that point, the PEP can do whatever 
it is that it thinks is reasonable other than grant access (unless presented 
with a decision that explicitly states that it may do so via a Permit).

> I may have a PEP that asks 27 PDPs, and figures out an comfortable
> majority. It's my policy. I'll do what I need to for my application.

'figures out an comfortable majority'? hmmm... interesting. policy combination 
algorithms on the *PEP*.

> Look, if you build a PEP that behaves the way you say. Denies unless there
> is unequivocal Permit that's fully understood. It takes an XACML PDP on
> one end, and allows an application on the other. That's fine.
> 
> Now, if I'm a buyer of software products. I see that your PEP denies on
> anything, but a Permit.  Okay, that may be well and good for 85% of all
> customers.

can you give me an example of the 15%? if you want to have a PEP *behave* as if 
it allows everyone in unless specifically told not to you can do this easily 
with the current spec (the example above does just that).

if you find none of this persuasive then i suggest that you submit a proposal to 
the TC to change the specification in a manner that is consistent with your views.

b


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]