ProxySG Content Policy Language Guide
46
The following example is an exception defined within a layer. A company wants access to payroll
information limited to Human Resources staff only. The administrator uses membership in the
HR_staff group to define the exception for HR staff, followed by the general policy:
<Proxy>
; Blue Coat uses groups to identify HR staff, so authentication is required
authenticate(MyRealm)
define condition payroll_location
url=hr.my_company.com/payroll/
end
<Proxy> condition=payroll_location
allow group=HR_staff ; exception
deny ; general rule
This approach requires that the policy be in one layer, and because layer definitions cannot be split
across policy files, the rule and the exceptions must appear in the same file. That may not work in
cases where the rules and the exceptions are maintained by different groups.
However, this is the preferred technique, as it maintains all policy related to the payroll files in one
place. This approach can be used in either blacklist or whitelist models (see "Blacklists and Whitelists"
on page45) and can be written so that no security holes are opened in error. The example above is a
whitelist model, with everything not explicitly mentioned left to the default rule of deny.
Using Layer Ordering to Define Exceptions
Since later layers override earlier layers, general rules can be written in one layer, with exceptions
written in following layers, put specific exceptions later in the file.
The Human Resources example could be rewritten as:
<Proxy>
; Blue Coat uses groups to identify HR staff, so authentication is required
authenticate(MyRealm)
define condition payroll_location
url=hr.my_company.com/payroll/
end
<Proxy>
condition=payroll_location deny ; general rule
<Proxy>
condition=payroll_location allow group=HR_staff ; exception
Notice that in this approach, some repetition is required for the common condition between the layers.
In this example, the condition=payroll_location must be repea ted. It is very imp ortant to keep the
exception from inadvertently allowing other restrictions to be undone by the use of allow.
As the layer definitions are independent, they can be installed in separate files, possibly with different
authors. Definitions, such as the payroll location condition, can be located in one file and referenced in
another. When linking rules to definitions in other files, file order is not important, but the order of
installation is. Definitions must be installed before policy that references them will compile. Keeping
definitions used across files in only one of the files, rather than spreading them out, will eliminate the
possibility of having changes rejected because of interlocking reference problems. Note that when
using this approach, exceptions must follow the general rule, and you must be aware of the policy file