Re: [xacml] The SAML profile

[Erik Rissanen <erik@axiomatics.com>]

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, since if it 
had been applicable, the decision could be something else than was 
actually returned. I don't see any other interpretation of this than to 
return all attributes which were referenced by the policies.

Hal claimed on the previous call that he has a clear interpretation and 
he has promised to post text which clarifies this section.

> 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