HTTP access services

HTTP access services provide a secure tunnel for HTTP communication to any HTTP Version 1.1. client.

The connection between HTTP access services and an HTTP client is secured by using secure sockets layer (SSL). The connection between the HTTP proxy server and the HTTP access services is optionally secured by using SSL.

The HTTP access services use a method of authentication that establishes a secure HTTP connection with an HTTP client data stream, for example, from a browser. The HTTP access services check the data stream for valid credentials and if none exist, send back a form-based login screen, which challenges the user for a valid user ID and password.

Then, the HTTP access services send the HTTP data stream to an HTTP proxy server. The connection to the HTTP proxy can be configured to allow connections only from specified hosts.

When an HTTP client attempts to connect with HTTP access services, the HTTP client's header is parsed looking for a cookie with a specific name-value pair. There are two types of valid cookies: LTPA and a SafeLinx Server-specific cookie when LTPA is not configured. If the name 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. 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 services sets a cookie and redirects the request back to the HTTP client that then reconnects, this time with a valid cookie in the header that the HTTP access services uses to validate the session and forward the request to an HTTP proxy.

The authentication-related screens are generated from html documents that are located in a subdirectory of the SafeLinx Server install directory /<Install directory>/http/msg/<lang>/

These documents may be customized for your environment:
standard_login.html
This document contains the login form that is displayed on desktop or laptop browsers.
standard_logout.html
This document contains the logout message that is displayed on desktop or laptop browsers.
standard_nexttoken.html
This document contains the challenge form that is displayed when you use a Secure ID-based authentication method and the user is required to enter the "Next Token".
mobile_login.html
Same as standard_login.html but formatted to fit mobile devices such as the Apple iPhone.
mobile_logout.html
Same as standard_logout.html but formatted to fit mobile devices such as the Apple iPhone.
mobile_nexttoken.html
Same as standard_nexttoken.html but formatted to fit mobile devices such as the Apple iPhone.
/<Install directory>/http/msg/images/
Directory container for all images that are requested by the login/logout documents. The HTTP-AS service contains special code that recognizes the URL /lmc/* as a URL to resolve locally and not relay the request to the backend server.

It is permissible to customize the appearance, images, add rows and information, and so on, but the basic function of the login form must not be altered. If it is altered, you experience difficulty authenticating to the SafeLinx Server.

To explicitly log off the secure session, the user must manually enter the URL: https://<SafeLinx Server>/CM_Logout

IBM® iNotes® users do not need to explicitly log off from SafeLinx as SafeLinx contains product integration code that detects iNotes logoff events and destroys the SafeLinx session.

When the HTTP-AS service is configured to relay traffic to a reverse proxy, each requested resource (URL) must be paired with a service URL. For example, if the Service URL is configured as mobile.mycompany.com, then when the HTTP client enters that location in the browser, the HTTP access services redirect the URL as https://mobile.mycompany.com/http://mycompany.intranet.com

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, HTTP access services send a 301 Moved Permanently HTTP status code to the HTTP client in addition to the appropriate URL for redirection to the port configured for the HTTP service. The value of Host must also match the value that is stored in the client certificate in order to avoid certificate processing warnings on some browsers.

To add HTTP access services, from the Resources pane, right-click the SafeLinx Server to which you want to add the services, and then click Add > HTTP access service.