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

["Michiharu Kudoh" <KUDO@jp.ibm.com>]

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