Consolidation of multiple HTTP access services under one IP address

The HTTP listener now supports configuring multiple HTTP services, each with its own service URL, to use the same IP address and port.

HCL SafeLinx support in the HTTP listener enables a connection request to be routed to a host that is named in the request header. After the listener reads the host token in the HTTP header of an inbound connection request, it assigns the session to the HTTP access service on that host. In this way, you can consolidate several HTTP access services, each supporting a separate application, and each with a unique DNS name, under a single external IP address. SafeLinx can then determine which service each request belongs to. Such address consolidation reduces firewall management and administrative costs as compared to using separate IP addresses for each DNS name.

For example, in an environment that supports IBM Connection, IBM iNotes, and IBM Sametime, you might create HTTP access services similar to the ones in the following table:

Table 1. HTTP access services for multiple applications
Application Service name External URL TCP listening port
Connections http-service0 https://connections.renovations.com 443
iNotes http-service1 https://inotes.renovations.com 443
Sametime http-service2 https://sametime.renovations.com 443

The URLs for all three applications resolve to the same external IP address. The HTTP listener on the SafeLinx server receives traffic for all three URLs on port 443. The listener then routes the traffic to the HTTP access service whose host name appears in the Host token of the HTTP header. For example, when a mobile device sends a request for the service URL https://sametime.renovations.com, the service reads the value of the Host token in the HTTP request header. After it detects the value sametime.renovations.com, traffic for the session is directed to http-service2.

To enable secure connections between client devices and the DNS names that share an address and port, install a multiple-host or domain-based certificate on the SafeLinx Server. Self-signed certificates are supported, but you must designate the certificate as the default certificate in the key database. For each service URL that is certified by an untrusted certificate, users receive a security warning that indicates that the identity of the site cannot be verified.

All HTTP access services that share an address and port must also share a common SSL/TLS configuration. SSL/TLS settings include cipher restrictions, key database and stash files, and any SSL/TLS related timers and buffer sizes. The SSL settings for the first HTTP access service that registers with the SafeLinx Server are applied to all of the other services that share the address and port.