Controlling access to ICAP services

ACLs

NetCache access control lists (ACLs) are sets of rules that create policies for controlling access to services. ACL entries (or rules) allow, deny, or otherwise act on requests based on variables such as client IP addresses. NetCache is permissive by default, that is, ACLs are not enabled and no requests are denied.

ICAP services are configured using ACLs. ACLs must be enabled to perform ICAP services, and rules must be applied to direct user requests. You can use the Appliance Manager to enable ACLs for ICAP and to create rules that

Direct requests for ICAP services
Control who receives adapted content

How ACLs work

Actions are combined with expressions to form rules. Variables and associated values can be used to form pattern-matching expressions. When processing a request, NetCache compares the request against pattern-matching expressions until a match occurs. When a match occurs, actions are executed. If no match occurs, the action is not executed and rule checking continues.

If you are not familiar with ACLs in NetCache and writing rules to control client access, see the Configuration Guide to form a comprehensive understanding of how to create rules and implement policies for controlling access to the NetCache appliance.

Creating rules

Rules are an ordering of variables in the form of an expression. Expressions specify actions for directing ICAP requests. Rules for controlling ICAP services list a set of ICAP service farms. The ACL syntax is insensitive to the order in which services are listed. For example, the following rules are equivalent:

icap(virus_check, ad_insert) user bob

icap(ad_insert, virus_check) user bob

The actual order of services is determined during ACL processing, when the vectoring point for each service retrieves its order from the services list. For more information, see Ordering of services.

ACL actions for controlling ICAP services

NetCache supports the following actions and variables that are specific to handling requests for ICAP services.

Action/Variable	Description
`icap`	Directs requests for ICAP services. For example: `icap(virus_check) server-ip 10.20.30.151 and url matches exe` In this example, the virus-scanning service is configured for all HTTP requests to server IP 10.20.30.151 that contain a URL pattern that matches "exe." Note When listing multiple services, you must separate each with a comma followed by a blank character. For example, `icap(service1, service2, service3)`.
`icap_now`	Sends a precache request modification (REQMOD) to an ICAP service. The `icap_now` action is used for ICAP services that must be invoked early in an ACL evaluation process, for example, content-filtering services. Filtering services typically implement access control policy checks that must be invoked during ACL processing. For example: `icap_now(content_filter)` In this example, ICAP filtering is invoked for all requests. Note All `icap_now` service farms must provide precache request modification services (REQMOD_PRECACHE vector), which adapt a request that is sent to the cache, for example, content filtering. See Vectoring points for a description of request and response modification service types.
`attribute`	Applies to attributes returned by ICAP services. The `attribute` variable directs NetCache to compare values, such as a URL category returned by an ICAP service during an ACL evaluation. For example: `attribute service_farm_name attribute_value` In this example, the named service returns the attribute, and the value is compared. Note An ICAP service must be invoked before a check for its attribute can be made. The `icap_now` action advances ACL evaluation for services. If an `icap_now(service_farm_name)` clause is not processed before an attribute clause, the service is not recognized, and an error message is returned to the client.

Action/Variable

Description

icap

Directs requests for ICAP services. For example:

icap(virus_check) server-ip 10.20.30.151 and url matches exe

In this example, the virus-scanning service is configured for all HTTP requests to server IP 10.20.30.151 that contain a URL pattern that matches "exe."

Note
When listing multiple services, you must separate each with a comma followed by a blank character. For example, icap(service1, service2, service3).

icap_now

Sends a precache request modification (REQMOD) to an ICAP service. The icap_now action is used for ICAP services that must be invoked early in an ACL evaluation process, for example, content-filtering services. Filtering services typically implement access control policy checks that must be invoked during ACL processing. For example:

icap_now(content_filter)

In this example, ICAP filtering is invoked for all requests.

Note
All icap_now service farms must provide precache request modification services (REQMOD_PRECACHE vector), which adapt a request that is sent to the cache, for example, content filtering. See Vectoring points for a description of request and response modification service types.

attribute

Applies to attributes returned by ICAP services. The attribute variable directs NetCache to compare values, such as a URL category returned by an ICAP service during an ACL evaluation. For example:

attribute service_farm_name attribute_value

In this example, the named service returns the attribute, and the value is compared.

Note
An ICAP service must be invoked before a check for its attribute can be made. The icap_now action advances ACL evaluation for services. If an icap_now(service_farm_name) clause is not processed before an attribute clause, the service is not recognized, and an error message is returned to the client.

Content category restriction using NetCache ACLs

The NetCache access control scheme provides a mechanism for setting content category-based restrictions. NetCache ACL settings can be used to allow or deny user access to content.

Example

The icap_now action enables NetCache to send an ICAP precache request modification early in an ACL evaluation so that subsequent ACLs can be applied to categories. Filtering services typically categorize content, and attribute values can be used to specify access to content. Consider the following rule:

icap_now(content_categorization) any

deny user bob and attribute content_categorization sports

In this example, the icap_now action enables NetCache to send an ICAP precache request modification early in an ACL evaluation. the attribute variable is used for category-based control. The icap_now action invokes the ICAP service, and user Bob is denied access to all Web sites for which the ICAP service returns the attribute sports.

Authenticating users

Authentication is the process of determining a users identity. NetCache is permissive by default, which means that authentication is not enabled and access to all protocols is allowed. The NetCache authentication and ACL features enable you to control access to the NetCache appliance by individual user or groups of users. Authentication verifies the identity of the user, and ACLs authorize access to services. Use the options on the Authentication pages of the Appliance Manager to enable authentication (Setup tab > Authentication).

If you are not familiar with authentication in NetCache, see the Configuration Guide to form a comprehensive understanding of supported methods for authenticating users to NetCache services.

Using ACLs to authenticate users

NetCache ACL settings can be used to force authentication before user requests are serviced. The following actions can be used to form rules that control requests for access to supported services.

Action	Description
`auth`	Require authentication and continue the rule checking sequence if already authenticated.
`re-auth`	Force reauthentication.
`try-auth`	Require authentication and continue the rule checking sequence even if authentication fails.

Example

ACLs can be used to create a policy that authenticates users and directs access to ICAP-serviced content. Consider the following policy:

auth any

icap(translate-french) group engineering

icap(content-filter) not group marketing

deny attribute content-filter news and time 9am-5pm

In this example, NetCache directs requests from the engineering group to the ICAP language translation server. With the exception of requests from the marketing group, all requests are sent to the ICAP content-filtering server. The ICAP filtering service categorizes content, and all filtered requests are denied access to news Web sites from 9:00 a.m. to 5:00 p.m.