Re: [xacml] The SAML profile

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

Hi Erik

Erik Rissanen wrote:
> All,
> 
> 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 
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.


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


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.

> 
> - If the meaning is something else, then I cannot think of how to define 
> it.

try working with my definition above and refine it as appropriate until 
it makes sense to you.

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


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

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.

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

We had a similar problem with LDAP many years ago which led to the
publication of RFC 3876 about matched values. I think this feature that 
Anne is adding to the SAML profile is similar in some ways to the LDAP 
problem of matched values.


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


> 
> 
> We have previously talked about how policies supplied in a SAML XACML 
> Authz  request are in relation to the other policies in the PDP. We said 
> some weeks ago that the supplied policies will be inserted in the top 
> level policy set *before* the existing policies in the PDP. I now 
> noticed that the SAML profile draft already contains text on this issue. 
> It's different from our previous decision in two respects: first, the 
> supplied policies are inserted *after* the existing policies and there 
> is an XML attribute "CombinePolicies". If this is false, then the 
> existing policies in the PDP shall not be used at all. See section 4.4, 
> page 24.
> 
> I think it makes more sense to put policies before since then for some 
> combining algorithms they will be more significant which might be 
> desirable if you are providing policies in the first place.


I think it is a very useful feature to dynamically present policies. But 
it is difficult to know which flavour users will prefer and how 
applications might use this feature. I have a use case where "before" is 
definitely the correct approach, but maybe Anne had another use case in 
which "after" was the correct approach.

Therefore I would like to propose the following principles:

i) it should be possible for the application to supply extra policies
dynamically to the PDP
ii) it should be possible for the application to say whether these extra
policies should totally replace the existing policies or be used along
with the existing policies
iii) it should be possible for the application to say in which order the
existing and new policies are evaluated.

If these principles are accepted then we can work out the best way of
encoding them in the SAML message.

> 
> *** Proposal: change insertion of policies to *before*.
> 
> *** Action needed: do we want to support the "CombinePolicies" option?
> 
> I think that this seems a nice enough feature, so it's ok for me. It 
> would be useful if one wants to make use of the context handler in a 
> PDP, but want to control the policies himself.
> 
> *** Proposal: fix wording on wording on page 24, around line 768. It 
> says "If the CombinePolicies XML attribute is true,. then the PDP MAY 
> choose to use such XACML Policy instances.". I think it should say "..., 
> then the PDP MUST combine the supplied policies with the existing 
> policies in the PDP". The same wording appears also at the top of the 
> next palge, which should also be changed.
> 
> 
> In section 4.7 there are some TBDs about matching the holder of 
> attributes. This can be easily fixed now that the core schema is done.
> 
> *** Proposal: fix the attribute holder matching. It should say that "The 
> <Match> element shall be evaluated according to the XACM schema against 
> the <Attributes> elements in the <Request>. If it evaluates to "Match" 
> to an <Attributes> element, then the attributes shall apply to that 
> <Attribute> element".
> 
> 
> 
> *** Proposal: change wording at end of section 4.11. It says now "An 
> implementation MUST be prepared to handle any circular dependencies that 
> may arise". This could be interpreted such that the PDP must be able to 
> resolve circularly inherited attributes among the supplied attributes in 
> a SAML XACML Authz request. This is not the intent. It was meant to mean 
> that the PDP must not crash or otherwise behave badly if there is a 
> circular dependency. I propose that we say "An implementation is not 
> required to resolve any inherited dependencies between supplied 
> attributes, but MUST NOT treat any circular dependencies which may arise 
> as an error or otherwise fail on them."
> 
> 
> 
> In section 5.2, page 33, it says that the <ReferencedPolicies> MUST 
> contain copies of all policies referenced from the supplied policies. I 
> think this is a too strict requirement and it may in many cases be 
> useful to have SAML XACML policy assertions with "external" policy 
> references, and it should be allowed.


I agree with this. In our EC TAS3 project we will be having at least 2
external policies along with XACML ones, and we would like this SAML
profile to cover our use cases.



> 
> *** Proposal: Change the above mentioned MUST to a MAY in the section 5.2.
> 
> 
> 
> In section 5.6, at the end of page 35, it says that "The <saml:Issuer> 
> element identifies the entity that generated the XACMLPolicy Response 
> message". I think it should not always have to like this. I can imagine 
> situation where a policy repository contains signed policies in SAML 
> assertions and those are returned by a policy query. In this case I 
> might want to receive the original issuer of the policy, rather than the 
> policy query service as the issuer.
> 
> *** Proposal: Change the text to "The <saml:Issuer> element identifies 
> the originator of the contained XACML Policy, which MAY be the generator 
> of the XACMLPolicy Response message".
> 
> 

OK

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


> 
> *** Proposal: remove section 6 unless someone can explain what it is 
> good for.

see above

regards

David

p.s. currently on holiday with very poor Internet access, so apologies
if this message is late in arriving, and if I dont respond to any 
replies for several days

> 
> 
> Section 8 contains specifications for metadata. This section is to a 
> large degree unfinished work.
> 
> *** Proposal: remove section 8. Open an issue on the issues wiki which 
> says that WD 5 of the SAML profile contains metadata specificatoins, and 
> that those should be considered for the future metadata profile for 
> which there is a working draft already.
> 
> 
> Section 9 contains (line 1248) a really long URN, which I think is a typo.
> 
> **** Proposal remove the prefixing duplicate URN string.
> 
> 
> Best regards,
> Erik
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> 

-- 

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

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