[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [xacml] [model] Issues PM-2-02,PM-2-04: Applicability
[This note has to do with the syntax for expressing "applicability" of a single policy, and not with the logical rules for combining an inapplicable policy with other policies!!] We currently allow a <target> element predicate in <applicablePolicy> element. The purpose of this element is to allow a PDP (or its agent, a PRP) to eliminate policies efficiently if they do not apply to the current authorizationDecisionQuery. Such an element can be used to index policies by Subject or Resource/Action (where some policies will need to be indexed under both Subject and Resource/Action, and some policies will apply to all Subjects and/or Resource/Actions). The idea is that the <target> element predicate is simple to compute, and allows the PDP (or PRP) to narrow down the field of potentially applicable policies efficiently. The PDP (or PRP) can then perform more complex evaluations on the smaller remaining set of policies. Since the <target> element needs to be a simple predicate that is efficient to compute, it is not sufficiently expressive to rule out all cases where the <policy> may not apply. For example, if the policy applies only to employees who are over 55 years of age, then there is no syntax currently for expressing this in the <target> element. POTENTIAL RESOLUTION: We need two levels of applicability predicate: one used for fast narrowing down of the set of potentially applicable policies (and used for indexing), and the second for fully expressing the conditions under which this policy is applicable. The first level applicability predicate is our current syntax: a regular expression match on a Resource/Action and Subject. It is very simple to compute, and MUST return TRUE for every authorizationDecisionQuery to which the corresponding policy applies. It MAY return TRUE for an authorizationDecisionQuery to which it does not apply. This predicate might be called "indexApplicability" or "basicApplicability" or something similar. The second level applicability predicate is an optional new element in the <applicablePolicy>. It may use any comparison of attributes and values that could be used in the policy itself. This predicate might be called "fullApplicability" or something similar. This second level predicate is optional because for many policies, only the first level predicate may be required to fully capture the exact set of conditions under which the policy applies. A policy evaluation returns "NOT-APPLICABLE" if either the first level applicability predicate OR the second level applicability predicate evaluates to FALSE. The second level predicate need be computed ONLY IF the first level predicate evaluates to TRUE. The <policy> element may assume that the first and second level applicability predicates have been evaluated to TRUE. This may save some duplicate predicates. -- Anne H. Anderson Email: Anne.Anderson@Sun.COM Sun Microsystems Laboratories 1 Network Drive,UBUR02-311 Tel: 781/442-0928 Burlington, MA 01803-0902 USA Fax: 781/442-1692
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC