About Web proxy chaining

Web proxy chaining is useful in a number of scenarios. For example:

  • In large organizations you can route Web proxy traffic from internal Microsoft Forefront Threat Management Gateway computers to upstream servers protecting sections of your networks or at the edge of the organization.
  • Departmental Forefront TMG firewalls can forward Web proxy requests to an upstream Forefront TMG server configured with a single network adapter and acting as a Web proxy and caching server.
  • Branch offices running Forefront TMG can use Web chaining as a means of conditionally routing Web proxy requests based on destination. For example, an organization with headquarters in the United States sets up a branch office in the United Kingdom. The branch office Forefront TMG firewall is connected to an Internet service provider (ISP) in the United Kingdom. Web chaining rules can be configured at the branch office to direct requests for Internet hosts in the United Kingdom to the local ISP, and all other requests (for non-UK Web sites) are redirected to the Forefront TMG firewall at headquarters.

For information on configuring Web chaining rules, see Configuring Web proxy chaining

Web chaining and caching

When a client makes a request to a downstream server, the downstream server attempts to serve the requested object from its cache. If it cannot, the request is redirected in accordance with Web chaining rules, as follows:

  • An internal Forefront TMG client makes a Web request to the downstream Forefront TMG computer. This may be a Web proxy request from any type of Forefront TMG client.
  • Forefront TMG checks access rules to verify whether the request is allowed.
  • If a user request is allowed, the downstream Forefront TMG checks whether HTTP caching is enabled and checks cache configuration settings to verify whether the object should be fetched from the cache.
  • If an object cannot be retrieved from the cache, the downstream Forefront TMG computer checks Web chaining rules to determine how to forward the request.
  • If there is a Web chaining rule to redirect to an upstream server, the request is forwarded. For each new HTTP request, the Web chaining rules are processed in order. If the request matches the conditions specified by the first rule, the request is redirected. Otherwise, the next rule is processed. This continues until the last, default rule is processed. You cannot change the order of the default rule.
  • If the upstream server has caching enabled, it checks its cache to verify whether the requested object is available. If so, it is returned to the downstream server. The downstream server places the content in its cache (in accordance with cache configuration settings) and returns the content to the user. If a cached object cannot be found by the upstream server, the request is forwarded to the next upstream server in the chain or to the Internet. When an Internet server returns content to the upstream server, the upstream server caches the content in accordance with its cache configuration settings and then passes it to the downstream server.

You configure cache properties and rules on downstream and upstream servers to determine how chained requests are served from the cache. Hierarchal caching helps conserve bandwidth. For example:

  • Configure the upstream server to cache content. This has the effect of reducing Internet bandwidth, as chained requests can be served from the upstream cache.
  • Configure the downstream server to cache content. This reduces bandwidth on the link between the downstream and upstream servers.
  • Configure downstream and upstream servers to cache content. This reduces Internet bandwidth, while increasing the ability to make content available even if links are unavailable.

Authenticating chained requests

You can configure authentication mechanisms for Web chaining, in accordance with your deployment scenario. For example:

  • Handle authentication on the upstream proxy by delegating client credentials on the downstream server and creating a Web access policy on the upstream server.
  • Handle specific user access on the downstream proxy by configuring access rules requiring authentication on the downstream proxy. Specify a static account to be used to authenticate the downstream server to the upstream server. All user requests allowed and redirected in accordance with access rules and Web chaining rules on the downstream server are allowed on the upstream server, provided the downstream server authenticates successfully.

If the upstream server requires authentication (either because Require all users to authenticate is enabled on a network, or access rules require authentication), configure Web chaining rules on the downstream server as follows:

  • Enable delegation of credentials in the rule, so that the credentials of clients making requests using Basic authentication are passed (delegated) to the upstream server for authentication. If the downstream server does not require client authentication, client credentials are passed to the upstream server. If the downstream server requires client authentication, the credentials are first consumed by the downstream proxy and then passed to the upstream server. Basic authentication does not require the client to reauthenticate to the upstream server.
  • Create a secure account on the upstream server, and then specify the credentials for this account in the Web proxy chaining rule on the downstream server. If the upstream server is a domain member, use the format DomainName\UserName. The downstream server uses this account to authenticate to the upstream proxy using Basic or Integrated Windows authentication. Configure a user account that is not used for other purposes.
  • If the Web chaining rule is configured to use a static account and delegate client credentials, the static credentials are used.

SSL Authentication

You can configure a secure SSL channel between a downstream and upstream proxy. This is especially important when Basic authentication is used, as transactions are sent in clear text. To use a secure channel, the upstream network listening for Web proxy requests from the downstream server is enabled to listen for SSL requests. This setting is specified on the Web Proxy tab of the network properties. A valid server certificate must be installed on the upstream server. The downstream server must have a root certificate of the CA that issued the server certificate, so that it can validate the server certificate. The downstream server initiates an SSL connection to the upstream server.

If the upstream network is configured to require client certificate authentication for Web proxy requests, the downstream server must have a valid client certificate that can be used for authentication to the upstream server.