#9 TargetMatch re-orders comparison operands

[Bill Niebel]

sunxacml correctly evals this policy pseudocode to A < B:

<xMatch MatchId="dateTime-less-than">
<AttributeValue DataType="dateTime">A</AttributeValue>
<xAttributeDesignator DataType="dateTime"
AttributeId="B"/>
</xMatch>

The following policy pseudocode reverses both function
sense
and operand order and so would seem to do exactly the same
as above. But instead it has the opposite effect from
what's
expected, i.e., doesn't eval to B > A, but to B < A:

<xMatch MatchId="dateTime-greater-than">
<xAttributeDesignator DataType="dateTime"
AttributeId="B"/>
<AttributeValue DataType="dateTime">A</AttributeValue>
</xMatch>

sunxacml code [end of method TargetMatch.getInstance()]
doesn't record the order of these two operands, so the
subsequent comparison is sometimes accidentally right,
other
times wrong. It records AttributeValue and
AttributeDesignator/Selector separately. Subsequent code
assumes that the AttributeValue is always the first
operand
and that the AttributeDesignator/Selector is always the
second operand. Hence, in the second pseudocode, the
operands are in effect silently re-ordered.

This code deals specifically with Targets, but there
may be a
similar issue in Conditions.

From the code, it seems that there can be only one each of
AttributeValue and AttributeDesignator/Selector. This is
unfortunate: allowing two
AttributeDesignators/Selectors would be useful, and
seems to be within the oasis standard.
It appears to be disallowed in sunxacml only as a side
effect
of the class containing the bug. It would be great if
this
bug fix would allow two AttributeDesignators/Selectors.

[Seth Proctor]

Logged In: YES
user_id=688081

Hi Bill. This is not a bug in the SunXACML code. The XACML specification
requires that the parameters to a TargetMatch are first a value followed by
a designator or a selector. In fact, if you ran your policy with the swapped
match through a schema checker, the policy would be rejected. This is a
case of the code assuming your're using a validated policy, which is why
when you swapped the order, the code didn't reject the policy but did do
the evaluation correctly.

As for allowing multiple designators/selectors, sorry, but that's not allowed
by the spec. If the spec allowed it, I'd add support, but it's invalid. Let me
know if you have any questions about this...

seth