This article is intended for IBM Notes Traveler customers who want secure, remote access to Traveler servers from supported devices that require access outside the bounds of their corporate intranet. You can accomplish this in two ways with IBM Mobile Connect (IMC).

NOTE: Traveler is installed as a separate application and operates as a server task on an IBM Domino server.

IMC provides a full client/server-based virtual private network (VPN) solution when installed on various supported user platforms. For HTTP-based applications such as Lotus iNotes, IMC also provides an option that does not require any additional software on a user's device. Instead, it provides secure authentication through a browser-based logon (Figure 1).

Why IBM Mobile Connect?

Figure 1: How the IMC option (HTTP access) works with Traveler


IMC provides a Federal Information Processing Standards (FIPS) 140-2 certified platform containing the latest secure sockets layer (SSL) / transport-level security (TLS) ciphers and industry-standard authentication mechanisms. IMC's HTTP Access Services use the same strong authentication and encryption algorithms as the full VPN client. HTTP Access Services can be configured to run simultaneously with full VPN sessions, providing a multifunction remote-access solution with a small footprint, allowing IT administrators to control the breadth of access per user.

The IMC management console, Gatekeeper, provides access to all configuration options and full control over ciphers, authentication methods, security restrictions, and enterprise destinations.

How does it work?

IMC's HTTP secures communication by forcing remote HTTP-based applications to connect using industry-standard SSL/TLS technology (SSL V3 / TLS 1.0,1.1,1.2) . SSL/TLS ciphers are configurable and can be restricted to FIPS 140-2 certified algorithms. Two-way certificate validation is also available to add an additional layer of trust to the session.

After secure communications are established, the IMC's Connection Manager sends a form-based or HTTP-401-based challenge to the remote application, prompting for user credentials. Credential information is x-www-url-encoded and sent over the secure connection using an HTTP POST operation. The HTTP Access Services decodes the information and validates it using a configurable authentication method.

Upon successful validation, the HTTP Access Service builds a token and sends it to the remote application using the HTTP set-cookie operational model. The cookie contains a IMC-specific encrypted token and has the secure and session bits turned on. The remote client is then expected to include the cookie containing the token in all future connect requests.

Now that the token is present in the HTTP flows, the HTTP Access Service opens a connection to an enterprise host and relays traffic back and forth, similar to an SSL/TLS gateway.

What it's not
IMC's clientless support is not an HTTP proxy. It does not cache any content or store any information contained in the body of the HTTP data flow. It is not an optimizer, compressor, or token reducer, and it is not able to flush a browser's cache. Because a secure session cookie is used, users must be sure to exit the browser session when they finish with an application session.

Architecture of IMC and Traveler
IMC uses HTTP Access Services to provide an SSL/TLS gateway function for HTTP communications from any HTTP version 1.1 client data stream such as a web browser. The connection provides access to web-based services and content without requiring the presence of a VPN client. The session is secured by use of SSL/TLS and can be restricted to permit connections only from specified hosts or address ranges.

The HTTP Access Services is a subsystem within IMC that is responsible for applying set configuration options to all connection requests and data traffic. This subsystem is responsible for enforcing security, validating access, generating audit information, and relaying traffic to the intended enterprise-located servers.

SSL/TLS
The Connection Manager's HTTP Access Services use SSL or TLS when communicating with the browser or client application. Version 3 of the SSL protocol are supported as are Versions 1.0, 1.1, and 1.2 for the TLS protocol. The following algorithms are supported:

- Public key algorithms
RSA (1024-, 768-, or 512-bit keys)
- Symmetric key algorithms
DES (56-bit key)
Triple DES (168-bit key)
RC4 (40-, 56-, or 128-bit keys)
- Message authentication codes
SHA-1
MD5

X.509 certificates can provide authentication for the SSL/TLS communications. These certificates along with root certificates to validate the other party's certificate are stored in a key database that is installed with Connection Manager. The Connection Manager administrator can configure the source of this database using the Gatekeeper administration console. The administrator can also configure the desired root certificates and client-side certificates using the administration interface of the SSL toolkit, IBM Key Management.

IMC supports restricting the SSL/TLS ciphers to those that are FIPS 140-2 approved and supports denying connection requests that support only SSL/TLS version 2 ciphers.

Authentication

