ShowTable of Contents
This article is intended for Lotus 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 Lotus Mobile Connect (LMC).
NOTE: Traveler is installed as a separate application and operates as a server task on a Lotus Domino server.
LMC 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, LMC 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 LMC option (HTTP access) works with Traveler
Why Lotus Mobile Connect?
LMC 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. LMC'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 LMC 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?
LMC's HTTP secures communication by forcing remote HTTP-based applications to connect using industry-standard SSL/TLS technology. 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 LMC'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 decode the information and validate 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 LMC-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
LMC'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 LMC and Traveler
LMC 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 LMC 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
Connection Manager's HTTP access services use SSL or TLS when communicating with the browser or client application. Both versions 2 and 3 of the SSL protocol are supported and 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.
LMC 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 is issued to prompt for a valid user ID and password. This function uses authentication methods and algorithms available to all components of LMC.
Authentication methods are resource containers defining how LMC challenges and validates remote user credentials. LMC 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
LMC 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 LMC-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 LMC 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 application server or proxy.
There are several ways to configure access to multiple backend application servers:
1. Use Traveler. LMC is tightly integrated with Traveler, allowing a single HTTP access services definition to connect with a back-end Traveler server.
2. Use a transcoding reverse proxy. Allows a reverse proxy to route traffic to the appropriate destination based on information contained in the target URL.
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 or
https://notestraveler2.example.com).
Configurable HTTP 401-based challenge
LMC 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 LMC form-based challenge. Instead, the HTTP Access Service must be configured to use an HTTP 401 challenge.
LMC 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 LMC 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.
Traveler
For a Traveler server accessed by LMC, the "External Server URL" field (Domino Server document --> Lotus Traveler tab) must be configured correctly, taking the form of
https://lmcserver.example.com:
/servlet/traveler (see Figure 3). Port 443 may be omitted from this URL since it is assumed. This field should match the LMC Service URL on the Traveler HTTP Access Service.
Figure 3: External Server URL
If you want an encrypted pipe between the Traveler and LMC servers, you must import a certificate in PKCS12 format for the Traveler server into the key database for LMC.
LMC
Configuring LMC 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 LMC management console, Gatekeeper.
Let’s consider sample architecture that includes a single HTTP access service configured to authenticate users against a Domino LDAP directory server and then relay authenticated traffic to a Lotus iNotes Redirector node. The steps assume that the LMC 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.
5. On the next screen (Figure 5), enter the "Port number of service".
Figure 5.
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.
LMC supports LDAP, RADIUS/RSA Secure ID, two-way certificate validation, and system-specific authentication methods. This example uses LDAP authentication against the Domino 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 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 LMC 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
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 "Tip on 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 a single backend application server or proxy. Multiple Traveler application servers require multiple HTTP access service definitions.
HTTP access services require public certificates to secure communications. LMC 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, wg_keyman, 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 LMC and Traveler, a certificate must be imported into the http.trusted.kdb database.
- "Remote hosts allowed access": If desired, specify specific devices which are allowed access to the HTTP service.
- "Authentication Profile": Enter the authentication method to use to validate remote user credentials.
- "SSO 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.
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 a two-processor system with 1000 simultaneous sessions is 5.
- "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.
- "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.
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.
LMC ships with a utility, wg_ikeyman, 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:
NOTE: The wg_ikeyman utility, called Key Management, is available from the Start Menu on Windows in the LMC program group. When using the Connection Manager on a UNIX platform, enter the command, wg_ikeyman, from the command line.
1. Either work with a new key database file or use one of the key database files installed by LMC:
* To use an existing file, select Key Database File --> Open. Set the Key database type to CMS, use Browse to go to the LMC 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 LMC server.
4. Click OK and exit the Key Management application.
5. Using Gatekeeper, bring up the HTTP Access Service Properties panel, select the SSL tab, and verify that the file name of the key database and the file name of the stash password are set correctly. Use the full path if possible.
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.
Single Sign-On (SSO)
Enabling SSO for LMC and Traveler requires that a common key file be generated by LMC and imported by the Traveler server.
Configure/Enable SSO on LMC
You can enable SSO for LMC 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 (typically set to the fully qualified host name of the LDAP or RADIUS server used for authentication).
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 LMC. Also, the UID may work to authenticate the user account if Domino's Person Document contains the UID field.
4. Check "Enable SSO" and set an SSO Domain. This 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. 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 LMC 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 LMC and must now be exported.
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 LMC export the keys and configuration data, follow these steps (refer to Figure 12 above):
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.
- In UNIX, the LTPA key file is in the root “/” file system.
Note that 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 Lotus iNotes servers
For SSO to function properly, all servers must agree on cryptographic keys, user information, and miscellaneous other configuration data. Once LMC generates the key file, it must be imported by the Traveler server.
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.