Virtual host junction

WebSEAL supports virtual hosting and, through virtual host junctions, can eliminate the limitations of URL filtering. The term virtual hosting refers to the practice of maintaining more than one server on one machine, as differentiated by their apparent hostnames. Virtual hosting allows you to run multiple Web services, each with a different host name and URL, that appear to be completely separate sites.

Virtual host junctions allow WebSEAL 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 located on junctioned servers or on the local machine. Access to resources using virtual hosting is possible because the HTTP 1.1 specification requires client browsers to include,

of the server where the requested resource is located. WebSEAL uses the value of the HTTP Host header, rather than the URL of the request, to select the appropriate virtual host junction for dispatching the request. If the HTTP Host header is present in the request and its value matches the host name of a configured virtual host junction, then the virtual host junction is used. Otherwise, a standard WebSEAL junction is used, based on the URL of the request.

In a case where there is no Host header in the HTTP request (such as in an HTTP 1.0 request), WebSEAL again uses a standard junction.

Using virtual host junctions, a user can access resources directly using the host name of the junctioned server (http://protected-server/resource), rather than indirectly using the host name of the WebSEAL server with 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 originally found 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 that 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 actually routed to WebSEAL.

This also has great value in the larger organizations that already have traditional Web address space. By using virtual host junctions you can preserver this Web address space from the user standpoint, just changing DNS mappings to point to WebSEAL instead of real Web Servers. For example, a company may have www.myhr.com for their HR system and www.mypayroll.com for their payroll system. Since these applications already exist and their Web addresses are known throughout the user community, application of the traditional WebSEAL junction method would not benefit the corporation. Instead, resolving

www.myhr.com and www.mypayroll.com to WebSEAL’s IP address and allowing it to decipher which server to direct traffic to would be the most beneficial.

4.6.1 Creating a remote type virtual host junction

Creating a virtual host junction is similar to creating a standard junction. A virtual host junction can be created using either WPM or the standard server task command in the pdadmin CLI. The following example specifies the syntax for the pdadmin command for creation of a virtual host junction (entered as one line):

pdadmin> server task instance_name-webseald-host_name virtualhost create options vhost-label

The virtual host label (vhost-label) is simply a name for the virtual host junction.

The junction label is used to indicate the junction in the display of the protected

object space (Web Portal Manager). Here is some highlights regarding virtual hosts labels:

򐂰 Virtual host junctions are by default always mounted at the root of the WebSEAL object space and are easily identified because they start with the

@ character followed by the host label defined during junction creation.

򐂰 You can refer to a junction in the pdadmin utility using this label.

򐂰 The virtual host junction label must be unique within each instance of WebSEAL.

򐂰 Because the label is used to represent virtual host junctions in the protected object space, the label name must not contain the forward slash character (/).

Common and required options specified for creation of virtual hosts are:

–t type Type of junction. It can be one of: tcp, ssl, tcpproxy, sslproxy.

–h host-name The DNS host name or IP address of the target back-end server. The same host name can be used for a TCP junction and an SSL junction. The port of each virtual host differentiates one from the other so that they are each considered unique.

–v vhost-name[:port] WebSEAL selects a virtual host junction to process a request if the request’s HTTP Host header matches the virtual host name and port number specified by the -v option. The -v option is also used to specify the value of the host header of the request sent to the back-end server.

–g vhost-label If both HTTP and HTTPS protocols need to be supported between the client and WebSEAL, then two junctions to the same virtual host (-h) are required, one for each protocol (-t). By default, each junction recognizes its own unique protected object space, even though the junctions (which are differentiated by protocol only) point to a single object space. The -g option causes a second additional junction to share the same protected object space as the initial junction. This single object space reference allows you to maintain a single access control list (ACL) on each protected object. This option is appropriate for junction pairs only (two junctions using complementary protocols).

The option does not support the association of more than two junctions. Use of this parameter is optional.

Additional junction options

Almost all junction functionality (SSO options, and so on) that is available for traditional junctions is also available for virtual host junctions. The only exceptions to this are the junction cookie options (-j , -J) and the cookie/path modification options (-I, -n). They are not available for virtual host junctions because they are not required. The problems that these options were introduced to solve are no longer an issue when using virtual host junctions.

4.6.2 Defining interfaces for virtual host junctions

The multiple interface capability is important when setting up certificate support (SSL) for multiple virtual host junctions. A digital certificate contains the name of the host being accessed. Therefore, it is necessary to have a unique certificate exchange for each virtual host configured for SSL. Browsers produce a warning message when there is a name mismatch between certificate and host.

A default network interface is defined as the combined set of values for a specific group of settings that include HTTP or HTTPS port setting, IP address, worker threads setting, and certificate handling setting. The single default interface for a WebSEAL instance is defined by the values for the following stanza entries in the WebSEAL configuration file:

[server]

http http-port https https-port worker-threads network-interface [ssl]

webseal-cert-keyfile-label [certificate]

accept-client-certs

WebSEAL can be configured to listen on multiple interfaces. To configure additional interfaces, you define each custom-named interface within the [interfaces] stanza of the WebSEAL configuration file. A custom interface specification uses the following format:

[interfaces]

interface-name = property=value[;property=value[;...]]

Example interface definition:

[interfaces]

support = https-port=444;certificate-label=WS6;

worker-threads=16;network-interface=9.0.0.8

This example (entered as one line) creates an interface named support with the following properties:

򐂰 Allows WebSEAL to listen for requests at IP address 9.0.0.8.

򐂰 Listens on HTTPS port 444.

򐂰 The HTTP port defaults to disabled.

򐂰 WebSEAL authenticates to SSL clients using a server-side certificate named WS6 stored in the WebSEAL key database file.

򐂰 The interface uses its own pool of 16 worker threads to service requests.

򐂰 The interface defaults to never requiring (prompting for) client-side certificates during authentication.