Re: [xacml] The SAML profile

[Erik Rissanen <erik@axiomatics.com>]

Hi David,

I was perhaps not so clear. What I had in mind was a case where a policy 
contains a negative condition, so it evaluates to NotApplicable because 
an attribute *is* present in the request. If the attribute would have 
been absent, then the policy would have been applicable, possibly 
leading to a different decision.

In other words, the policy was not applicable, and thus it contributed 
the decision and it was one of the attributes present which made it 
NotApplicable, thus this attribute contributed to the decision.

Regards,
Erik

David Chadwick wrote:
> Hi Erik
>
> thanks for the reply.  I only take issue with one of your answers, as
> indicated below.
>
> Erik Rissanen wrote:
>> Hi David,
>>
>> See responses inline.
>>
>> David Chadwick wrote:
>>> 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 was returned, then it is an implementation option 
>>> whether to return only the set of attributes from any one of these 
>>> policies, or the set from all of these policies. If several policies 
>>> were used to create the response, then the attributes used by all 
>>> these policies should be returned.
>>
>> This is use case has been discussed extensively on the list in the 
>> several recent months, and it has been decided that it will not be 
>> addressed in the 3.0 core. We will do a separate profile later to 
>> handle attribute coordination between the PEP and PDP. (Or at least I 
>> think we should.)
>>
>>
>>>> The problems with this functionality are:
>>>>
>>>> - If the meaning of "was used" is that the attribute was referenced 
>>>> by the PDP, 
>>>
>>>
>>> I think this is simply a case of missing implied text in Anne's 
>>> description. If you replace "that were used in making the
>>> authorization decision." by "was used in making the authorization
>>> decision that was returned" then it becomes much clearer what the 
>>> intention was. Any attributes that were used by the PDP in making 
>>> authorisation decisions that were not returned do not contribute to 
>>> the returned request context. If you read Anne's subsequent sentence 
>>> I think you will see that this was the original intention.
>>
>> This doesn't change much since the fact that a policy was not 
>> applicable in itself does contribute to the decision which was made,
>
> I think this is Alice through the looking glass logic. If a policy is
> not applicable then it should be ignored. Full stop. E.g. Say a policy
> is Deny access to all people with green noses and black hair, but the
> subject only provided his hair colour and did not provide his nose
> colour. You should not be saying "well it would be applicable if you did
> have a green nose, so I am still going to consider that this policy was
> used and I will return hair colour in the used attributes". To me, this
> is a nonsense. The policy was not applicable and the hair colour was
> ignored in making the decision.
>
>
>  since if it
>> had been applicable, the decision could be something else than was 
>> actually returned.
>
> Again this is Alice in Wonderland logic. The PDP can only work with the
> attributes it is given, and it cannot assume that all subjects possess
> all attributes but that they just choose to present some of them. The 
> PDP cannot second guess what attributes a subject has, and should 
> simply use what it is given and say that these are all that are 
> relevant for the current decision making.
>
> > I don't see any other interpretation of this than to
>> return all attributes which were referenced by the policies.
>
> I disagree with this position.
>
>>
>> Hal claimed on the previous call that he has a clear interpretation 
>> and he has promised to post text which clarifies this section.
>
> I look forward to receiving this, since it will be a useful clarification
>
> regards
>
> David
>
>
>>> then you will end up with lots of superfluous attributes in the
>>>> response since there might be many non-applicable policies, which 
>>>> are found to be non-applicable only after attributes have been 
>>>> referenced. This make the feature non-useful.
>>>
>>> Then this cannot have been the intention, can it? And I dont think 
>>> that this is a correct interpretation of Anne's text.
>>
>> Maybe so, but my problem with the text is that I cannot interpret it 
>> in a meaningful way. :-)
>>
>>>>
>>>> - Obligations are more efficient since it is possible to target 
>>>> only the interesting attributes and we avoid the overhead of 
>>>> collecting any attribute which was used by the PDP.
>>>
>>> Obligations are not addressing the same issue are they?
>>
>> No, there are two separate use cases which have been mentioned in 
>> this context.
>>
>> 1. How does a PEP coordinate with a PDP so it sends the right 
>> attributes to the PDP.
>>
>> 2. Which role was "significant".
>>
>> The second one is handled by dynamic obligations easily since a human 
>> can make an interpretation of what is "significant" in a particular 
>> policy.
>>
>> The first one is a very relevant use case and I have many ideas about 
>> how to solve it, but the TC has decided to defer this to after the 
>> 3.0 core has been finished.
>>
>>>> - In XACML 2.0 it is possible to refer to any attribute with an 
>>>> XPath, which makes this very difficult to implement.
>>>
>>> This might be the case for your PDP implementation, but is it the case
>>> for all XACML PDP implementations?
>>
>> I was thinking in terms of the general XACML policy model, regardless 
>> of implementation details.
>>
>>> Certainly if one regards the SAML profile as a standard way of talking
>>> to any PDP that supports the XACML request/response context, but which
>>> might not support the XACML policy syntax, then this argument about 
>>> being difficult to implement does not hold. In our EC TAS3 project 
>>> we will be supporting at least 2 PDPs that support this SAML profile 
>>> but not XACML policy syntax. I believe that many such PDP 
>>> implementations exist.
>>
>> Yes, but the standard is intended to support an XACML PDP, and we 
>> should not put in features in it which cannot work with an XACML PDP.
>>
>>>>
>>>> - It is difficult (impossible?) to implement this at the 
>>>> granularity of individual attribute values in multi valued 
>>>> attributes (such as "role") since a set functions could be used on 
>>>> the multi value attribute, in which case it is difficult to track 
>>>> which of the individual values was the "significant" one.
>>>
>>>
>>> The code that performs the function evaluation will surely know which
>>> value (or values) from the set gave the match, and therefore it will be
>>> able to return the subset of matched values.
>>
>> Perhaps, I haven't thought about it in detail, but it does get very 
>> complex to track for instance when set functions are used. For 
>> instance, the original set could be made a union with another set, 
>> which contains the same value. Is that attribute any longer 
>> "significant"? How does one handle that kind of correlation between 
>> different attributes? What about if the value with which it is 
>> matched against is dynamically generated? Are there issue tracking 
>> "significance" in that case? There are so many open questions.
>>
>>>>
>>>> *** Proposal: I propose that the ReturnContext-feature in the SAML 
>>>> profile draft is removed.
>>>
>>> I would like to propose that it isnt, and instead we clarify exactly
>>> what the intentions of this parameter are.
>>
>> Hal has said that he will propose text to clarify it.
>>
>> It also appears that this feature is something that people really, 
>> really want there, so may be should keep it even if it is 
>> fundamentally broken? Users can deal with and work around the cases 
>> where it won't work and implementations can do it "badly".
>>
>>>> Section 6 talks about saml Advice. I am not very familiar with the 
>>>> use of Advice, but this section lists no reason for why one would 
>>>> want to do what it described. So, either explain what good it is 
>>>> for, or drop section 6 altogether.
>>>
>>> I dont want to second guess Anne, but here is a scenario that might 
>>> fit.
>>> Suppose a user U wants to access a confidential attribute held by
>>> repository R, and the confidential attribute is returned by R in a SAML
>>> attribute assertion. In order for R to make the decision it contacted
>>> its remote PDP using this SAML profile, and got a grant decision along
>>> with the policy that was used to give the grant. This SAML assertion
>>> (which conforms to the current profile under discussion) is included as
>>> Advice in the SAML attribute assertion to U in order to inform the user
>>> under which policy he was granted access to the confidential attribute.
>>
>> So in this case it would depend on the other feature which we 
>> discussed above. Anyway, maybe we can keep this section since it does 
>> not have any MUSTs in it, it's just something that implementation may 
>> do if they wish. But it would be nice to know what good it is for. :-)
>>
>> Best regards,
>> Erik
>>
>>
>