HTTP access services
HTTP access services enable secure connections between a remote mobile device and HTTP services on the internal network, such as IBM Traveler and IBM Sametime. HTTP access services do not require installation of a VPN client, and are sometimes said to provide clientless access. HTTP access services are secured with Transport Layer Security (TLS) encryption.
The HTTP access services subsystem is installed with SafeLinx Server and is responsible for applying a consistent set of configuration options to sessions that it manages. This subsystem validates access, enforces security, generates audit information, and relays traffic to internal servers. Each HTTP access service can send traffic to a single or to multiple applications. HTTP access services integrate support for a range of IBM® mobile applications, including IBM Connections, IBM Connections Chat (formerly, Sametime® Mobile), IBM Verse, IBM Notes® Traveler, and IBM iNotes®.
HTTP access services differ from the HTTP codec resource that is used to support SafeLinx Clients.
The connection between an HTTP access service and an HTTP client is secured by using Transport Layer Security (TLS). You can restrict the service so that it allows connections from specified hosts or address ranges only.
Inside the firewall, an HTTP access service relays authenticated HTTP encapsulated traffic from client applications to an internally located HTTP proxy or application server. Optionally, you can also use TLS to secure the connection between the HTTP access service and the HTTP proxy server or application server. If client applications access a server that generates an HTTP redirect, use TLS to secure the communications to the application server or proxy. The generated redirects are then also forced to use TLS.
Along with an HTTP proxy, HTTP access services use the System, RADIUS, or LDAP-bind authentication profiles to provide the same service as an authenticating HTTP proxy.
The HTTP access service uses a method of authentication that establishes a secure HTTP connection with an HTTP client data stream, for example, from a browser. The HTTP access service checks the data stream for valid credentials. If none exist, the access service sends back a form-based login screen, which challenges the user for a valid user ID and password.
Then, the HTTP access service sends the HTTP data stream to an HTTP proxy server or any application server that supports HTTP as a transport. The connections to the HTTP access services can be configured to allow connections only from specified hosts.
When an HTTP client attempts to connect with HTTP access services, the client header is parsed for a cookie with a specific name-value pair token. These name-value pair tokens are generated based on settings in the authentication profile.
- LTPA (Version 1)
- LTPA Version 2 (LTPA2)
- SafeLinx Server-specific cookie
LtpaToken=is found in the header, then the LTPA encoded token is used. If the name
WgSessionKey=is found in the header, then the SafeLinx Server encoded session key is used. If a valid cookie is found in the header, then the HTTP client request is forwarded to an HTTP proxy or application server. This cookie is used in future connection attempts and has a lifetime equal to that of the browser session. Though in the case of the LTPA token, the token has a separate configurable lifetime.
When no valid cookie is found in the header, a login page is sent to the HTTP client. After the user logs in and provides valid credentials, the HTTP access service sets a cookie and redirects the request back to the HTTP client. The HTTP client reconnects with a valid cookie in the header. The HTTP access service uses this action to validate and forward the request to an HTTP proxy. Mobile Connect provides default login forms that you can customize for your environment. For more information, see Creating custom login pages.
If users connect to the HTTP access service from devices of unknown or unreliable security, the potential presence of spyware might expose data or user credentials to compromise. Protect against unauthorized access risks by implementing safeguards such as TLS encryption and secure authentication.
The Service URL can be entered directly in a browser or stored in a Host tag of an HTTP header in an application data stream. If the value of Host does not match the value of the Service URL, the HTTP access service sends a 301 Moved Permanently HTTP status code to the HTTP client. It also sends the appropriate URL for redirection to the port configured for the HTTP service. To avoid certificate processing warnings on some browsers, the value of Host must match the value that is stored in the client certificate.
For information about configuring HTTP access services for use with IBM Notes Traveler and IBM iNotes, see the articles Providing secure remote access to Traveler servers and Enabling secure, remote access to IBM iNotes using IBM SafeLinx.