The HTTP Access Services authenticate each secure HTTP connection, checking the data stream for valid user credentials. If none exists, a configurable form-based challenge or HTTP 401 Basic challenge is issued to prompt for a valid user ID and password. This function uses authentication methods and algorithms available to all components of IMC.

Authentication methods are resource containers defining how IMC challenges and validates remote user credentials. IMC supports methods for validating credentials with the following:

LDAP V3-compliant directory servers
RADIUS protocol servers
RSA Secure ID including next-token support
X.509 certificate exchange
IMC system user accounts
For more information on authentication methods, refer to the IBM Mobile Connect Wiki.
Single Sign-On (SSO)

HTTP Access Services can enable SSO through LTPA. LTPA provides a mechanism for storing user authentication information in a token that is generated when users are successfully authenticated with Connection Manager. The token is encrypted and signed by use of a password and a public/private key pair stored in an HTTP cookie and is included in all requests for the configured SSO domain. IMC supports 2 LTPA token types. LTPA and LTPAToken2.

The LTPA keys are shared with other LTPA-enabled servers within the same domain so the servers can validate the token and authenticate user requests instead of challenging the user. LTPA tokens include a configurable expiration timestamp so that after the token expires, a new authentication challenge is issued.

The LTPA token is used in place of the IMC-specific token and is sent to the HTTP client application in the form of an HTTP cookie using the set-cookie directive. HTTP clients include this token in all future HTTP requests.

HTTP Access Services Object

The HTTP Access Services resource contains information that tells IMC how to authenticate users and where to relay traffic to the back-end server. Each HTTP Access Services resource can send traffic to a single or to multiple applications.

There are several ways to configure access to multiple backend application servers:

1. Use with Notes Traveler. IMC is tightly integrated with IBM Notes Traveler, allowing a single HTTP Access Services definition to connect with a stand alone Traveler server, several stand alone servers or High Availability Traveler Pools. IMC also can act as a load balancer in front of one or many Traveler pools. [See later section - IMC with Traveler HA Pools]

2. A single HTTP application service can distribute and / or map HTTP transactions to multiple internal application servers. The feature includes a configurable distribution algorithm allowing for Round Robin, Balanced, and Hot Standby architectures.

