Re: [Re: [xacml] obligations & error conditions] - PROPOSAL

[Polar Humenn <polar@syr.edu>]

On Wed, 14 Apr 2004, Bill Parducci wrote:

> >>line 3130:
> >>A PEP SHALL allow access to the resource only if a valid XACML response
> >>of "Permit" is returned by the PDP.  The PEP SHALL deny access to the
> >>resource in all other cases.  An XACML response of "Permit" SHALL be
> >>considered valid only if the PEP understands and can and will discharge
> >>all of the obligations contained in the response.  An XACML response of
> >>"Deny" may also be accompanied by obligations.  In this case, if the PEP
> >>understands the and can discharge the obligations it MUST deny access and
> >>make best efforts to discharge the obligations; otherwise the PEP MUST
> >>treat the decision by the PDP as an ERROR.
> >
> > This still doesn't address my concerns. In the Permit case you seem to be
> > issuing a SHALL requirement on discharging obligations, while in the Deny
> > case, you are issuing a SHOULD (best-efforts).
>
> we can say that it SHALL discharge the obligations, but the reality is that even
> if the obligations cannot be discharged the effect is deny because the PEP has
> to *do* *something* (doing nothing is doing something for access control). there
> is no such thing as 'sorta allow' or 'sorta deny' that i am aware of, so is the
> alternative, 'if the PEP is presented with a Deny + Obligations and it doesn't
> understand the obligations it should...' allow access? spin a big wheel?

It will follow the POLICY of the organization in which it is deployed.

> > I don't agree.
>
> i can see that ;o)
>
> > The second sentence also says that the PEP SHALL deny access "in all other
> > cases".  The paragraphs might as well just end after that sentence.
> >
> > That single sentence alone says, if you don't get a Permit, then Deny.
>
> ...except that the rest of the paragraph attempts to explain what a "Permit" &
> "Deny" are (they have obligations vs. NA/I which do not) and what the
> ramifications of this difference entails (which seems to be the very basis of
> this thread)

Then that paragraph is contradictory.

> > which leaves absolutely no room for dealing with this "error" thingy
> > (which is not defined), or even NotApplicable.
> >
> > Why cannot this paragraph simply state the requirements are for
> > interpretation of the most simple model, which governs the common
> > understanding that you write XACML policies, such that "Deny" means do not
> > grant access, and "Permit" means grant access.
>
> because it is important that "Permit" and "Deny" are fully expounded upon to
> alleviate 'interpretation' of what they may mean. "'Permit' means grant access
> *only* if you fully understand the constraints of the decision".

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

And why isn't "Deny" means deny access *only* if you fully understand the
....."

Why are they different?


> > A PEP that relies on a decision from a single PDP, and it receives a
> > decision of Permit from that PDP, this PEP SHALL allow access. If this PEP
> > receives a decision of Deny from that PDP, this PEP SHALL deny access.
> > Either decision may carry with it obligations. It is this PEP's
> > responsibility to discarge those obligations. Should this PEP not
> > understand or cannot discharge any of the obligations, this PEP shall act
> > as if the PDP returned a decision of Indeterminate with reasons concerning
> > the understandablility or discharging the offending obligations.
>
> just curious as to how you consider the decision "Indeterminate"? the
> PDP made a decision and that decision was clearly stated. how does the
> PDP know that the PEP cannot understand the Obligations when the answer
> it gives is "Permit" or "Deny"?  furthermore, if the PDP doesn't know
> that the PEP cannot understand its decisions how is it expected to
> provided 'reasons concerning the understandability'? as far as the PDP
> is concerned everything is OK.

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.

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.

> > If this PEP receives a response of Indeterminate or NotApplicable its
> > action is out-of-scope as further action MAY be taken by the PEP depending
> > on its configuration and capabilities. Further action MAY include, but is
> > not limited to, denying access outright, looking up values for misssing
> > attributes and resubmitting the access control request, looking up
> > incomprehensible obligations, or requesting of an alternate PDP.
>
> again, how does the *PDP* know this is "Indeterminate"?

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.

> 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?

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.


> >>line 3478:
> >>A PEP that receives a valid XACML response of "Permit" with obligations
> >>SHALL be responsible for discharging all of those obligations.  A PEP
> >>that receives an XACML response of "Deny" with obligations SHALL be
> >>responsible for discharging all of the obligations that it understands
> >>and is capable of discharging. If the PEP cannot understand the
> >>obligations provided by the PDP it must treat the decision by the PDP as
> >>an ERROR.
> >
> >
> > Again, this is skewed toward Deny.
>
> no it isn't. the *decision* is absolutely neutral. what is 'skewed' is the
> implementation constraints and that is necessary to make sure that when two PEPs
> are given the same decision they behave the same way (given teh same level of
> understanding). again, one of the PEPs may go looking elsewhere for information
> but until it finds a PDP that tells it to do something different (in a manner
> that it can understand) it MUST physically deny access.

