Re: [xacml] The SAML profile

[David Chadwick <d.w.chadwick@kent.ac.uk>]

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
> 
> 

-- 

*****************************************************************
David W. Chadwick, BSc PhD
Professor of Information Systems Security
The Computing Laboratory, University of Kent, Canterbury, CT2 7NF
Skype Name: davidwchadwick
Tel: +44 1227 82 3221
Fax +44 1227 762 811
Mobile: +44 77 96 44 7184
Email: D.W.Chadwick@kent.ac.uk
Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html
Research Web site: http://www.cs.kent.ac.uk/research/groups/iss/index.html
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

*****************************************************************