SteelHead™ Deployment Guide - Protocols : HTTP Optimization : HTTP Authentication Optimization
  
HTTP Authentication Optimization
RiOS v6.1 or later has specific HTTP authentication optimization for handling the various inefficient browser authentication behaviors. The HTTP authentication optimization attempts to modify the client-to-server behavior so that it maximizes the benefit of the HTTP optimization module.
RiOS v7.0 or later supports Kerberos as an authentication mechanism, in addition to the NTLM-based authentication supported by previous RiOS versions. Kerberos authentication support is beneficial for access to SharePoint, Exchange, IIS, and other Microsoft applications that use Active Directory and Kerberos for authentication. With this feature, your system is capable of prefetching resources when the Web server employs per-request Kerberos authentication.
Prior to RiOS v7.0, servers that required Kerberos authentication did not take advantage of the parse-and-prefetch optimization feature. RiOS v7.0 or later can decrypt the Kerberos service ticket and generate session keys to authenticate, on a per-request basis, with the Web server. For more information about Kerberos, see Kerberos.
The following is a list of HTTP authentication optimization methods:
  • Reuse auth - URL learning and parse-and-prefetch sends a particular request from the browser and triggers the HTTP optimization module to prefetch the objects of a Web page. The browser typically opens parallel TCP connections to the server to download the objects (for details, see Multiple TCP Connections and Pipelining). If the Reuse Auth feature is not enabled, the HTTP optimization module does not distribute the objects to the client through an unauthenticated connection, even though it can already have the objects in its database. With reuse auth enabled, the HTTP optimization module requires that the session has already been authenticated and that it is safe (in other words, without violating any permissions) to deliver the prefetched objects to client regardless of whether the connection is authenticated or not. Reuse Auth is as if the client only used a single connection to download all the objects in serial.
  • Force NTLM - The default authentication behavior on Microsoft's IIS server is per-request authentication for Kerberos and per-connection authentication for NTLM. Thus, the HTTP optimization module is configured to change the client-to-server negotiation so that the client chooses an authentication that maximizes the benefit of the HTTP optimization module. When enabled, Force NTLM removes the WWW-Authenticate: Negotiate line from the 401 Unauthorized message from the server. When the 401 Unauthorized message arrives at the client, the only authentication option available is NTLM. The client has no choice but to use NTLM for authentication.
    • Do not use this feature if Kerberos authentication is required.
  • Strip auth header - When you enable strip auth header, the HTTP optimization module detects an authentication request on an already authenticated connection. It removes the authentication header before sending the request to the server. Because the connection is already authenticated, the server delivers the object to the client without having to go through the entire authentication process again. If you require Kerberos authentication, do not use strip auth header.
    • Strip Auth Header specifically addresses the issue described in Connection Jumping.
  • Gratuitous 401 - You can use this feature with both per-request and per-connection authentication but it is most effective when used with per-request authentication. With per-request authentication, every request must be authenticated against the server before the server would serve the object to the client. Most browsers do not cache the server response requiring authentication, and this wastes one round-trip for every GET request. With gratuitous 401, the client-side SteelHead caches the server response. When the client sends the GET request without any authentication headers, it responds locally with a 401 unauthorized message and saves a round trip.
    • The HTTP optimization module does not participate in the actual authentication. The HTTP optimization module informs the client that the server requires authentication without requiring it to waste one round trip.
    To enable HTTP Kerberos authentication
    Install RiOS v7.0 or later on the client-side and server-side SteelHead.
    Join the server-side SteelHead to the active domain directory.
    Enable Kerberos key replication on the server-side SteelHead.
    On the HTTP page, select Enable Kerberos Authentication Support.
    Click Apply.