RE: [xacml-comment] Comment on condition element

[David Sutton <David.Sutton@cp.net>]

Hi Anne,

I'm happy to drop the point as I can see four ways of accomplishing what I
want given the current framework.

1) As you suggested below, define a new rule-combining algorithm in which
the result is NotApplicable unless the first rule is true.

However I personally don't like this option too much as it seems a bit
contrived to define a new rule-combining algorithm of this nature. Also a
rule never actually evaluates to 'true'. A rule value is either 'Effect',
'Not-applicable', or 'Indeterminate' - so I guess the new algorithm would be
that the rule-combining algorithm result is NotApplicable unless the first
rule is 'Effect'.

2) Use obligations (which are available at the policy and policy set level)
to hold the role requirement.

This I think would work - but since obligations are currently sort of
outside the current document it is sort of an out-of-band solution.

3) Use the relaxed (i.e. non-indexable) form of a target element in the
policy object. This would allow a subject to be true for any subject whose
role occupant attribute holds the appropriate role name.

4) Have the same condition on each of the policy's rules.

Please see a few additional comments for your consideration below.

Thanks,

- David

> -----Original Message-----
> From: Anne Anderson [mailto:Anne.Anderson@Sun.com]
> Sent: 16 December 2002 16:45
> To: David Sutton
> Cc: xacml-comment@lists.oasis-open.org
> Subject: RE: [xacml-comment] Comment on condition element
>
>
> On 16 December, David Sutton writes: RE: [xacml-comment] Comment
> on condition element
>  > From: "David Sutton" <David.Sutton@cp.net>
>  > > If you want a condition at the policy or policy set level,
>  > > include a rule.
>  >
>  > By including a rule with a condition is not the condition
> scope limited to
>  > that rule only - not the policy or policy set? So no other
> rules in the set
>  > would be affected by a condition in any other rule in the
> policy or policy
>  > set.
>
> This could be done with a new rule-combining algorithm in which
> the result is NotApplicable unless the first rule is true.  Then,
> one of the other rule-combining algorithms could be called into
> play.  This makes the semantics clear.
>
> If we allow Condition in a Policy, the Policy writer will not
> necessarily want the Policy to return NotApplicable if the
> Condition is false.
> What if a policy writer wants the policy to
> return Permit or Deny if the condition is false?

So could they not simply negate the condition so that it returned true?

> If we allow
> Conditions in policy sets or policies, then we would need to
> specify the "combining algorithm" for combining the result of the
> enclosing structure's policy with the results of the set of
> enclosed structures.

Sounds a bit horrid. However I'm not sure that this is true. Since the
<Condition> element further refines the applicability established by the
target, then having a condition element doesn't place any extra changes on
the model since it is only a way of refining the target. The model already
describes the appropriate behaviour for target results of 'Match',  'No
Match' and 'Indeterminate'.


>
> I would rather not complicate things unless the existing
> mechanisms are inadequate.
>
>  > Based on some recent comment I understand that the requirement
> that target
>  > elements be indexable may have been relaxed. If this is so
> then it would be
>  > possible to make the role requirement part of the policy
> target (assuming
>  > for example that role membership would be a subject attribute).
>
> That is true.  Target elements are not required to be indexable
> according to any particular indexing scheme.
>
>  > On a related secondary note I'm not clear on what is the
> behaviour for a
>  > rule that does have a target when its enclosing policy or
> policy set also
>  > has a target? Is the rule bounded by both the rule target and
> the inherited
>  > target or does a rule only inherit a target when the rule has no target
>  > element itself?
>
> The Target of the outer structure acts as a filter: if it returns
> False, then the inner structures are never evaluated.  The Target
> on an inner structure will be applied only if the inner structure
> is evaluated, so it serves only as a way of potentially narrowing
> the Target of the inner structure.

Thanks - that's how I hoped it would work.

>
> Some systems may compose outer structures from sets of inner
> structures (i.e. policies from a set of rules, policy sets from a
> set of policies and policy sets): this is outside the scope of
> XACML, since the XACML PDP will only see the final composition.
> In this case, the Target of the outer structure may be computed
> based on the union (or intersection) of the Targets of the inner
> structures.
>
> Anne
> --
> 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
>
>