Requirements and limitations of Sametime reverse proxy support

Reverse proxy server requirements

This section lists the requirements and issues that are specific to the reverse proxy server.

• URL specification requirement (affinity-id requirement) - Only reverse proxy servers that use the following URL specification to access protected internal servers can be used with Sametime: Http[s]://hostname:port/affinity-id/

  The "affinity-id" is an administrator-defined alias for an internal Sametime server. This affinity-id must be present in the URLs sent from web browsers to the reverse proxy server to enable web browser users to access the Sametime server through the reverse proxy. For detailed information on this mandatory requirement of the reverse proxy server, see Configuring mapping rules on a reverse proxy server.

• Multiple reverse proxy servers must use the same DNS name and mapping configurations - If you have deployed multiple reverse proxy servers in your network environment, and you expect users to access your Sametime server(s) through multiple reverse proxy servers, each of the reverse proxy servers must have the same DNS name and the same mapping configurations as noted:
  • DNS name - All reverse proxy servers must use the same DNS name. For example, if one reverse proxy server is named reverseproxy.example.com all other reverse proxy servers must be named reverseproxy.example.com. If the reverse proxy servers have different DNS names, the Sametime clients will be unable to maintain communications with a Sametime server deployed behind the reverse proxy servers.
    Note: If a network environment includes multiple reverse proxy servers that have the same DNS names, a connection dispatching device (such as an IBM Load Balancer) is usually used to distribute Connections from web browsers to the multiple reverse proxy servers. These devices are frequently used to load balance Connections to multiple computers.
  • Mapping configurations - Each reverse proxy server must use identical mapping rules and configurations to govern the translation of URLs sent by web browsers to the reverse proxy server for the purpose of accessing an internal Sametime server. If the translation of these URLs to the URLs of the internal Sametime servers does not occur in exactly the same way on each of the reverse proxy servers, the Sametime clients will be unable to maintain communications with a Sametime server deployed behind the reverse proxy server.
    Note: Each Sametime server must be represented by the same "affinity-id" in the mapping rules on each of the reverse proxy servers.

    For more information about the affinity-id and mapping rules, see Configuring mapping rules on a reverse proxy server.

• The reverse proxy server must use cookies for authentication - When an user uses a web browser to access and authenticate with the reverse proxy server, the reverse proxy server must send an authentication cookie to the web browser. All subsequent HTTP requests from a Sametime client will then pick up this cookie and use it for automatic authentication with the reverse proxy server.

  Reverse proxy servers that rewrite URLs for authentication purposes are not supported. Some reverse proxy servers append authentication and session information to the end of URLs embedded in HTML that passes through the proxy back to the client. The client will include this appended data on subsequent requests to the reverse proxy server. When the reverse proxy server receives these subsequent requests from the client, the reverse proxy server strips the authentication data and rewrites the URL to accomplish the internal routing of requests. A Sametime server cannot operate behind a reverse proxy server that handles authentication data in this way.

• A lengthy timeout value should be specified for the authentication cookies - The administrator should specify a lengthy timeout value for authentication cookies generated by the reverse proxy server.

  If the authentication cookie expires when the user is attending a meeting, the user is disconnected from the meeting. To re-enter the meeting, the user must go through the inconvenient process of reconnecting to the reverse proxy, reauthenticating with the reverse proxy, and waiting for the Java™ applets to be reloaded to the web browser.

  Setting a lengthy timeout value for authentication cookies can prevent unexpected user disconnections due to an authentication cookie expiration. Generally, the authentication cookie should be valid for the entire length of the longest meetings that are routinely conducted on the Sametime server deployed behind the reverse proxy server.

Sametime client limitations and JVM requirements

The following Sametime clients can communicate with Sametime servers through a reverse proxy server:

• Sametime Meeting Room client
• Sametime Recorded Meeting client
• Sametime Connect for the desktop (the Microsoft™ Windows™ version of Sametime Connect)

On IBM AIX® servers, the Meeting start-up log contains the Sametime server name when the Sametime server is configured behind a proxy server.

The Sametime Meeting Room client and the Sametime Recorded Meeting client can communicate with a Sametime server through a reverse proxy server when running with the following Web browsers and Java Virtual Machines (JVMs):

• A Microsoft Internet Explorer 6 browser that operates with the Microsoft native VM or the Oracle JVM 1.4.2 (and associated Java Plug-in).
• A Netscape 7 browser that operates with the Sun Microsystems JVM 1.4.2 (and associated Java Plug-in).

Secure Sockets Layer (SSL) issues and requirements

Note the following about SSL and Sametime in a reverse proxy environment:

• Secure Sockets Layer (SSL) can be used to encrypt data transmitted between the Sametime clients and the reverse proxy server.
• SSL cannot be used to encrypt data transmitted between the Sametime servers and the reverse proxy server.

If SSL is used to encrypt data transmitted between web browsers and the reverse proxy server, the administrator must perform the mapping configurations on the Sametime server necessary to map the HTTPS data received from the web browser to the HTTP required by the Sametime server.

The reverse proxy must also be configured to translate the HTTP data received from the Sametime server to the HTTPS data required by the client.

When a reverse proxy server is configured to support SSL, the reverse proxy server sends an SSL server certificate to the web browser during the SSL connection handshake. The Java 1.4.2 Plug-in used by the web browser must have access to a Signer certificate that is signed by the same Certificate Authority (CA) as the server certificate that is sent by the reverse proxy.

By default, the Java Plug-in has access to several different Signer certificates that can be used for this purpose. To view the Signer certificates that are available to the Java Plug-in 1.4.2, use the Java Plug-in Control Panel as described in Viewing the Signer certificates.

Client certificate authentication issues

If the reverse proxy server is configured to require client certificate authentication, the client certificate for an individual user must be imported into the Java Plug-in 1.4.2 Control Panel on that user's computer as described in Importing the client certificate.