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

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

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


Subject: [xacml] Re: Boolean Policy resolution



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



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


Powered by eList eXpress LLC