Excelerator XL 1.0 access control policies are so named because they let you implement the intent your organization's formal or informal policies as specific, simple rules that are enforced on cache devices.
The following sections explain the purpose and structure of Excelerator XL 1.0 access control policies in detail.
As stated earlier, the chances are good that your organization already has formal or informal policies that specify who can access your cache devices and for what purposes.
Without access control policy enforcement, anyone with network access to a device is able to access any services on the device.
Although there are undoubtedly some situations wherein allowing universal access to cache devices on the network is desirable, for most installations, access needs to be controlled for security or other resource-management reasons.
The access control policies you create on your Excelerator XL 1.0 devices should probably reflect your organization's policies in scope and complexity.
Policies can range from a rule as simple as
to a complex set of rules that limits device access to
Excelerator XL 1.0 access control policies consist of one or more of each of the following:
Policy: This is a logical container that lets you organize and manage access control rules. Policies are further explained in Policies Put It All Together.
Rule: This is a key component because true and false results come from rule evaluation. Rules have an assigned action and are evaluated according to their priority settings and action types. Rules are further explained in Rules Specify the Action and the Evaluation Order. Rule evaluation order is explained in Evaluating Your Access Control Policies.
Set: This is an organizational unit within a rule that provides logical flexibility and complexity in organizing the rule's conditions. The organization of individual conditions inside of and among a rule's condition sets is a key mechanism to the rule's internal logical flow. Sets are further explained in Sets Enable Complexity.
Condition: This is the fundamental unit of access control. Conditions specify how request data is evaluated for obtaining a true or false result. Conditions are further explained in Conditions Are Specific, Boolean Tests That Are Either True or False.
Each of these is explained in more detail in sections that follow as indicated above. However, before reading detail about each component, a visual representation of how policy components fit together might be useful.
Figure 18 shows the relationships and functions of the components that compose an access control policy.
Figure 18
There are five basic condition types:
Each of these is designed to test specific request data and most of them contain three basic elements:
Operators vary according to operand type and include such statements as: equals, does not equal, is authenticated, etc.
NOTE: A few condition types, such as User Is Authenticated and DNS Mismatch, don't have right-hand operands.
When a condition is evaluated, the left-hand operand (request data) is compared against the right-hand operand (a value you have specified) for obtaining a Boolean result---either true or false.
For example, you might set a condition for comparing the target URLs in requests with the URL http://www.nonproductive_site.org. If the device then receives a request for this site, the condition evaluates as true. Requests to any other Web sites evaluate as false.
If the condition evaluates as true, the rule to which the condition belongs will either allow or block the request depending on the rule's assigned action.
NOTE: Allow and block actions are assigned to rules, not conditions.
Multiple conditions are joined together with either And or Or depending on the Join setting for the rule to which the conditions belong. For more information on condition joining, see Joining Conditions and Sets Inside Rules.
Although it is not obvious in the management interface, there is always at least one set of conditions within every rule.
The first set is preceded by either an If or an If Not statement as selected using the drop-down list located in the horizontal bar marking the first set of conditions.
Each subsequent set of conditions is preceded by either an And (or And Not) statement or an Or (or Or Not) statement, depending on the Join value specified for the rule. For more information, see Joining Conditions and Sets Inside Rules.
Condition sets let you group similar conditions together within a rule and are generally analogous to the function that parentheses perform in programming logic.
The term rule can easily become confused with the functions performed by sets and conditions. The key points to remember are these:
Requests are evaluated against rules after they are sorted by priority and action type. For more information on how rules are sorted, see Evaluating Your Access Control Policies.
Rules can be enabled and disabled as access control needs change. Requests are only evaluated against rules that are enabled. If the policy containing a rule is disabled, the rule is effectively disabled as well.
Policies are the organizational containers for managing rules. Each policy has a name and an associated stage, neither of which can be modified once the policy is created.
The policy name can contain from two to 32 alpha-numeric characters and spaces and usually indicates something about the purpose and function of the rules it contains.
The policy's stage specifies which request type (new connection or user) its enabled rules will be evaluated against.
The system evaluates requests only against enabled rules in enabled policies. Disabling a policy effectively disables all the rules contained within the policy (but it doesn't change the Enabled setting for each rule).
The order in which policies are enabled influences the order in which rules are evaluated. For more information on the rule evaluation process, see Evaluating Your Access Control Policies.
Creating the logical expression of your access control policies often requires the ability to join and group condition statements.
Excelerator XL 1.0 access control rules provide
To facilitate the evaluation of rules, Excelerator XL 1.0 uses disjunctive normal form (DNF) and conjunctive normal form (CNF) to define the relationships between the conditions and sets within a given rule.
This form is used when a rule's Join drop-down list is set to And.
The first rule shown in Figure 18 is in disjunctive normal form, meaning that the conditions within the rule are joined by And and the two sets are joined by Or.
Rules that use disjunctive normal form are true only when
IMPORTANT: Using a Not statement to join a set changes a true result to false and vice versa. For more information, see Using Not.
This form is used when a rule's Join drop-down list is set to Or.
The second rule shown in Figure 18 would be in disjunctive normal form if it contained multiple sets, because the sets would be joined with either And or And Not.
Rules that use conjunctive normal form are true only when
IMPORTANT: Using a Not statement to join a set changes a true result to false and vice versa. For more information, see Using Not.
Excelerator XL 1.0 access control rules let you quickly reverse a true or false result by specifying the keyword Not in your logical expressions.
Having this ability provides an important short-cut to efficient logic in some situations. However, we recommend that you avoid using Not since tracking the logic becomes confusing very quickly when Not keywords get involved.
Each condition statement operator pair has one Not member. Examples of pairs include: Is and Is Not, Group Is and Group Is Not, Is Authenticated and Is Not Authenticated, etc.
Table 9 shows how the results within individual condition statements are reversed when Not is used.
Table 9.
| Source IP in Request | Operator | Value Specified in Condition Statement | Result |
|---|---|---|---|
10.1.1.1 |
Is |
10.1.1.1 |
True |
10.1.1.1 |
Is Not |
10.1.1.1 |
False |
10.1.1.2 |
Is |
10.1.1.1 |
False |
10.1.1.2 |
Is Not |
10.1.1.1 |
True |
Each set in a rule is preceded by a drop-down list. The list before the first set contains If and If Not. The list before all other sets contains either Or and Or Not, or And and And Not, depending on the Join setting for the rule to which the sets belong. For more information, see The Disjunctive Normal Form and The Conjunctive Normal Form.
The key point to remember when selecting If Not, And Not, or Or Not before a set is that the result of evaluating the conditions in the set will be reversed. In other words, if the set would normally report a true result to the rule, it will report a false result; if it would normally report a false result, it will report a true result.
Obviously, using a Not option to precede or join sets can quickly become confusing and should generally be avoided.
In Excelerator XL 1.0, authentication profiles and access control policies are separately defined and completely independent of each other unless they are configured to work together.
Authentication profiles represent a resource that access control policies can leverage if the profiles are active for one or more proxy services.
There are some precautions that must be observed when coupling access control policies with authentication profiles. For example, if authentication is required for some proxy services but not for others and you have policies that require authentication, you must ensure that requests from unauthenticated users are either allowed or blocked before the rules that require authentication come into play. For more information, see Step 4 in Plan Access Control Rules.
Figure 19 illustrates how access control policies and authentication profiles work together to control access to device services.
Figure 19 
Excelerator XL 1.0 filtering services are tightly coupled with access control policies.
You can identify N2H2 and/or Websense servers and create conditions that access them as either Filtering Servers or Category Servers. The conditions then request input from these servers as follows:
Filtering Servers: Conditions that reference a filtering server send request data to the server and request a report from the server as to whether it would allow or deny the request.
The key point to remember is that getting authorization from the server doesn't automatically translate to the request being allowed. You must create a rule that either allows or blocks the request based on whether the conditions that refer to the filtering server evaluate as true or false.
Although it would seem illogical, you could create a rule that blocks requests the filtering server indicates should be allowed and allows requests that the server indicates should be denied.
For an illustration of how access control policies work with filtering servers, see How a Filtering Server Works with Access Control Policies.
Category Servers: Conditions that reference a category server send the request's URL data to the server with a request that the server return the category information for the URL.
You must create rules that allow or block requests based on the category information the category server returns.
For an illustration of how access control policies work with category servers, see How a Category Server Works with Access Control Policies.
Figure 20
How a Filtering Server Works with Access Control Policies
Figure 21
How a Category Server Works with Access Control Policies
Figure 22 shows how requests are processed when access control policies, authentication profiles, and filtering servers are all involved in access control.
Figure 22 