Virtual host junction solution

WebSEAL supports virtual hosting. Through virtual host junctions, it can eliminate the limitations of URL filtering.

WebSEAL can use virtual host junctions to communicate with local or remote virtual hosts. WebSEAL uses the HTTP Host header in client requests to direct those requests to the appropriate document spaces on junctioned servers or on the local computer.

A user can access resources directly with the host name of the junctioned server (http://protected-server/resource). The use can do this, rather than indirectly with the host name of the WebSEAL server and a potentially modified resource path (http://webseal/junction/resource). Direct access to the resource using the host name of the junctioned server does not require URL filtering.

Virtual host junctions preserve the content of response pages in the same form as the original content on the junctioned web servers. Clients can use the unmodified absolute and server relative URL links on these response pages to successfully locate the resources.

Configuration for virtual host junctions requires the external DNS maps all virtual host names to the IP address (or addresses) of the WebSEAL server. When the user makes a request to the host name of the junctioned server, the request is routed to WebSEAL.

The HTTP/1.1 specification requires that requests contain an HTTP Host header. WebSEAL uses the value of the Host header, rather than the URL of the request, to select the appropriate virtual host junction for dispatching the request.

WebSEAL chooses the appropriate virtual host junction as follows:

• If the Host header is in the request and its value matches the host name of a configured virtual host junction, WebSEAL uses the virtual host junction.

  We must include the port number in the Host header when the virtual host uses a non-standard port for the protocol. The standard port for TCP is 80 and the standard port for SSL is 443.

  The Host header that WebSEAL sends to the virtual host junction contains the value specified by -v when the virtual host junction was created.

• In all other cases, WebSEAL uses a standard junction that is based on the URL of the request. For example, WebSEAL uses a standard junction in the following situations:

  • If the value of the Host header does not match any virtual host junctions (-v vhost_name[:port]).

  • If there is no Host header, such as in an HTTP/1.0 request.

By default, virtual host junctions take precedence over standard junctions. We can use the match-vhj-first configuration entry in the [junction] stanza to reverse this behavior. If this configuration entry is no, WebSEAL searches for a standard junction matching the request. If no match is found, WebSEAL checks the Host header to determine whether a virtual host junction can handle the request.

If we set match-vhj-first to no in an environment that maintains sessions, we must set the shared-domain-cookie configuration entry to yes. By default, WebSEAL maintains a separate session cache for each virtual host junction and a separate session cache for all standard junctions. For session affinity, use the shared-domain-cookie parameter so that WebSEAL can use the same session, regardless of which junction services the request. We can also use the session-cookie-domain stanza to specify the domains that share session cookies. For information about these configuration entries, see the web reverse proxy Stanza Reference topics..

Unlike standard junctions, WebSEAL does not define virtual host junctions as a mount point in the document space. WebSEAL accesses virtual host resources by virtual host junction designations, which are always at the root of the document space of WebSEAL. These designations are called virtual host labels.

The junctioned server with the virtual host name in the HTTP Host header returns its own responses, which can contain server-relative or absolute URLs. WebSEAL returns these responses, unfiltered, directly to the client. Absolute URLs in the responses from junctioned servers that reference the server itself must use the virtual host name and not the server IP address. Clients can use the unmodified absolute and server relative URL links on these response pages to successfully locate the resources.

Other features of virtual host junctions:

• Support for both HTTP and HTTPS protocols. To support both protocols between the client and WebSEAL, we must use two virtual host junctions. Use a separate virtual host junction for each protocol.

  A virtual host junction responds only to a single protocol (port). The junctioned server must support both HTTP and HTTPS to create the two junctions with unique SSL and TCP ports on that server.

• WebSEAL can also provide multiple local virtual host junctions of its own to serve protected local content.
• Virtual host junctions share many configuration options with standard WebSEAL junctions. Virtual host junctions do not support several standard junction options. There are also several new options specific to virtual host junctions.
• Each WebSEAL instance can support multiple interfaces, ports, or both. With multiple interfaces and ports, we can configure an SSL certificate for each HTTPS interface and port on which listening occurs.

  If virtual host names resolve to different interfaces or ports that WebSEAL is listening on, then WebSEAL can present different certificates to the connecting clients.

Parent topic: Virtual Hosting