[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml-dev] XACML Target matching question
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 On 7/18/2011 5:55 PM, Helmut Petritsch wrote: 4E24ABD0.9080704@petritsch.co.at" type="cite">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, RichReading 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 policysets. The PDPSHALL return a response context as if it had evaluated a singlepolicy setconsisting of this policy-combining algorithm and the set ofpolicies and/orpolicy sets. The PDP MUST evaluate the policy set as specified in Sections 5 and7. ThePDP MUST return a response context, with one <Decision> element ofvalue"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 toppolicies(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 anymention of adefault 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.15but thechoice of combining algorithm is down to the implementation. Helmut is quite right in highlighting the following: *"If the twopoliciesare top level policies and there is no combining algorithm, youshould getan 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 incomingrequest, thePDP is forced to return Indeterminate. However, this would makeenterprisescenarios fail where for instance 2 policies have the same targetsimplybecause one addresses enterprise-wide requirements such as"out-of-officehours" whereas the other policy could address direct businessrequirementse.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 onehand andbusiness-specific policies on the other) is one of the strengths of100%XACML solutions and fine-grained access control. The ability tochoose thecombining 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 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]