bill parducci wrote:
>
> On Dec 19, 2008, at 7:15 AM, Erik Rissanen wrote:
>> What I mean is that if a PolicySet/Policy/Rule contains an <Advice
>> AppliesTo="NotApplicable">, then it would be returned to the PEP if
>> that policy was processed by the PDP and the final decision is
>> NotApplicable (and to be more precise, that particular NotApplicable
>> was "pushed up" all the way through combination).
>
> Please bear with me on this since I am still a bit fuzzy... So, you
> are proposing that any Policy/Rule in the scope of the security
> infrastructure that doesn't lead to a Permit/Deny for a given request
> returns an Obligation should the ultimate result be Not Applicable?
I don't understand what you mean. Sorry. :-)
I only mean that those Policise/Rules which actually contain <Advice>
return them. Not any of them.
>> They want to put markers in parts of the policies, which they want to
>> show to the users if the final decision is NotApplicable. The markers
>> would give advice to the user about what was wrong with the access
>> request and the reason to why no policy applied to the request.
>
> So, if I read of your proposal is correct, any Obligation marked
> AppliesTo="NotApplicable" in and Policy/Rule in the security realm--no
> matter who wrote it or the scope of the decision--would be sent back.
> For example a PDP that serves decisions for the front door access
> control and the accounting system would reply with any NotApplicable
> Obligations across domains should the ultimate decision be NotApplicable?
>
> Is this correct?
No. It would only apply to <Advice>, not <Obligation>.
And yes, if you mix policies across domains, you would get <Advice>
across domains. So in that case it wouldn't make sense to use them.
But this is really not any different from the case where you use
AppliesTo="Deny" with refactored policies, since in that case you end up
with Denys across domains, so you get interference in policy combining
as well, which is even worse.
Regards,
Erik
