Hi Sampo
Here is why I think it does not particularly matter if the returned set
of attributes along with a grant is deterministic or not.
A user wants to get access to a resource. If a user is granted access by
presenting a bunch of credentials (i.e. attributes), then he will
usually be happy. If the user now wants more privacy protection, he
might want to present less attributes and therefore know which of the
ones previously presented were actually the "correct" ones, so that only
these can be presented next time. If two different sets of his
attributes actually granted his access via different rules, again it
does not matter which set he presents next time, either each set
separately or both sets together will work. He will still be granted
access. For maximum privacy protection and maximum safety he should
present the "least privileges" set of attributes. But I think it is
placing too great an onus on a PDP to ask it to return the least
privileges set of attributes. This should be up to the user to
determine. If the PDP can return either the "only" set of attributes
that are needed (assuming only one rule fired), or any one of several
sets (assuming multiple rules fired) then this should be sufficient for
the user.
I understand that you are approaching this issue from a slightly
different perspective than myself, ie. that of a policy administrator,
who is trying to debug an XACML policy. This was not my intention for
this feature, rather it was to help the user reveal or present fewer
attributes in a subsequent access attempt.
Further comments inline below.
wrote:
> David Chadwick wrote:
>> Erik Rissanen wrote:
>>> I have started editing the SAML profile. Anne has done a very good job
>>> with the profile,
>> agreed
>>
>> > but I have noticed the following things which I think
>>> need to be changed. See the SAML profile wd 5.
>>>
>>> Section 4.4, page 23-24 describe a functionality which I think cannot be
>>> implemented well and there is a better alternative.
>>>
>>> The functionality is that if the XML attribute ReturnContext="true",
>>> then the PDP shall return an XACML <Request> in the SAML profile
>>> response, which contains those attributes which the PDP used during
>>> request evaluation. This is what David Chadwick posted about to the
>>> comments list a few weeks ago:
>>>
>>> http://lists.oasis-open.org/archives/xacml-comment/200811/msg00024.html
>>>
>>> His use case is that he wanted to know which role triggered the
>>> policies.
>> In many cases it will be policy (singular) wont it? So why not address
>> the problem initially by assuming that only one policy caused the answer
>> that was returned, and then extending this to the case when several
>> policies gave the same answer as the returned one.
>>
>>
>> > As I explained on the list I think that use case is handled
>>> better by means of dynamic obligations, which I suppose we will discuss
>>> on Thursday.
>> Whilst I am not against dynamic obligations, I dont think they are
>> addressing the same problem as Anne was trying to solve, which I think
>> can be restated as this:
>>
>> "given a possibly very large set of attributes which were presented in a
>> request context, which ones were used by the PDP to formulate the
>> response context. Or stated another way, which of the presented
>> attributes could have been missing from the request context and the same
>> response would still have resulted, in which case remove these
>> attributes from the returned request context."
>>
>> If only one policy gave the response that was returned, then the above
>> should be easy to compute. If several policies gave the same response as
>
> Wrong. The attributes that contributed to eariler policies in not being
> applicable are relevant as well.
I dont think they are. Because the policy is non-applicable then it can
be discarded.
But what do you actually mean by "attributes that contributed to earlier
policies in not being applicable"? Are you thinking here of a policy
such as "if you are a project leader but not a project manager then..."
In which case such a policy is a nonsense in a distributed system, since
there is no component that can force a user to release all his
attributes. Privacy protection (for one) dictates that I release only
the attributes that I want the PDP to see.
>
> I think there are several levels of detail that may interest someone
> debugging a policy decision:
>
> 1. Just the rule that matched and the attributes referenced by that rule
Yes, I am interested in this one
> 2. All other rules that could have matched and the attributes that
> might have been referenced. The point here is that XACML does not
> guarantee deterministic order of evaluation in all cases.
Are you saying here that the PDP simply stopped processing further rules
once it had a decision? In which case I think this is perfectly
acceptable and sensible strategy for a PDP. And from a user perspective
the returned result was sound and the attributes from 1. are sufficient
to help next time around.
> 3. All rules and rule sets that were not considered applicable and
> the attributes that caused them not to be applicable.
this one I dont completely follow as mentioned above
> 4. All rules that could have been considered and attributes
> referenced. Again, this is interesting if the policies and/or
> policy sets are formulated such that they are not deterministic.
How is this different from 2 above?
>
> It may already have been mentioned in discussion, but I consider
> all allowances for non-determinismn in XACML spec to be serious
> flaws. I realize non-determinism may allow more optimal evaluation
> and even be in line with "declarative" expression of policies,
> but it seriously undermines trust in integrity of the XACML system.
I dont follow the logic of this. If two statements are true, and I
always return one at random to you, why would you trust me any less. If
asked who is Sampo?, and I return either "Sampo is a Finn" or "Sampo
lives in Portugal" but not both, would someone trust me less. It all
depends upon the question being asked. If asked "tell me everything you
know about Sampo" then yes they would trust me less. But a PDP is being
asked, can this user with this set of attributes get access to this
resource under these conditions? to which the answer is yes, no, dont
know or error. If however the questions is "tell me everything about the
accesses that can be granted to any resources with this set of
attributes, then this is a completely different question to the one that
the SAML-XACML request context is asking. This is not a use-case that I
was addressing, and I think it opens up a whole new ball game if it is
what you are asking for,
>
> Who wants to hear as justification for policy decision: "It depends..."?
I dont think this is entirely fair. Rather it is "given this initial set
of attributes the answer is...[pick one from several true ones]"
regards
David
- rest of message truncated to save bandwidth from Kenya :-)
