OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xacml-dev message

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


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


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.


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
"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
(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
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
scenarios fail where for instance 2 policies have the same target
because one addresses enterprise-wide requirements such as
hours" whereas the other policy could address direct business
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
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.

* *
David Brossard, M.Eng, SCEA, CSTP
Solutions Architect
+46(0)760 25 85 75
Axiomatics AB
Skeppsbron 40
S-111 30 Stockholm, Sweden
2011/7/17 Doron Grinstein

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