Re: [xacml-dev] XACML Target matching question

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

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