RE: [xacml] Another proposal (a good one this time)

[Tim Moses <tim.moses@entrust.com>]

Title: RE: [xacml] Another proposal (a good one this time)

Michiharu - I suggest that, if the formal language for meta-policy is inadequate, we should just drop it, and rely on a plain-language description.  XACML can describe a small number of meta-policies, and others can define new ones, either registering them through an XACML process, or keeping them entirely private.

All the best.  Tim.

-----------------------------------------
Tim Moses
Tel: 613.270.3183

-----Original Message-----
From: Michiharu Kudoh [mailto:KUDO@jp.ibm.com]
Sent: Sunday, March 03, 2002 6:35 AM
To: 'XACML'
Subject: Re: [xacml] Another proposal (a good one this time)

Tim,

The current syntax for the meta-policy is generic Boolean expression. I
agree that Boolean expression is generic and powerful, but in some cases,
it is not enough. For example, we need to write the policy rules using
precedencies. The policy which has higher precedence overrides the policies
that have lower precedencies. If two policies that have the same precedence
conflict each other, the global denial meta-policy is used. If two policies
having the different precedence, the higher precedence policy always
overrides the lower policy. Suppose that we need to write two policies,
p1and p2. Each policy has the precedence 1 and 2, respectively. The
precedence 1 is the highest precedence:

Policy(ID = p1, effect = "permit", precedence = "1", metaPolicyRef = ??)
  target(sbj1, res1, act1)
  condition(cond1)

Policy(ID = p2, effect = "deny", precedence = "2", metaPolicyRef = ??)
  target(sbj1, res1, act1)
  condition(cond2)

The decision is determined as follows (assuming that target parameters are
satisfied):

                 cond2
                 T                   F
---------------------------------
cond1  T    permit by p1   permit by p1
           F    deny by p2     indeterminate

Which Boolean expression should I specify for this meta-policy? I think
that the current meta-policy-1 does not solve this because p2 (deny) does
not always override p1 (grant). Do you think it is necessary to allow
user-defined meta-policy (based on not Boolean expression) in addition to
the Boolean expression type meta-policy?

Michiharu Kudo

IBM Tokyo Research Laboratory, Internet Technology
Tel. +81 (46) 215-4642   Fax +81 (46) 273-7428

From: Tim Moses <tim.moses@entrust.com> on 2002/03/01 05:20

To:   "'XACML'" <xacml@lists.oasis-open.org>
cc:
Subject:  [xacml] Another proposal (a good one this time)

Colleagues - Here is a new proposal.  I believe it addresses many of the
issues we are wrestling with in a self-consistent manner.  It is one that I
(personally) can live with as a point from which to start refining the
schema.  I would be interested to know whether others can "live with" it,
too.  All the best.  Tim.

Proposal

There is no syntactic distinction between a rule and a policy.  A rule is
simply a small policy.  So, I'll use the term "policy" exclusively for the
remainder of this discussion.

A policy statement contains:
· a policyId;
· a target;
· an effect;
· a metaPolicyRef and
· a condition.

Policy meta-data (such as issuer and issue instant) are conveyed in the
saml statement wrapper.

Target defines the set of names for the:
· resources;
· subjects and
· actions
to which the policy statement applies.  If the policy statement applies to
all entities of a particular type, then the target definition is the root
of the applicable name space.  An XACML PDP MUST verify that the names of
the resources, subjects and actions specified in an authorization decision
request are each included in the target of the policy statement that it
uses to evaluate the request.

MetaPolicyRef specifies the meta-policy by which the policy statement MAY
be combined with other policy statements.

Condition is a general expression of predicates of attributes.  It SHOULD
NOT duplicate the exact predicates implied by target.  Therefore, it MAY be
null.

Policy statements may be combined provided that their metaPolicyRefs are
identical and that their targets are in identical name spaces.  This SHALL
be done by including the conditions from the source policy statements in
the condition of the combined policy statement, in accordance with the
meta-policy.  (See draft-xacml-v0.9, Section 6 for an example of a
meta-policy).

The target of the combined policy statement can be calculated from the
targets of the source policy statements.  Two approaches are permitted:

· the target of the combined policy statement MAY contain the unions of the
target definitions for resource, subject and action that are contained in
the source policy statements; or

· the target of the combined policy statement MAY contain the intersections
of the definitions.
In the former case, the targets from the source policy statements MUST be
included in the form of conditions in the combined policy statement.  In
the latter case, this step MAY be omitted.  In the former case,
inapplicable predicates should not be encountered.  In the latter case,
inapplicable predicates may be encountered.

The effect of the combined policy is defined by the meta-policy.

The syntax of a combined policy statement is identical to that of a source
policy statement.

There is an alternative representation for a combined policy, called a
policy manifest.  It contains:
· a policyId;
· a target;
· a metaPolicyRef and
· a list of policy definitions.
A policy definition identifies a policy statement by meta-data, (e.g.
name).

A policy manifest can be converted to a policy statement at any time, by
applying the identified meta-policy to the policy statements identified by
the policy definitions.  The resulting policy statement MUST contain a
target computed from the target values in the actual versions of the source
policy statements used in the conversion, whereas, the target in the
manifest SHOULD be computed from the target values in the actual versions
of the source policy statements at the time the manifest was prepared.

The significance of the two representations is that, in the first case, the
policy statement is generated at the time of preparing the representation,
whereas, in the second case, the policy statement can be generated (using
the latest versions of the source policy statements) immediately prior to
evaluation.  PDPs SHOULD support both representations.

-----------------------------------------
Tim Moses
Tel: 613.270.3183

----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>