Integrating IBM MobileFirst Platform with reverse proxies and security gateways

[This post is based on the “Integrating with reverse proxy and security gateway” section from the IBM MobileFirst Platform security technical white paper. The text has been updated and expanded to include additional details and new features related to Device Single Sign-On with security gateways that were introduced in IBM Worklight 6.2.]

Enterprises use reverse proxies and security gateways in their perimeter network to protect web resources. There are several products in the market that function as reverse proxies and security gateways providing a termination point for HTTPS and user authentication. IBM MobileFirst Platform can be configured to work with these types of security components using its flexible authentication integration framework. IBM Security Access Manager for Enterprise Single Sign-On, IBM DataPower®, CA SiteMinder, and other similar solutions, can be configured as reverse proxy and a security gateway.

The most common configuration for integrating with these security gateways includes leveraging the header-based authentication mechanism included in IBM MobileFirst Platform. For example, the CA SiteMinder Reverse Proxy might forward a header with user identity upon successful authentication of the user to IBM MobileFirst Platform, which can be configured to trust that header and authenticate the session based on the user identity in the header. With IBM Security Asset Manager and IBM DataPower, there are additional mechanisms, such as a Lightweight Third-Party Authentication (LTPA) token.

IBM Security Access Manager and IBM DataPower as reverse proxies can terminate the authentication of the user and forward trusted credentials in the HTTP header or cookie. IBM MobileFirst Platform can then verify the credentials from the HTTP header or the cookie and establish the user session based on that authenticated user. There are two common mechanisms for establishing trust between security gateways and IBM MobileFirst Platform:

    1. Header based. IBM MobileFirst Platform can be configured with header-based authenticator and login module to set the user identity based on the value from a custom header. The custom header is set and forwarded by the security gateway. The header-based authenticator in IBM MobileFirst Platform consumes this header and the header-based login module establishes the user session based on the value in this header.
    1. Lightweight Third-Party Authentication (LTPA) based. IBM MobileFirst Platform on WebSphere Application Server and WebSphere Application Server Liberty Profile can be configured with an LTPA realm to set the user based on the LTPA token forwarded by IBM DataPower or IBM Security Access Manager. With trust being established between the WebSphere runtime and IBM Security Access Manager or DataPower, the LTPA realm configured in IBM MobileFirst Platform will consume the LTPA token sent as a cookie and it will establish the user session from the LTPA token.
  • The sequence diagram in Figure 1 shows the general flow when a security gateway is used between the mobile application and the MobileFirst Platform server. In this diagram, the word “token” is used to represent either of the cases described above. The token could be a header based token or an LTPA token. The flow shown in the diagram is generalized such that it could apply to IBM Security Access Manager, IBM DataPower, CA SiteMinder or other security gateways and reverse proxies.


    In this flow, the initial request from the MobileFirst Platform app to the MobileFirst Platform server is checked at the security gateway. If the requested URL is protected (requires user authentication), and this session has not already been authenticated, the gateway will send back a login form. The challenge handler in the mobile app will see the login form, gather the requested credentials from the user, and post the credentials to the gateway via the login form. The gateway will authenticate the credentials and, if they are valid, will generate the appropriate token to represent the user (typically an http header based token or an LTPA token cookie). The mobile app will then retry the original request, but this time the user is authenticated. So the gateway will allow the request, including the header based token or LTPA token, to continue to the MobileFirst Platform server. The MobileFirst Platform server will then check what security realms are required for this request. The user credential is already present in the form of the header token or LTPA token, so the MobileFirst Platform server will then validate or assert that token according to the authenticator and login module chosen. There will likely be additional MobileFirst Platform security realms defined that must be successfully authenticated against, for example application authenticity, device provisioning and anti-XSRF realms. The MobileFirst Platform server will send challenges back to the mobile app for those realms. The challenge handler in the mobile app will detect those challenges and gather the required information to satisfy the challenges from the server. The mobile app will then submit the request again with the challenge responses and the MobileFirst Platform server will validate the responses. Once the challenges are satisfied, a successful response will be sent to the mobile app. The mobile app is then ready for further use.

    Another feature in MobileFirst Platform is Device Single Sign-On (SSO). With this feature, a user can authenticate once and access multiple protected resources (applications and adapter procedures). Once a user on a device has authenticated to an SSO-enabled login module, they can access other resources protected by that same login module without having to re-authenticate. This poses a challenge with a security gateway topology. The Device SSO feature relies on the device ID that is sent from the mobile app. The ID is checked at the MobileFirst Platform server to see if that device already has a valid, active authentication. The security gateway will not have access to the database of registered devices or the state of the authentication for the devices, so it is not able to grant access based on the device ID. So the security gateway will prompt for user credentials before the MobileFirst Platform server has a chance to allow access based on the device ID. In Worklight 6.2, support was added to allow the Device SSO feature to work with security gateways. For the case of IBM Security Access Manager, an integration guide is available detailing the configuration required to enable this scenario. The recommended approach described in the integration guide is based on setting up the rules on the security gateway to allow the incoming requests to the /init and /authenticate URLs to flow through to the MobileFirst Platform server. This allows the device authentication challenge/response between the mobile app and MobileFirst Platform server to proceed normally (as it would with no security gateway). The security gateway will still check and authenticate all other URLs to the MobileFirst Platform server, only delegating the checking for /init and /authenticate to the MobileFirst Platform server. The sequence diagram for this flow is shown in Figure 2


    Another approach to achieve Device SSO with a security gateway is to use the Simple Data Sharing feature in Worklight 6.2 and later. With this feature, several applications within a family of applications on a single device can securely share lightweight information such as authentication cookies or tokens. An application family is a set of applications that specify the same value for the application family (wlAppFamily value in worklight.plist on iOS or sharedUserId in the Android manifest) and are signed by the same signing identity. Each application in the application family must first be configured to use Device SSO. Then, each application would be configured to share the appropriate cookie (or cookies) via Simple Data Sharing. For example, the cookie to share may be PD-S-SESSION-ID, LtpaToken2 or other cookie used by your gateway. With this setup, the first application launched would authenticate to the gateway (typically by prompting the user for credentials) and then authenticate to the MobileFirst Platform server, including authentication to the Device SSO realm. The cookie obtained from the gateway will be shared with the other applications in the family. When the second and subsequent applications are launched, they will retrieve the shared cookie and use it to authenticate to the gateway without having to prompt the user for credentials. The request will then continue to the MobileFirst Platform server where it will validate that this device has already authenticated via Device SSO and then authentication process will be complete.

    The IBM MobileFirst Platform provides a flexible architect for integrating with the existing security infrastructure of an enterprise. In this article, common approaches to integrating with existing reverse proxies and security gateways are described. In addition, two approaches to enable the use of the Device SSO feature with security gateways are described.

    Last modified on March 22, 2016