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


Subject: Re: [xacml] IIC012: syntax-error or processing-error?



Hi Seth,

You make some good points. and you are right to say that your PDP will
return "Not-Applicable" for this policy. In fact, you'd be right if you
wanted to return Deny, Permit, or Indeterminate, as well. The fact is that
the answer for badly formed policies is "undefined".

In my previous example, some one can configure the PDP initially to be
"Deny", "Permit", "Not-applicable", or even possibly "Indetermiante with
not-configured". So if you take operation of the conformance tests to be:

1. Load Policy to PDP
2. Load Request to Context Handler
3. Make request.

For a bad policy, some PDPs might accept the policy and return
Indeterminate with syntax-error.  Yours would return Not-Applicable. Mine
would be whatever it was set to before, because the badly formed policy
would never get into the PDP.

So, in essence, we don't and shouldn't define what happens in this case.

Now, for your "another side", of which you ellude to here:

> There is, of course, another side to this. If a request comes into the PDP
> that causes a policy to be fetched and parsed for the first time, and if that
> policy is the only applicable policy, then an error in the policy could be
> reported back to the PEP. Why? Because you might want to make it clear that
> there was a policy for the request, but it was invalid. This might be useful
> for diagnostic reasons, but I can't think of any other use for this
> distinction. The spec doesn't really nail this point down, so it's hard to
> know for sure what the tests should assume. It's also hard to define whether
> or not this is the case that the tests are exercising.

This case is actually covered in the policy combining algorithms:

"If an error occurs while evaluating the target of a policy, or a
reference to a policy is considered invalid or the policy evaluation
results in "Indeterminate", then the policy set SHALL evaluate to
"Indeterminate"."

which is in all of the combinging algorithm specifications. In this case,
retrieving an "invalid"  policy will result in an indeterminate. However,
the status code is not specified, but that could be a meriad of factors,
such as the policy reference is down, the policy behind the reference is
invalid, etc.

However, it is still up to the PDP adminstrative interface to decide
whether all referenced policies are correct at load time and decide not to
accept. If you take the more dynamcic case, that may defer the answer, but
it is covered.

-Polar



 On Wed, 4 Dec 2002, Seth Proctor wrote:

>
> Let me suggest this: the result should be NotApplicable. This is an invalid
> policy, so the PDP should be unable to parse it. Sine the PDP should reject
> the policy, there will be no available policy to service the request. Hence,
> the NotApplicable result.
>
> This gets back to a similar thread we started a couple of weeks ago about when
> to return messages about bad policies (ie, is the policy paresed on PDP
> startup, on request processing, etc.). I think in general it's hard to
> define what to do in some of these cases, because different implementators
> will handle this differently. I want my PDP to reject the invalid policy,
> therefore it will never be available to a request, and will result in
> NotApplicable. But that's my choice. It's unclear to me whether the spec
> allows a PDP to parse and use an invalid policy, which is essentially what's
> required to get Indeterminate in this case.
>
> There is, of course, another side to this. If a request comes into the PDP
> that causes a policy to be fetched and parsed for the first time, and if that
> policy is the only applicable policy, then an error in the policy could be
> reported back to the PEP. Why? Because you might want to make it clear that
> there was a policy for the request, but it was invalid. This might be useful
> for diagnostic reasons, but I can't think of any other use for this
> distinction. The spec doesn't really nail this point down, so it's hard to
> know for sure what the tests should assume. It's also hard to define whether
> or not this is the case that the tests are exercising.
>
> Thoughts?
>
>
> seth
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>



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


Powered by eList eXpress LLC