ShowTable of Contents
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 a Lotus 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).
Figure 1: How the IMC option (HTTP access) works with Traveler
Why IBM Mobile Connect?
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.
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
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.
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
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.
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 resource
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.
2. A single HTTP application service can distribute and / or map HTTP transactions to multiple internal application servers. The new feature includes a configurable distribution algorithm allowing for Round Robin, Balanced, and Hot Standby architectures.
3. 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
4. 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
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.
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.
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.
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 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, and to an IBM iNotes Redirector node. 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 (Figre 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".
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. If the directory server is using a self-signed certificate, you must import that certificate to the key database.
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, 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 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. 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. IMC will first query on the mail field, if unsuccessful, it will build a new query using the supplied login name 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.
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". Each active session is assigned to a thread for processing. The thread is responsible for all data exchange between the client browser and the back-end application server. It takes some practice to get the optimal number of threads but a good rule of thumb is 1 thread for every 100 concurrent sessions. Click Next.
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 selecting the "TIP" button for a specific option."
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.
* "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 operational mode of the HTTP access service
* "Application server URL": Enter the protocol (HTTP/HTTPS), host name or IP address of the Traveler server to forward authenticated traffic. If using HTTPS to secure the connection between IMC and Traveler, a certificate must be imported into the http.trusted.kdb database.
* "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 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.
* "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 backend 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.
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.
Single Sign-On (SSO)
6. Optionally, select the SSL Ciphers tab and select the appropriate ciphers. The default settings are to allow all V2 and V3 ciphers. Click OK.
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 (Figure 12 below):
Figure 12: LTPA / SSO tab
1. Check Enable LTPA.
2. 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.)
3. 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 Domino's Person Document contains the UID field.
4. The BEST Practice is to check "Enable SSO" but set the SSO 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 (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 the HTTP Access service definition, in which case it will override the setting in the Authentication profile.
5. 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.
6. In the "LTPA key action" section, select "Generate new keys" and enter a 6-32 character password. Remember this password since it is required to import the key file on the iNotes servers.
7. 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)
Import LTPA key file on IBM Notes Traveler servers
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. Note
* 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.
** 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.
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 Domino Administrator, from the File menu, choose Open Server --> enter the name of the server on which to work. One 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, LtpaTokenLOTUSMOBILECONNECT, 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, 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).
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 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
There are several methods for configuring IBM Mobile Connect with IBM Notes Traveler (Stand Alone - Single Server, Stand Alone several server, or High Availability Pool or Pools. Please consult IBM Support if there are questions regarding how this field should be set for your intended environment.