3. Use multiple Internet protocol addresses. The HTTP Access Services configuration includes the ability to bind the service to a specific IP address. This way, there can be multiple HTTP Access Services resources listening on the same set of ports. This option is necessary for applications that expect to use standard HTTP ports 80 and 443. To the user, the URL simply looks like different host names (https://notestraveler1.example.com or https://notestraveler2.example.com).

4. Assign different listening ports to each HTTP Access Services resource. Since each resource can be configured to send traffic to a different back-end server or proxy, configure each service to listen on a different port. If you use this configuration, your users must know the port number and add it to the URL request (https://traveler.example.com:12345).

5. Use a transcoding reverse proxy. Allows a reverse proxy to route traffic to the appropriate destination based on information contained in the target URL.

Configurable HTTP 401-based challenge

IMC allows for two credential challenge methods: a form-based challenge and an HTTP 401-based challenge. Many devices used to access Traveler are not capable of supporting the IMC form-based challenge. Instead, the HTTP Access Service must be configured to use an HTTP 401 challenge.

IMC generates the HTTP 401 challenge after analyzing tokens in the HTTP header, to determine browser type and preferred locale (see Figure 2 below). The template files used for this form are installed with the product in locale-specific subdirectories. These templates are designed to be customizable, provided that the basic attribute structure and function are not altered. The shipped files are in [Windows] C:\Program Files\IBM\Connection Manager\http\ [Linux/AIX] \opt\ibm\ConnectionManager\http\ . When modifying these templates for your environment place the customized files into Windows] C:\Program Files\IBM\Connection Manager\http\custom\ [Linux/AIX] \opt\ibm\ConnectionManager\http\custom .

Figure 2. HTTP 401-based challenge screen


When you enter a user ID and password and click OK, the browser generates a URL-encoded POST operation containing the entered fields along with hidden fields containing information about the session.

It's possible for HTTP-based applications to answer the challenge without displaying the page to the user. You can uniquely identify the IMC challenge by querying the server token in the HTTP header.

Configuration

Enabling access to Traveler using HTTP Access Services requires architecture decisions and configuration steps for both components. This section describes options and requirements for each component.

IMC

If you want an encrypted pipe between the Traveler and IMC servers you must check the box on the Server tab of the HTTP Access Service to 'Accept untrusted certificates from internal servers' and also specify the use of the HTTPS protocol in the Application Server URL field.

Configuring IMC also involves setting up authentication methods and defining one or more instances of the HTTP Access Service resource. This section includes screen captures taken from the IMC management console, Gatekeeper.

Let’s consider sample architecture that configures a single HTTP Access Service configured to authenticate users against an LDAP directory server and then relay authenticated traffic to IBM Notes Traveler. The steps assume that the IMC Gatekeeper management interface is being used.

Create a directory server resource as follows:
1. Right-click a top-level folder or create a new folder to contain configuration information --> select Add Resource --> Directory server.

Figure 4. Add a Directory Server window

2. In the Add a Directory Server window (Figure 4), enter a "Common name" (free-form text describing the resource).

3. Enter a "Host name or IP address of service" (the directory server).

4. Enter the "Base distinguished name (DN)" and click Next. This is the starting point in the directory tree for resolving user accounts. Note** - This field is not always required for successful authentication by all LDAP servers.

5. On the next screen (Figure 5), enter the "Port number of service".

Figure 5 – Add a Directory Server wizard

6. If anonymous searches are not allowed, enter an "Administrator's distinguished name
(DN)" and password.

7. If the directory server requires a secure connection, enable the "Use secure connection" option. Enter a key database and stash file. IMC is shipped with several root signer certificates. You must import any personal certificates / and root signer certificates into the configured key database file.

8. Click Next. select a Primary OU, and click Finish


Authentication profile resource

The next step is to define an authentication profile that uses the directory server resource from the previous step. An authentication profile is a container defining how the HTTP Access Service challenges for and validates user credentials.
IMC supports LDAP, RADIUS/RSA Secure ID, RADIUS with an LDAP Lookup, two-way certificate validation, and system-specific authentication methods. This example uses LDAP authentication against an IBM Tivoli Directory server:

1. Right-click the system container again, this time selecting Add Resource --> Authentication Profile --> LDAP-bind Authentication.

2. In the Add a New Authentication Profile window (Figure 6), enter a "Common name" and optional "Description" (free-form text describing the profile).

Figure 6. Add a New Authentication Profile window


3. Select a "Password policy". The policy is used to set rules for system passwords and to determine the number of failed log-in attempts before the account is locked. To View/Edit a password policy, refer to Default Resources --> Wireless Password Policy container.

4. Optionally, select a "Backup authentication profile" to be used if this profile fails to connect to external servers and click Next.

5. In the next window (Figure 7), select the Directory Server defined earlier.

Figure 7. Add a New Authentication Profile window



6. The "User key field" is the attribute that IMC uses to search the directory server for the user ID provided by the credential challenge. It defaults to mail and can be set to any attribute that is part of the user record in LDAP. Beginning with IMC 6.1.5 this field can chain together multiple user key fields to provide the best chance at success to authenticate incoming user requests. For example you can code the values mail,uid,cn together or some combination. You would not need to use all three if not necessary. IMC will build a single query to the LDAP server where it would first query on the mail field, if unsuccessful, LDAP would apply the supplied credentials as a 'uid', and, if necessary, a final query using the supplied login name as a cn (Common Name) in an attempt to match on an attribute in the LDAP Servers' user record and validate the user login credentials. This is done in a single query to the LDAP server.

7. Optionally enter "Additional search criteria" (such as group information or employee type) if you want to restrict access to certain groups or types of employees. This field requires X.500 notation, for example, (&(employeeType=active)(group=remoteAccess)).

8. Set the "Maximum number of processing threads". This specifies the maximum number of threads to process authentication transactions. Please note that each thread maintains a persistent connection with the DSS (LDAP/RADIUS) for performing search operations. On multiprocessor machines you can see increased performance by using multiple threads. For example you should allocate one thread for every 25 clients that log in or log out per second up to 100 clients (or 4 threads). For HTTP Access Services the default value is 1 and the valid range is 1 to 10.

9. In the next window (Figure 8), if you want single sign-on (SSO), select the "Enable LTPA" option. The steps necessary to complete the configuration for SSO are detailed later in this article. This setting can be left unchecked for now. Click Next.



Figure 8. Add a New Authentication Profile window

10. In the next window, select the Primary OU and click Finish.

Additional configuration options can be found on the Properties panel after the resource is created. More information on these options can be found in the System's administrator guide and by viewing the properties panel and clicking inside a selected field then clicking the TIPS button in the lower right corner for a complete explanation.

HTTP Access Service resources

Now we must create an HTTP Access Service resource. HTTP Access Services are designed to relay authenticated traffic to multiple or single backend application servers or proxies.
HTTP Access Services require public certificates to secure communications. IMC provides a utility for working with a key database, generating a Certificate Request Message (CRM) that is used in requesting a certificate for a given machine name and generating self-signed certificates. This utility, IBM Key Management (Windows) is located in the IBM Mobile Connect Program Group, or wg_ikeyman (UNIX), is located in the bin sub-directory in the Install directory.

1. To add an HTTP access service resource, right-click the Connection Manager resource and select Add --> HTTP Access Service (Figure 9).
Figure 9. Adding an HTTP access service

* "Service URL": Enter the text string matching the URL contained in the certificate used to secure connections. This is the URL end users will access your configured applications through.
* "TCP port to listen on": Enter the TCP port that the service listens on for access requests (default is SSL default of 443).
* "Description": Enter free-form text description of the service.
* "Current state": Select the state of the service. Active means the Connection Manager activates the service; Defined is equivalent to down in which case the Connection Manager does not start the service making it unreachable.
2. Click Next (Figure 10).
Figure 10. Specifying Application URL's and Authentication Profiles



* "Application server URL": Enter the protocol (HTTP/HTTPS), host name or IP address of the Traveler server to forward authenticated traffic. Here you may also provide multiple IBM Traveler Server URL's if you have several stand alone servers. You would then choose the 'Balanced' scheduling algorithm on the Server Tab of the HTTP Access Service (post create wizard) which will allow IMC to balance the Traveler traffic between the Traveler server nodes. [Please see the section IMC with Traveler HA Pools for further information]
* "Authentication Profile": Enter the authentication method to use to validate remote user credentials.
* "SSO Cookie Domain": If this option is set, the value overrides what is set in the authentication method. If not set, the authentication method properties are used. This value tells a browser when to include the session cookie and is normally set to the domain name in the Service URL, or the fully qualified name set in that same field. Setting the value here in the HTTP Access Service is a BEST Practice.
3. Click Next (Figure 11).
Figure 11. Specifying the maximum number of threads and idle time


* "Maximum number of processing threads": Enter the number of simultaneous processing threads (considerations are the number of simultaneous sessions and number of processors). Recommended value for use with Traveler 1 thread for every 150 - 200 sessions. You also want to Enable Traveler integration on the “IBM Mobility” tab in Gatekeeper using the HTTP Access Service properties. See the section on Sizing / Configuring the HTTP Access Service for use with Traveler for more details and the IMC Technote - General Sizing Guide for IMC's HTTP Access Services
* "Maximum idle time": Enter the maximum time that a session can be idle before the Connection Manager clears the session's authentication token, forcing the client to re-authorize.
* “Redirect HTTP ports”: A comma delimited list of ports from which HTTP traffic is accepted and is redirected into HTTPS port configured as the TCP Port to listen on. This allows an end user to use the HTTP protocol and have IMC redirect it into HTTPS avoiding an error back to the device for omitting the correct protocol on the request.
* "Bind port to a specific address": Configures the service to be bound to a specific Internet address. By doing this binding, multiple HTTP Access Services resources can be configured to listen on the same ports, thus allowing for different back end servers to be used based on the Internet address of the initial request. Multiple addresses can be assigned to a single network interface using IP aliasing.
* "Address to bind to": Enter the Internet address or host name to bind the service to.
* Click Finish to finalize the creation of the HTTP Access Service. More configuration is available post creation with the Properties for the HTTP Service.

Secure the HTTP access service with a certificate

Secure Sockets Layer (SSL) / Transport Layer Security (TLS) is used to secure communications over HTTP Access Services. This requires that a certificate for the externally visible host name be stored in a Cryptographic Message Syntax (CMS) key database file.
IMC ships with a utility, Key Management (from the IMC Program Group in Windows) or the wg_ikeyman command (UNIX), for managing key database files. The utility generates self-signed certificates and CRMs to obtain a public certificate from a certificate authority.

Self-signed certificates can work but require the user to accept and import the certificate when first connecting to the HTTP access service. For this reason, valid public certificates are recommended. To generate and use a self-signed certificate, follow the steps below:

1. Either work with a new key database file or use one of the key database files installed by IMC:
* To use an existing file, select Key Database File --> Open. Set the Key database type to CMS, use Browse to go to the IMC Install directory, and select the http.trusted.kdb file.
* If creating a new key database file, select the "Stash the password to a file" option.
2. Enter the password (default is "trusted").

3. To create a self-signed certificate, select Create --> New Self-Signed Certificate. At a minimum, enter a key label and a common name which should match the fully qualified external host name of the IMC server.

4. Click OK and exit the Key Management application. For instructions on using the IBM Key Management to create a CRM and managing public certificates see this IMC Technote.

5. Using Gatekeeper, bring up the HTTP Access Service Properties panel, select the Service tab, and verify that the file name of the key database and the file name of the stash password are set correctly. The following screen shot shows just the file names which indicates the files are located in the default IMC install directory, but use of the full path notation can prevent certificate related problems later.


6. Optionally, select the SSL Ciphers tab and select the appropriate ciphers.
Tip** - The use of third party tools like sslscan or openssl are useful in determining what ciphers are preferred, or supported by Application Servers.
Click OK.


Single Sign-On (SSO)

Enabling SSO for IMC and Traveler requires that a common key file be generated by IMC and imported by the Traveler server.

Configure/Enable SSO on IMC

You can enable SSO for IMC by using the Gatekeeper, navigating to the authentication method used by the HTTP access service, and modifying the LTPA/SSO tab on the Properties panel:



1. Check Enable LTPA.
2. Token Type - Beginning with IMC 6.1.5.1 select either LTPA or LTPAToken2 for the token type. With the LTPAToken2 IMC supports using 128 bit AES/CBC to encrypt the token.

3. Enter the LTPA token realm/domain (The token REALM is typically set to the fully qualified hostname of the LDAP server that handles authentication. It is stating that the servers trust credentials that have been validated for that domain.)

4. In the "LTPA token user identification", use the distinguished name if authenticating against Domino LDAP and the UID for RADIUS, Secure ID, or System Authentication from IMC. Also, the UID may work to authenticate the user account if IBM Domino's Person Document contains the UID field. The 'Other' option is new in IMC 6.1.5.1 and is an alternate user field from the User Record looked up by IMC. This configurable option allows an administrator to specify any field within in a user's LDAP record to be used as the user string set in the LTPA token. An example of this would be using the NotesID attribute when the LDAP server contains this attribute and the application is Traveler or iNotes. This eliminates the need to to have Domino Directory Assistance map the LDAP Server 'DN' to something Domino understands like the NotesID.

5. The BEST Practice is to check "Enable SSO" but set the SSO Cookie Domain in the HTTP Access Service. This value is used to inform browsers when to include the LTPA token as a cookie in the HTTP header flows. For HTTP Access Services, set this value to the fully qualified external host name used to access the HTTP Access Service from a browser/client (Service URL field on HTTP Access Service). If more than one hostname is used, it can be set to the external domain. This value can also be set in either the Authentication Profile or the HTTP Access service definition, but the HTTP Access Service value will override the setting in the Authentication profile.

6. Check "Enable SSO over SSL connections only". The LTPA token is sensitive information and should be included by the browser only when communicating with IMC over a secure connection.

7. In the "LTPA key action" section, select "Generate new keys" and enter a 6-32 character password. Remember and record this password since it is required to import the key file on the Domino servers. You may need it in the future......

8. Click Apply to generate cryptographic keys that are used to generate the LTPA tokens. These keys are stored internally by IMC and must now be exported. Use a full path for the name of the key file.
Export LTPA keys to a file
The previous step generates cryptographic keys and a password used in LTPA token generation. For SSO to work properly, this data must be exported in a format acceptable to other application servers that grant access based on this token.

To have IMC export the keys and configuration data, follow these steps (refer to screen shot below which is a continuation of Figure 12)


1. In the "LTPA key action" section, select "Export to keyfile" and enter a file name with the full path to the file.

2. Click Apply, to export the file. The key file is a user-readable ASCII file that can be transferred to the Traveler server.
* In Windows, the LTPA key file is located in the \ProgramFiles\IBM\ConnectionManager\logs directory unless a full path is specified.
* In UNIX, the LTPA key file is in the root “/” file system, again, unless a full path is utilized in the LTPA export keyfile name field.

Note** When using a Gatekeeper remotely to export the key file, the file will still be stored in the Connection Manager computer, not the computer running the Gatekeeper.

Import LTPA key file on IBM Notes Traveler servers

For SSO to function properly, all servers must agree on cryptographic keys, user information, and miscellaneous other configuration data. Once IMC generates the key file, it must be imported by the Domino Server(s) running IBM Notes Traveler.

1. In IBM Domino Administrator, from the File menu, choose Open Server --> enter the name of the server on which to work. On the Configuration tab, expand Server and select All Server Documents in the left navigation pane.

2. In the Server Document, from the Create menu, choose Web SSO Configuration.

3. In the Web SSO Configuration window (Figure 13), enter a unique Configuration Name, for example, LtpaTokenIMC, and the DNS Domain that houses the application servers, for example, .xyz.com.

4. In the Participating Servers section, add the name of the Domino/Traveler server participating in the SSO configuration.
Figure 13. Web SSO Configuration window

5. In the top menu bar, click Keys and select Import WebSphere LTPA Keys.

6. In the Enter Import File Name prompt (Figure 14), enter the location of the key file obtained from the Export Key file step above and click OK.
Figure 14. Enter Import File Name prompt

7. Enter the key file password you created during key generation on IMC, and click OK to display the LTPA token configuration information. Click Save & Close.

8. Return to the Configuration tab in the Server document, select All Server Documents, and select the server into which you want to import the key file.

9. In the Server Document, go to Internet Protocols tab --> Domino Web Engine tab
Figure 15. Domino Server document

10. Set "Session authentication" to Multiple Servers (SSO) and set "Web SSO Configuration" to the Configuration Name from Step 3 above.

11. Save and close the document. Restart the HTTP Tasks on the Traveler server.


Setting the Server URL field for Traveler in IBM Mobile Connect

There are several methods for configuring IBM Mobile Connect with IBM Notes Traveler (Stand Alone - Single Server, Stand Alone multiple servers, or High Availability Pool or Pools.

• In this article we have seen an example of configuring a single URL for use with a single IBM Traveler server with the format like:

TRAVELER http://mytravelerserver.domain.com

The TRAVELER keyword associates URLs with the integrated IBM Traveler application and IMC will match identifiable Traveler traffic with the appropriate server(s) applying distribution rules where applicable.
• Another environment may be to use several stand alone Traveler servers with IBM Mobile Connect. IMC can act as a load balancer in front of application servers such as Traveler. The way you might typically see this configured can be seen in the following screen shot:


• Notice here we have 3 separate Traveler URL's and we also have selected the Balanced scheduling algorithm to balance the incoming Traveler traffic.
• IMC will maintain a session affinity with the Traveler server for end users to avoid bouncing between servers.
• The TRAVELER keyword is not required here since all the traffic is for Traveler.
• These functions represent some of the new (6.1.5.1) Load Balancing function of IMC which is exploited further with Traveler HA Pools.

IMC with Traveler HA Pools

• Beginning with IMC 6.1.5.1 there is a new configurable object to create a Traveler HA Pool or Pools. A "pool" represents a single Traveler HA cluster made up of one or more server nodes. Nodes within the pool are treated as equal peers. When assigning new traveler sessions, IMC, if applicable, will balance the users amongst all the pools. To create the Traveler Application Pool object right click on the Mobile Connect container in Gatekeeper and select Add Resource and then select Application Server Pool


• Shown here is the first panel of the Application Server Pool wizard:

• Provide a Common name and Description for the Pool.
• Next add all of the Traveler server URL's which are to be members of the pool.
• Maximum Users: Maximum number of sessions that will be assigned to this pool. Once met, IMC will no longer include this pool in new session assignment.
• Minimum Users: Number of sessions after which IMC will start including other pools in the distribution. If the total users are <= this setting, all the users will go to only one pool.
• Add the Application Server Pool to the configuration at the level which makes sense for your organizational environment.


• After the Traveler application pool object has been created, go back to the existing HTTP Access Service which you need to configure the Traveler HA Pool to. Edit the Server Tab.



• Here is where you would now associate the newly created Traveler HA Pool object with the HTTP Access Service.
• Notice there are no Traveler server URL's shown in the Application Server URL field, but rather you check the box for the Traveler pool to use for this service. Multiple Pools may be defined and selected.
• The Balanced Scheduling Algorithm must be used with an HA Traveler pool.
• Traveler Integration must be turned on / checked on the IBM Mobility Tab of the HTTP Access Service.

Usage Notes on IMC HTTP Access Service functions with IBM Notes Traveler
• Once a user is assigned to a server pool, the information will be stored in the user's IMC record along with the specific server from the pool. Both settings are surfaced in Gatekeeper on the Properties panel ibm-wluser objects. These values can be modified in Gatekeeper if specific assignment is required.


• Starting with Traveler V9, there exists a configurable option in Traveler to include a token in the http header of all responses that indicates which Traveler node in a HA cluster owns the "Master Record" for a given user.
Function in IMC will sniff response headers for this token and adjust the Active application server URL setting in IMC's version of the user record to keep it in sync with where the Traveler cluster is managing the session. This function has 2 benefits, 1) if the cluster moves a session for balancing or maintenance reasons, IMC will be able to detect and adjust so future connections go to the correct server. 2) If a load balancer is used between IMC and Traveler (usually not needed), IMC will know which node is actually processing the session be able to bypass the load balancer causing less churn for the cluster.
• To enable this function in the Traveler cluster (9.0 + only), issue the following command on the Traveler server console:

set config NTS_HTTP_HEADERS_RESPONSE_X_IBM_TRAVELER_HOST=host


Sizing / Configuring the HTTP Access Service for use with Traveler

• Minimum hardware requirement for the IMC Server would be a Quad Core processor with 8GB RAM running on a supported 64-bit OS. Please see System Requirements for answers to other related hardware questions.
• In General for Traveler you can expect to support 1000 – 1500 concurrent sessions per CPU core. For this number of sessions you will need one processing thread for every 200 sessions.
• To use our 5 Traveler Server example from above where each Traveler server has roughly 2000 registered devices the pool would have 10000 devices.
• To properly support this Traveler pool the IMC Server would need to have a minimum of 10 processor cores and likely between 8 – 12 GB RAM for this example.
• On the General Tab of the HTTP Access Service you would edit the Maximum Number of Processing Threads. This value represents the maximum number of threads to process actual transactions between IMC and Traveler. To follow our example here you would want 50 processing threads.


• If the Traveler Pool were to add another server then it may be necessary (depending on number of concurrent sessions) to increase the number of processing threads as well as the Maximum Size of Thread Pool, also exposed on the General Tab. The default value is 50.
• The Maximum Size of Thread Pool also represents the incoming SSL connections from mobile devices to IMC as well as transactions from IMC to Traveler.
• **TIP** - A good method to check how many processing threads are being used by the HTTP Access Service is to briefly turn on STATUS level logging from the Gatekeeper. Right click the Connection Manager object, select Properties, then the Logging Tab in the right pane. Select STATUS, and allow it to run for a few minutes. Then turn back off, and examine the STATUS level entries of the wg.log file in C:\Program Files\IBM\Connection Manager\logs for Windows, or /var/adm for Linux/AIX.

• The log entries would look like this:
[STATUS]http-service0-ThreadPool: pooling 30 threads, active 4, idle 26

Setting the External Server URL for IBM Notes Traveler

There are times when a device needs to connect to a link sent by the Traveler server. For example, downloading client files, web page URLs, and Apple encrypted mail retrieval. To make sure that the server sends an appropriate link that the device can use, you must first set the External Server URL field on the IBM® Traveler tab in the Server document. For guidance in setting this value please see the following article -
http://www-10.lotus.com/ldd/dominowiki.nsf/xpDocViewer.xsp?lookupName=Administering+IBM+Notes+Traveler+9.0.1#action=openDocument&res_title=Setting_the_external_server_URL_A901&content=pdcontent&sa=true