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


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 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
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.
3. All rules and rule sets that were not considered applicable and
   the attributes that caused them not to be applicable.
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.

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.

Who wants to hear as justification for policy decision: "It depends..."?

Cheers,
--Sampo

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




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