ProxySG Content Policy Language Guide
20
This provides the ability to test various aspects of a request, such as the IP address of the client
and the URL used, or the response, such as the contents of any HTTP headers.
•Ensures policy integrity during processing.
The lifetime of a transaction may be relatively long, especially if a large object is being fetched
over slow networks and subjected to off-box processing services such as content filtering and
virus scanning. During this time, changes to configuration or policy rules may occur, which
would result in altering the policy decisions that affect a transaction. If a request was evaluated
against one version of policy, and some time later the associated response were evaluated against
a different version of policy, the outcome would be unpredictable and possibly inconsistent.
The transaction ensures that both the request and the response are evaluated against the version
of policy that was current when the transaction was created. To ensure that new policy is
respected, long lived transactions such as those involved in streaming, or large file downloads, are
re-evaluated under new policy. Re-evaluation applies to both the request and response, and any
resulting new decisions that cannot be honoured (such as new authentication requirements) result
in transaction termination.
•Maintains policy decisions relevant to request and response processing.
•Various types of transactions are used to support the different policy evaluation requirements of
the individual protocols: administrator, cache, and proxy transactions.
•In a few special cases, two or more transactions can be created for a single request. For example, if
an HTTP request is made via the SOCKS proxy (on port 1080 of the ProxySG), then it is possible
for two transactions to be created: a SOCKS proxy transaction, and an HTTP proxy transaction.
You can see these transactions for yourself if you turn on policy tracing. A new entry is added to
the policy trace file for each transaction.
Policy Model
Each transaction begins with a default set of decisions, many of which are taken from configuration of
the system. These defaults include such things as forwarding hosts or SOCKS gateways. The most
important default decision affects whether or not requests should be allowed or denied. The defaults
for the various transaction types are:
•Administrator Transaction— the default is to deny requests.
By default, administration is only available through one of the methods that bypasses policy
evaluation. These are:
❐accessing the CLI through the serial console
❐accessing the CLI through RSA authenticated SSH
❐logging into the Management Console or CLI using the console credentials
Specific rights must be granted through policy to enable other administration methods.
•Cache Transactions—the default is to allow requests.
These requests originate from the ProxySG itself, and are used primarily to maintain the state of
content. Additional policy can be added to specifically deny requests for specific content, and to
distinguish content management requests from other cache transactions.
•Proxy Transactions—the default is taken from system configuration.