Policy re-evaluation can deny previously allowed transaction if Force action (such as force_deny or force_exception) is applied with sub-optimal layer order.

Products

• ProxySG Software - SGOS

Issue/Introduction

I have long-lived connections that were already allowed by policy rules, yet were denied when I installed policy (regardless of the change).

Resolution

When you install policy with the VPM, the policy engine re-evaluates existing and previous allowed transactions to ensure policy integrity during the prosessing. This re-evaluation might deny exisiting connections if the associated condition is changed. However, even if you install policy on VPM without any changes, the similar issue might occur if the policy layers order is not optimal.

This problem only occurs only when:

• Force action is used, such as force_deny or force_exception
• User/group source condition comes earlier than authentication rule (see below examples)

SOLUTION:

Reordering the Policy Layer.

In this example, a Web Access Layer with user-group source condition is located before the Web Authentication Layer. 
With this layer order, the already-allowed transaction is denied when ProxySG re-evaluates the existing transactions.

<Proxy>
   ALLOW condition=__GROUP1
<Proxy>
   authenticate(iwa) authenticate.force(yes) authenticate.mode(proxy)
<Proxy>
   trace.request(yes) trace.rules(all) trace.destination(test)
<Proxy>
   ALLOW condition=__GROUP1 service.name="Explicit HTTP"
   FORCE_DENY

 If the order is corrected and if the Web Authentication Layer is located before the Web Access Layer in the policy layer order, the already-allowed transactions are not denied.

<Proxy>
    authenticate(iwa) authenticate.force(yes) authenticate.mode(proxy) 
<Proxy>
    ALLOW condition=__GROUP1 
<Proxy>
    trace.request(yes) trace.rules(all) trace.destination(test) 
<Proxy>
    ALLOW condition=__GROUP1 service.name="Explicit HTTP" 
    FORCE_DENY 

; Definitions
define condition __GROUP1
    realm=iwa group=COMPNET\almas_group end