This section contains the following subsections describing additional features supported by Proxy Services:
You can schedule downloads of HTML files from a Web site to the local cache. You can download one URL, multiple URLs up to a specified number of links, or an entire Web site. You can specify batch downloads for both forward and reverse HTTP proxies. However, reverse proxy will not download links that are external to a site.
Schedule a download before the workday starts to optimize your use of network resources. Using batch downloading keeps the cache of objects up to date for users.
HTML documents can have Java applet tags embedded in them without your knowledge.
A Java applet is a Java program that can be included in an HTML page. When you use a Java-compatible browser to view a page that contains a Java applet, the applet's code is transferred to your system and executed by the browser.
Once downloaded, the applet can excessively consume system resources, interfere with other applets, inspect and change client files, and make unauthorized client connections. With Novell BorderManager 3.7, you can enable Java blocking and filter the received HTML pages for any embedded applets. Any applets are removed from the document before it enters the system.
Proxy authentication to a proxy server can be accomplished in two ways:
If proxy forward or reverse authentication is enabled and both single sign-on and SSL are enabled, the proxy server will first try to authenticate the user through single sign-on. If the single sign-on attempt fails, the proxy server will establish an SSL connection with the client and then authenticate the user with an NDS or eDirectory username and password.
When you use Novell Client32, single sign-on eliminates the need for additional proxy authentication after you log in to NDS or eDirectory.
When the client generates a browser request, the proxy server verifies whether the client is authenticated. If the client is not authenticated, the proxy server requests that the client initiate a background authentication to the proxy server. All the protocol exchanges occur in the background, and the user is not prompted to enter an additional username and password.
Single sign-on is successful only when the client machine is running the Novell Client32 software and has logged in to NDS or eDirectory. The client machine must also be running DWNTRUST.EXE and CLNTRUST.EXE. These files are located in the SYS:PUBLIC directory on the server.
Single sign-on occurs on port 3024 on the server. If single sign-on has been enabled on the same Novell BorderManager 3.7 server for both the Novell IP Gateway and Proxy Services, only one background authentication is required for a user to use both services. This is because of the shared port on the server. For single sign-on to work, packet filtering firewalls in the routing path between a gateway or proxy client and a Novell BorderManager 3.7 server must allow packets designated for port 3024 to pass through.
For information on using single sign-on with the Novell IP Gateway, refer to Novell IP Gateway and NAT Overview and Planning.
SSL authentication also eliminates the need for an additional proxy password. For clients running Novell Client32, SSL authentication is used when single sign-on fails or is not enabled. For non-Novell clients, SSL is the primary method for eliminating the need to send an eDirectory username and password in clear text.
SSL ensures private and secure communication between the browser and the proxy server using a public-private key encryption system. When the client makes a browser request, the proxy server responds by requesting authentication using a Java applet or an HTML form. In response, the browser creates an SSL connection and sends the eDirectory username and password, encrypted over SSL, to the proxy server. The proxy server then authenticates the user with eDirectory.
To use SSL authentication, you must generate a certificate for the proxy server, which is then used for setting up encrypted channels. Proxy SSL requires Secure Authentication Service (SAS). Use the Novell Public Key Infrastructure (PKI) Services snap-in module to NetWare® Administrator to change and create certificates, key material objects, and key IDs. Refer to the PKI online help for more information.
For information on using SSL and the Novell IP Gateway, refer to Novell IP Gateway and NAT Overview and Planning.
ICP hierarchical caching includes the following elements:
Proxy servers maintain knowledge about each other using intelligent cache topologies. Hierarchical proxy caching increases performance by retrieving first-time access and negative cache data from the optimal nearby proxy server without having to retrieve this data from the origin Web server.
You can configure hierarchical cache routing to improve the performance of local cache misses. Two cache routing systems are provided: first-generation CERN cascading and second-generation Internet Cache Protocol (ICP) hierarchical caching.
The CERN cascading system provides standard HTTP forwarding through proxy chains. The ICP hierarchical cache system provides advanced cache routing through a designed cache topology. ICP provides maximum performance, scalability, and fault tolerance for both intranet and Internet Web caching.
ICP hierarchies are built on neighborhoods of proxy cache services. These neighborhoods are made up of parents and peers. The local proxy cache service normally has five neighbors. You can define multiple parents to improve performance and fault tolerance. ICP dynamically determines optimal cache fulfillment in the neighborhood. It also automatically detects down neighbors and recovers them.
The difference between peers and parents is in the fulfillment of URL objects that are not cached in the neighborhood. Only parents can be requested to obtain a URL for the neighborhood. The basic ICP fulfillment strategy is to obtain a neighborhood cached object from the most optimal neighbor (the one that responds first with a cache hit), and to obtain missed URL objects for the neighborhood and its local cache from the most optimal parent (the parent that responds first with the most preferred cache route).
The following are some basic guidelines for ICP neighborhood topology:
The Internet Cache Protocol (ICP) is a UDP-based message format used for communication among proxy caches. ICP is used in a cache mesh to locate cached Web objects in neighboring caches. Caches exchange ICP queries and replies to select the best location from which to retrieve an object. Once the location is determined, the object is retrieved using HTTP proxy.
When a query is received, the cache first checks its local cache, then sends ICP queries to its neighbors. The neighbors return ICP replies indicating a hit or miss. Depending on the replies, the proxy might access the parent neighbor to retrieve the object from the origin server. Novell BorderManager 3.7 is not set up to send queries through a Web hierarchy by default.
Neighbors can be configured as multicast groups. A multicast group is a list of addresses on which the ICP server receives multicast IP queries. A request for information can be sent to a multicast group.
The ICP server is configured with a list of the multicast groups or addresses that will participate in the ICP requests. The ICP client is configured with the responder list, a list of all acceptable neighbors (a unicast list) that can respond to a multicast query. This allows the ICP client to verify whether the responses are from a valid neighbor. The client keeps track of both the multicast responders and the multicast neighbors.
Setting up multicast groups reduces traffic congestion and configuration time. With multicast groups, you are not required to configure each neighbor separately, and the neighbors do not send multiple packets.
If a cache miss occurs, the proxy uses the source roundtrip time to determine whether to send the request to a parent or to the origin server. To calculate the roundtrip time, the proxy sends an Internet Control Message Protocol (ICMP) query to the origin server and the parent caches. The proxy uses the route that returns the shortest roundtrip time.
ICP domain routing is used to regulate ICP traffic based on host domains. The geographic distribution of neighbor caches might dictate that some domains can be better served by one cache over others. When you set up ICP clients, you can associate each neighbor with a list of route domains that it will serve. This increases response time and efficiency and reduces network traffic.
For example, the following configuration is in effect:
Neighbor host1 parent http_port=8080 icp_port=3130 .com .net .au .de
Neighbor host2 parent http_port=8080 icp_port=3130 .edu .mil
Neighbor host3 parent http_port=8080 icp_port=3130
In this example, the queries for root domains .com, .net, .au, and .de are forwarded to host1 or host3. Queries for .edu and .mil are forwarded to host2 or host3. Queries for all other root domains are forwarded to host3. ICP queries are not sent to a neighbor if it does not serve the requested URL host domain.
The default configuration is null, or all neighbors receive all queries. You can configure neighbors to process queries for one or more domains on the domain list.
ICP access control is configured on the ICP server and is used to verify whether proxies are allowed to send a request. You can set up a list of allowed clients (or clients that can send the ICP request). ICP access control is separate from Novell BorderManager 3.7 access control.