Re: [xacml-dev] XACML Target matching question

[Helmut Petritsch <helmut@petritsch.co.at>]

Hi Rich,

sorry, I justed wanted to hint you to the reference. (I have to admit
that I nearly missed it myself...)

But I agree with you that the specification should be more specific
regarding this question, as it is hard to find (as we both experienced);
if (as it seems) this "root" policy combining algorithm is an essential
property of the PDP, it should be mentioned at some stage (e.g. at the
description of the PDP, where already the "applicable policy" is
mentioned (line 62)).

Regards,
  Helmut

On 07/19/2011 12:02 AM, rich levinson wrote:
> Hi Helmut,
> 
> I agree, I missed a couple of the emails in the middle of the thread, where
> David ref'd sec 7.15.
> 
> However, as you have just indicated, and as I mentioned to David
> out of band, I think this should probably be raised as an issue, since
> it does not appear to be adequately specified, even if it is assumed
> to be implementation dependent:
> 
>     However, I think based on the explanations that have been
>     given, it is pretty clear that sec 7.15 alone is insufficient to
>     infer that a PDP will "roll up" a set of independently rooted
>     Policy and PolicySet elements under a common PolicySet
>     with some specific Policy combining algorithm. Also, I do
>     not think that the additional refs in the spec fill the gap.
> 
>     i.e. imo, this is a good example of a xacml-dev question that
>     should be raised to an issue.
> 
>     I remember that this was discussed in the past, maybe I even
>     raised a question about it, and probably went away satisfied
>     that at least someone could give me an answer even though
>     the spec, itself, did not completely do the job.
> 
>         Thanks,
>         Rich
> 
> 
> On 7/18/2011 5:55 PM, Helmut Petritsch wrote:
>> The referenced statement was specified by David: section 7.15,
>> "Authorization Decsion."
>>
>> After reading this section 7.15 (I did not find it when skimming over
>> the spec - thanks@David), I think there is no implicit top level
>> PolicySet, but rather a top level Policy Combining Algorithm, which is a
>>  property of the PDP (which should/could be configurable). Anyhow, how
>> it is determined ("hard-coded" or configurable) is implementation
>> dependent.
>>
>> Regards,
>>   Helmut
>>
>> On 07/18/2011 09:44 PM, rich levinson wrote:
>>> It would be useful to cite the specific place in the spec where the
>>> ref'd statement appears.
>>> It is not findable looking for "default", "top", "root", etc. It would
>>> also be useful if this
>>> "implicit" top level PolicySet had an official term by which it is
>>> referred to.
>>>
>>>     Thanks,
>>>     Rich
>>>
>>>
>>>>>> Reading further down in the XACML spec, in the Functional Requirements
>>>>>> chapter which dictates how evaluation should proceed, *section 7.15
>>>>>> "Authorization Decision"* explains exactly how a decision should be
>>>>>> reached whether there are multiple policies that can be matched or not:
>>>>>>
>>>>>> *In relation to a particular decision request, the PDP is defined by a
>>>>>> policy-combining algorithm and a set of policies and/or policy
>>>> sets. The PDP
>>>>>> SHALL return a response context as if it had evaluated a single
>>>> policy set
>>>>>> consisting of this policy-combining algorithm and the set of
>>>> policies and/or
>>>>>> policy sets.
>>>>>> The PDP MUST evaluate the policy set as specified in Sections 5 and
>>>> 7. The
>>>>>> PDP MUST return a response context, with one <Decision> element of
>>>> value
>>>>>> "Permit", "Deny", "Indeterminate" or "NotApplicable".
>>>>>> If the PDP cannot make a decision, then an "Indeterminate" <Decision>
>>>>>> element SHALL be returned.
>>>>>>
>>>>>> *
>>>>>> The paragraph above highlights one very important point: *the PDP must
>>>>>> always have a policy-combining algorithm at the very top. Any XACML 3.0
>>>>>> implementation should respect that. It then considers all the top
>>>> policies
>>>>>> (policy sets) as if they were within a policy set with the combining
>>>>>> algorithm defined at the very top.
>>>>>>
>>>>>> *Finally, after reading through the spec, I could not see any
>>>> mention of a
>>>>>> default combining algorithm as Doron suggested it.*
>>>>>>
>>>>>> *It is a requirement that the PDP consider all root policies as if they
>>>>>> were children of a single policy set as described in section 7.15
>>>> but the
>>>>>> choice of combining algorithm is down to the implementation.
>>>>>>
>>>>>> Helmut is quite right in highlighting the following: *"If the two
>>>> policies
>>>>>> are top level policies and there is no combining algorithm, you
>>>> should get
>>>>>> an error from your PDP"*. Section 7.15 stipulates that there must be a
>>>>>> combining algorithm.
>>>>>>
>>>>>> Note that choosing a PDP that forces you to use only-one-applicable has
>>>>>> considerable limitations. Section C.9 describes its behavior: if two
>>>>>> policies combined with only-one-applicable match an incoming
>>>> request, the
>>>>>> PDP is forced to return Indeterminate. However, this would make
>>>> enterprise
>>>>>> scenarios fail where for instance 2 policies have the same target
>>>> simply
>>>>>> because one addresses enterprise-wide requirements such as
>>>> "out-of-office
>>>>>> hours" whereas the other policy could address direct business
>>>> requirements
>>>>>> e.g. "access to sensitive information".
>>>>>>
>>>>>> Being able to segregate policies on different planes (enterprise-wide
>>>>>> policies about hours of work, geo-location, SoD, PCI-DSS on one
>>>> hand and
>>>>>> business-specific policies on the other) is one of the strengths of
>>>> 100%
>>>>>> XACML solutions and fine-grained access control. The ability to
>>>> choose the
>>>>>> combining algorithm gives you that flexibility and strength.
>>>>>>
>>>>>> I hope this helps clarify the situation.
>>>>>>
>>>>>> Cheers,
>>>>>> David.
>>>>>> * *
>>>>>> --
>>>>>> David Brossard, M.Eng, SCEA, CSTP
>>>>>> Solutions Architect
>>>>>> +46(0)760 25 85 75
>>>>>> Axiomatics AB
>>>>>> Skeppsbron 40
>>>>>> S-111 30 Stockholm, Sweden
>>>>>> http://www.linkedin.com/companies/536082
>>>>>> http://www.axiomatics.com
>>>>>> http://twitter.com/axiomatics
>>>>>> 2011/7/17 Doron Grinstein