xacml — archive

[Anne Anderson <bill@parducci.net>]

bill parducci <bill@parducci.net> wrote: >Date: Wed, 30 Jan 2002 22:19:04 -0800 >> A Combinator expression in which some, but not all of the >> Predicates to which it applies evaluates to NOT-APPLICABLE is >> evaluated as if the NOT-APPLICABLE Predicates were removed >> from the Combinator expression. > > >kinda pulls the teeth from an AND clause, doesn't it? I disagree. A predicate evaluates to NOT-APPLICABLE if the policy was not intended to apply to the authorization query that is presented. So removing the predicate from the calculation fits the natural semantics. Example: Sun Labs wants to make sure its own policies as well as any applicable Corporate policies are followed, so it creates the following base policy: <policy> <and> <referencedPolicy> http://www.sun.com/labs/policy </referencedPolicy> <referencedPolicy> http://www.sun.com/corp/policy </referencedPolicy> </and> </policy> If there are no applicable corporate policies for a given authorization request, then this policy reduces to checking the labs policy only. If there are no applicable labs policies either, then the <policy> returns a result of NOT-APPLICABLE, which simply means there were no applicable policies anywhere. >> The set of Combinators may be extended by [specifying a name >> for the new Combinator, a URI that is associated with the >> semantics of the new Combinator, and a type that specifies >> the way the URI is to be interpreted. Not all XACML PDPs >> will be able to interpret all extensions, but any PDP that >> can handle the specified type and can access the specified >> URI can handle the specified extended Combinator.] > > >what is the behavior of the PDP if it cannot resolve the extension? ERROR, I would think. >> Base Policy: the <xacml:applicablePolicy> element that specifies >> the <xacml:policy> element that a PDP will use [by default] >> to evaluate all Access Requests. >> >> [Alternative 1: >> A PDP MAY have multiple Base Policies, but such Base Policies >> SHOULD have non-overlapping <xacml:target> elements. This >> specification does not specify the order in which multiple >> Base Policies are evaluated, or the result if two or more >> Base Policies have overlapping <xacml:target> elements. >> >> Alternative 2: >> Base Policies have restricted <target> elements that are >> easily compared for overlap. In this alternative, the case >> where base policies overlap is an ERROR. Note that the 0.8 >> syntax favors this alternative and allows Alternative 3. >> >> Alternative 3: >> There is only one Base Policy and it has no <target> because >> applies to all Resource or it has a <target> element that >> completely specifies the set of resources which this PDP is >> prepared to handle.] > > >it seems that in reality you are going to need to have #3 to provide >resolution to conflicts arising from #1 whether it is called a base >policy or PDP default policy, etc. It seems that way to me also (with addition that #3 may have a target to indicate that this PDP simply does not have policies to cover all possible authorization queries that may be submitted to it). But I got the impression at the F2F that some people want to handle conflicts between policies on some basis other than a boolean combination, or don't want to have to create a base policy each time a new applicable policy is added to the set to be evaluated. I would like more clarification from the people who advocate having more than one base policy on why that is necessary. >> [A Base Policy for evaluating a particular Access Request may >> be specified as part of the Access Request. If a PDP has no >> default Base Policy, then the result of evaluating an Access >> Request that does not specify a Base Policy to use is FALSE >> (deny access).] > > >i personally, believe that we cannot support interoperability without a >default policy. anything that affects the outcome of a decision must be >determinable and a default policy definitely falls into that category. We could return NOT-APPLICABLE.