That is a matter of organization (local) configuration POLICY.

> > A default policy is the configuration issue for the particular application
> > that deploys it.
>
> that is true to a point. if you have a system that: ignores obligations, permits
> on "Indeterminate", or permits on "Not Applicable" you have a system that is NOT
> conforming. period.

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?

Are you going to be a John Ashcroft, invoke the Patriot Act, and start a
duck hunting trip, gathering sales records of people who bought XACML
compliant PDPs and see if they are using them the way you want them to?

These words and pseudo requirements are meaningless, much less out of
scope of what the standard can enforce.

> > You can tell me how I SHOULD use your product, but You are NOT going to
> > tell me how to run my organization!
>
> then write policies that don't break your systems. this has nothing to do with
> business processes. quite the opposite, what is being said here is that we want
> to make sure that if a policy says to do something under certain circumstances
> (with qualifications if desired) that it will actually be done the same way
> using two or more systems that implement the same specification (with the same
> capabilities).

Again. You don't have enough information on those systems. You're
guessing. I don't like your guesses.

> > I don't agree. Again you are writing requirements on points you have no
> > knowlege about and you cannot control. You're guessing, and for lack of
> > information, you may be making the wrong decision.  Like our current
> > President.
>
> i am not guessing about anything. i am trying to prevent some anarchist PEP
> developer from creating a system that will ignore the reasons the underlying
> principles of the standard because he doesn't want to be 'mind controlled by the
> man' :o)

We are not writing a standard about a PEP.

We are writing a standard about an XML form of a policy language geared
toward getting an access control decision from any policy written in that
language evaluated against the information represented in a Request
Context.

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.

> > Deny is meant to be deny access
> > Permit is mean to be grant access.
> ...so long as you fully understand what Permit means
>
> and
>
> Indeterminate means deny access lacking another other decision to the contrary

In your world, fine. In my world, it depends upon its configuration and
other factors that you don't know about, that you cannot know about.

> and
>
> NotApplicable means deny access lacking another other decision to the contrary

In your world, fine. In my world, it depends upon its configuration and
other factors that you don't know about, that you cannot know about.

> that is EXACTLY what the spec has said since day one. i have looked through the
> spec and cannot find anything that prevents the PEP from taking other decision
> prospecting actions. what i do see is the spec saying that you cannot allow
> access unless told to do so. i personally cannot think of any other way to
> explain how to succinctly act upon the decisions presented.

I know. And all of these words are meaningless, because you cannot force
me to comply, period.

> > and further, this is only in the case where you have a signular PEP-PDP
> > relationship!
>
> no. it is the case regardless where the PEP looks for decisions or how it
> requalifies the question.

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

> > It may be your Policy at your organization to categorically deny when you
> > get anything other than a Permit.  I respect that. It's your organization,
> > and it's your configuration.
> >
> > But don't tell me that's how I should act.
>
> 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.

Therefore, two policy writers will be common in their understanding in the
policies they write, the word "Deny" is meant to deny access, "Permit" is
meant to grant access, and NotApplicable means the policy does not apply,
and Indeterminate means that their policy could not determine a decision.

> why not have the PEP just kind of cruise around until it gets an answer
> that it is emotionally comfortable with?  that way it is ok for an
> 'organization' to allow access upon Deny and we can all stop being so
> darn judgmental! :oP

That may not be far off the mark.
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.

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.

However, if I have applications that need special attention to
Indeterminate, incomprehensible obligations, I'm not going to buy it,
because it's not going to do what I *NEED* it to do.

I'll find one that does, or custom build it. (I won't even think to read
the silly requirements in the XACML standard).


> > If I want to deploy a XACML eating breathing PDP in my organization, the
> > spec tells me how to write polciies for it, such that Deny means Deny, and
> > Permit means Permit. And that's only so we have some common standard
> > expectation if I gave the job to write policies to somebody else.
>
> NO. who needs an international standard for that? you can pick any vendor in
> oasis that provides the desired service and just hand the next policy writer the
> operation manual. the goal of the XACML standard (unless i have been wasting 3
> years of my life ;o) is to create an environment where more than one entity may
> be able to exchange policy information in such a manner such that the *applied*
> affects are equivalent even when interchanging components.

You just said the same thing I said.

If we exchange policies back and forth, they will have the same meaning
with respect to the same information given in a request context. Nothing
more than that.


> > If my PEP chooses to have 27 PDPs how are you going to tell me to run
> > that?
>
> see above.

I still didn't get how you specified that.

> <thwap> <thwap> <thwap> uh-oh, the black helicopters are here for my meeting
> with my co-conspirators. gotta run...

Have fun.
-Polar

>
> 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.php.
>