Re: [xacml-dev] Base and Permit-biased PEPs

[Seth Proctor <Seth.Proctor@Sun.COM>]

Hi Mary.

On Mon, 2004-10-25 at 13:48, Mary Kolencik (siamese@bcpl.net) wrote:
> I have a question about section 7.1.1 and 7.1.3, the Base PEP and
> the Permit-biased PEP in 2.0. Those sections say that "If the decision is 
> "Deny", then the PEP SHALL deny access.  If obligations accompany the 
> decision, then the PEP shall deny access only if it understands, and it 
> can and will discharge those obligations."
>
> Suppose the decision is "deny" with obligations and the PEP cannot 
> understand or discharge the obligation, does this result in a "permit"? 
> The above sentance says the PEP will only deny if it understands and 
> can do the obligation, so what happens when it can't understand or 
> discharge the obligation?

Here's my advice to you: forget that you read this section of the 2.0
specification, and replace it in your memory with the following
explanation.

A PEP is tied to a PDP (or to multiple PDPs), and is done so such that
the PEP should deterministically use the PDP's Decision to determine
access. In almost all cases, this means that if the Decision is Permit,
then the PEP should permit the action, and if the Decision is Deny then
the PEP should deny the action. If the Decision is NotApplicable then
the PEP may consult some other source, but in most cases will deny the
action. If the Decision is Indeterminate then the PEP may be able to
recover and try again (depending on the error case), but in most cases
will deny the action.

Obligations complicate things a little. Obligations are not supposed to
be a condition on the Decision, but they look like they act that way.
For example, if the PDP returns Permit, and returns Obligations that the
PEP cannot discharge, then the PEP is expected to Deny the action. This
looks a lot like a condition on the Decision, but it's not really [1].

So, what does this mean in the common case? If your PDP returns a
Decision of Permit or Deny and some Obligations, if the PEP cannot
discharge the Obligations, then your PEP cannot meet the contract it has
with the PDP, and should not accept the decision of the PDP. Where does
that leave you? In most systems, this is a case where the PEP cannot
make an informed decision about access, and therefore will deny the
action by default (although probably with different data logged). This
was a long-winded way of saying "whenever you can't handle an
Obligation, you should probably deny the action." :)

Basically, you just need to think about what makes sense in your system.
The text added in 7.1 is an effort to make sure that people don't build
systems where the PEP non-deterministically ignores the PDP's decision.
Personally, I think it confuses more than it helps, and in my experience
common sense prevails in most people's deployments. Sorry this was such
a long answer...did I at least answer your question?


seth


[1] You can get into endless semantic and pedantic arguments on this
issue, and believe me, we have :) I don't want to go down that path
right now, but mail me privately if you're interested in my views. To
get you started, think about the previous paragraph where I talked about
different Decisions that all (usually) result in Deny. Now think about
why you care how the PEP decided to deny an action. Having fun yet?