On Dec 20, 2008, at 12:49 AM, Erik Rissanen wrote:
> 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.
Sorry, I should have been more explicit. So the answer is yes. :)
>>> 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>.
Right. Sorry, again should have been more explicit. I was referring
back to the first sentence of this thread:
"...yesterday we decided to introduce introduce a new "type of
obligation..."
will stick solely to the term Advice moving forward to be more
precise. :)
> 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.
100% in agreement here.
> 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.
OK, this is where I am looking for clarity. Perhaps I do not
understand your "refactoring" process. If Advice is limited to Permit|
Deny and I have a mixed domain PDP those Policies that are not part of
the decision (aka "not applicable") would not be evaluated. (It makes
no sense to evaluate the Rules of a Policy where the Resource is not
applicable to the question being asked, right?). Therefore, by
definition the PDP would not return an Advice (or Obligation :)
contained within these Policies because they should never lead to a
Permit or Deny decision (the only thing that can be said of them is
that they are not applicable to the decision). This of course assumes
that individual Polices do not cross domain boundaries but I think
that is a safe assumption for a number of reasons.
Conversely, if you extend Advices to Not Applicable then you compel
the system to return ALL Advices(=NotApplicable) to the PEP that are
in all other domains since, by definition, any such Policy/Rule meets
the condition of being not applicable. I do not see any way to avoid
or control this and in the situation of a distributed system to be
able reasonably bound the problem.
For example, take the case of a Grid, would all peers need to be
queried to derive the exhaustive list of those things that are not
applicable to a decision? I know that this is an extreme case, but my
point is that the concept of "do something about those things that
don't apply to the situation" seems like it can lead to many
unintended consequences.
thanks
b
