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


Subject: Re: [xacml] The SAML profile


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.


sampo@symlabs.com 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 :-)



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