Before planning and creating access control policies for an Excelerator XL 1.0 device, you need to understand how the controls work as explained in this section.
If you already understand the basics of Excelerator XL 1.0 access control, planning instructions begin with Planning Access Control Policies and instructions for creating access control policies are found in Setting Up Access Control Policies.
Excelerator XL 1.0 access control policies are enforced at the device level. All active policies apply to everyone seeking access to any device services.
Access control policies contain rules you create that include a system action for when the rule is evaluated as being true. There are only two actions you can specify: Allow or Block.
Therefore, if you create a rule with an associated action of block, and the rule evaluates as true for a given request, the request is blocked. Conversely, if an allow rule evaluates as true for a request, the request is allowed.
NOTE: When a rule evaluates as false, there is no action and the request passes through until either a subsequent rule evaluates as true for the request or all the rules are evaluated.
If no rules evaluate as true for a request, the request is allowed by default.
Only the explicit blocking of a request prevents it from being processed.
In Excelerator XL 1.0, access control can happen at two points or stages as they are called in the device's System Controller.
When a browser or player first contacts a cache device with a request for data, there are two requests involved:
The New Connection Request: This is the request wherein the browser or player requests a TCP connection with the cache device. If the connection is established, the browser or player can then begin requesting data.
The User Request: This is a request for data from the cache device and it can only be made after a TCP connection is established with the device.
Excelerator XL 1.0 access control policies apply to only one of these request stages.
If you create and enable new connection policies, the system applies them when any connecting device (usually a browser or media player) sends the initial request for a TCP connection to the cache device.
New connection requests contain only the following data pertinent to access control
For forward proxy services, the Incoming IP Address is one of the cache device's IP addresses.
For transparent proxy services, the Incoming IP Address is the address of the origin Web server to which the browser or player sent the request before it was redirected to the cache device.
Specifying access control to happen at the new connection stage makes sense if your organization's policy for device access refers to either of these addresses and ports and includes statements similar to the following:
If you create and enable user request policies, the system applies them when the connecting device sends a request for data or other information after the TCP connection is established.
Like new connection requests, user requests also contain source and incoming IP address and ports. But they also contain additional data that access control policies can use, such as
NOTE: Generally, if your organization's policies allow access to only specific domains or host names, you will need to implement access control policies governing user requests.
The exception to this general rule applies to requests being redirected to a device's transparent proxy service. If requests are redirected, and if you know the IP address of the origin Web server, you could use a new connection policy to allow or block requests to the server's address (the Incoming IP Address).
Of course you could block the requests at the user request stage instead, but blocking through a new connection policy saves the overhead of establishing a TCP connection with the requesting browser or player.
Excelerator XL 1.0 access control works by evaluating the requests that come into the device against access control policy rules that you create. These rules are actually composed of one or more very specific conditions, such as user is authenticated or URL path is /userfiles/*. For more information regarding rules and conditions, see About Policies, Rules, Sets, and Conditions.
Figure 17 shows how requests are allowed or blocked based on rule evaluation.
Figure 17
Although the term access control might seem to imply that some requests are blocked, that is not true unless you create one or more rules that cause a block action when they are true.
Figure 17, Step 2 shows that if you only have rules that allow access, no requests coming into the device will be blocked. This is because all requests will evaluate as either true or false. If they are true, access is explicitly allowed. If they are false, no action is taken and the requests are allowed to pass through by default.
In other words, only requests that are explicitly blocked are actually blocked.
If you have both new connection policies and user request policies, keep in mind that the rules for both are evaluated separately. This means that a new connection request might be allowed by a new connection policy rule only to have the subsequent user request blocked by a user request policy rule.
This point is shown in Table 8.
Table 8.