Re: [xacml] Draft proposal for new work item: properties for new combiningalgorithm

[Anne Anderson <Anne.Anderson@Sun.com>]

Alternative proposal:

  Define ordered versions of permit-overrides and deny-overrides
  for XACML 1.1.

The only requirement we have so far is for priorities.  I believe
priorities are best handled by adding evaluation order
requirements to combining algorithms (i.e. sub-policies or
sub-rules must be evaluated in the order specified).

Here are my additional concerns about the "properties for new
combining algorithm" proposal:

 1) As other have mentioned, "kitchen sink" elements are easily
    mis-used.  Once introduced, they tend to develop a life of
    their own that impedes or prevents other rational extensions
    to the language.

 2) If we allow parameters that affect combining algorithms to be
    embedded inside the combined elements, we are effectively
    allowing the writer of the sub-policy or sub-rule to control
    evaluation of the enclosing policy.  Until I see a good use
    case otherwise, I believe the writer of an enclosing policy
    must retain control of how the policy will be evaluated.

 3) How does the author of a sub-element know which combining
    algorithm will be applied to the sub-element?  Parameters
    appropriate to combining algorithm A may be specified in Policy
    1, but Policy 1 may be referenced from a PolicySet that uses
    combining algorithm B.  In fact, the parameters supplied may
    have unintended effects when used with combining algorithm
    B.

    The parameters could be tagged in some way according to the
    combining algorithm to which they apply, but I think this
    becomes unwieldy.  Can you supply multiple sets of parameters
    in a single Policy, each of which applies to a different
    potential combining algorithm?  Do we force properties to
    have unique identifiers that associate them with a particular
    combining algorithm?

Anne

On 22 April, Michiharu Kudoh writes: [xacml] Draft proposal for new work item: properties for new combining  algorithm
 > From: "Michiharu Kudoh" <KUDO@jp.ibm.com>
 > To: XACML TC <xacml@lists.oasis-open.org>
 > Subject: [xacml] Draft proposal for new work item: properties for new combining
 >  algorithm
 > Date: Tue, 22 Apr 2003 19:09:55 +0900
 > 
 > This is a draft proposal for a new work item regarding "properties for new
 > combining algorithms".  XACML's extensibility allows local vendors to write
 > new combining algorithms.
 > It is often the case that such algorithm uses algorithm-specific parameters
 > (e.g. rule priority number). But the current schema definition has no space
 > to specify such application specific parameters (or a too restricted
 > schema)
 > 
 > - Simple extension to support parameters for new combining algorithms
 > 
 > There are several ways to support arbitrary parameters in the policy.
 > 
 > 1) Add priority attribute in the Rule element
 > 2) Add priority element below the Rule element
 > 3) Allow to insert any element below the Rule element
 > 4) Add a certain element (e.g. <Property> element) for a placeholder that
 > allows any element below it.
 > 
 > The first two items are not appropriate since it is not applicable to the
 > cases where another parameter is needed (e.g. fuzzy parameter).
 > The third might be good but it may conflict to the pre-defined elements.
 > The fourth is more generic and better than the above. A sample example is:
 > 
 > <Policy>
 >   <Rule>
 >     <Property>
 >       <Priority>1</Priority>
 >     </Property>
 >     <Target>
 >     <Condition>
 >   </Rule>
 >   <Rule>
 >     <Property>
 >       <Priority>2</Priority>
 >     </Property>
 >     <Target>
 >     <Condition>
 >   </Rule>
 > </Policy>
 > 
 > I use <Property> element above which allows any element/attribute below it.
 > Next, there are several possibilities for the place where the <Property>
 > element can be put.
 > 
 > 1) Several elements can have <Property> but not all. (e.g. only PolicySet,
 > Policy, and Rule elements can have <Property>)
 > 2) Any elements can have <Property>
 > 
 > If we choose the first, the problem would be which elements are allowed to
 > have <Property>.
 > If we choose the second, there is no problem about the extensibility.
 > 
 > Once we come to agreement on the above issues, the next issue is how we
 > modify the schema definitions. I don't discuss further in this proposal.
 > 
 > 
 > - Another extension: support environment in target element
 > 
 > The current policy model allows policy writers to specify policy on targets
 > of subject, resource, and action but not on environment. The conclusion of
 > the TC about not specifying the environment in the target was that 1) usual
 > access control policy consists of a access triple, that are subject,
 > resource, and action, 2) environment variables such as current time do not
 > fit the limitations set on the target element.
 > 
 > Setting aside the first item, some application will benefit if XACML
 > supports environment in the target. For example, privacy protection policy
 > often consists of four arguments, that are subject, resource, action and
 > purpose. In most cases, purposes used in a certain policy are on list and
 > they are described in the policy as equality checking (e.g. if subject is
 > Operator and purpose is order fulfillment, then permit the access). Its
 > meaning is much closer to subject, resource, and action in the target
 > rather than arithmetic computation using the current time and date time.
 > One idea is to support purpose (or any attribute that policy writer wants
 > to specify) that can be used by a vender specific rule combining algorithm.
 > A sample privacy protection policy would be:
 > 
 > <Policy RuleCombiningAlgId="DenyOverridesWithPurpose">
 >   <Rule>
 >     <Target>
 >       <Subjects>
 >         <Subject>... subject is operator </Subject>
 >       </Subjects>
 >       <Resources>
 >         <Resource>... resource is /order </Resource>
 >       </Resources>
 >       <Actions>
 >         <Action> ... action is read </Action>
 >       </Actions>
 >       <Environments>
 >         <Environment> ... purpose is fulfillment </Environment>
 >       </Environments>
 >     </Target>
 >   </Rule>
 > </Policy>
 > 
 > Therefore, my proposal is to allow <Environments> element and
 > <EnvironmentMatch> element in the <Target> element.
 > 
 > Michiharu Kudo
 > 
 > 
 > 

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