ProxySG policy order does not guarantee the order of evaluation

Products

• ProxySG Software - SGOS

Issue/Introduction

There is a transaction that matches rules in multiple layers that trigger custom exceptions. Instead of the exception page defined in the last matched rule being displayed, the exception page in the first rule is displayed.

When a transaction matches multiple rules that set the same property, doesn't the property defined on the last matched rule prevail? This does not seem to be the case.

 

Cause

The order of policy evaluation depends on the condition timing that guards the rule. So it does not matter on how many times the policy has been evaluated.

For example, if there is an authentication rule getting involved, all the transactions will go through the same policy evaluation regardless of whether the transaction had been authenticated or not.

Note: the situation described above is a case with exception pages, the issue is not specific to exception page only, it could be caused by other type of objects as well like not matching an ICAP scanning, etc.

Resolution

For example, user goes to www.abc.com/object1, then it gets authenticated and then the same user make another request going to www.abc.com/object2 which already gets authenticated. So both the requests will still go through the same set of policy evaluations, in our example here, both requests will be evaluated with policy P1 and P2 which end up, P1 will be evaluated later and it gets applied.

So it depends on the timing of the rule or policy been evaluated especially if those policies are in a different policy definition. For example, P1 and P2 are in a different policy definition and been called in a different ‘proxy’ layers, so there is a timing involved here when it gets to which policy been evaluated first or later.

define proxy policy p1
  <proxy>
     exception(content_filter_denied, "bad content")
end

define proxy policy p2
  <proxy>
     deny("policy denied")
end

<proxy>
   authenticate(realm1)

<proxy>
   user=!guest policy.p1

<proxy>
   policy.p2

If desired to make sure that P2 will be always evaluated later and gets applied, here is an example recommended by engineering using the same example above:

define proxy policy exceptionP1P2
  <proxy>
     ;P1
     Condition=condition1 exception(content_filter_denied, "bad content")

  <proxy>
     ;P2
     deny("policy denied")
end

<Proxy>
policy.exceptionP1P2

So in the example above, the two polices – P1 and P2 are in the same policy definition and in separate ‘proxy’ layers but the outcome is different. Assuming the user matched ‘condition1’, the outcome will be the user will get ‘policy denied’ (P2) been applied to the user transaction instead of P1.