Worklight mobile application security

To produce secure mobile applications, you must apply security principles and techniques to the implementation and configuration of your Worklight mobile applications, adapters, data, and web resources.

Worklight security entities

Worklight defines a framework that consists of:
  • Server-side security tests
  • Authentication realms
  • Log-in modules
  • Authenticators
  • Client-side challenge handlers.
Server-side security tests
A security test declares the set of one or more authentication realms that are used to protect an application, adapter procedure, or static URL resource.
Authentication realms
An authentication realm consists of a challenge handler, authenticator, login module, and a definition of the authentication process. An authentication realm can be used by more than one security test.
Log-in modules
A login module resides on the server. It is responsible for verifying credentials passed to it from an authenticator, and for creating a user identity object. It is also responsible for destroying a user identity object when an authenticated session is terminated. A login module can be used by multiple authentication realms.
Authenticators
An authenticator resides on the server. It is responsible for retrieving credentials through an HTTP request from a client application. The credentials are passed on to a login module for validation. An authenticator type (class) can be used by multiple authentication realms.
Client-side challenge handlers
A challenge handler resides on a client or device. It is responsible for detecting authentication challenges from a server, collecting user credentials, and sending them back to the server in response to a challenge. Each challenge handler identifies the authentication realm to which it applies.

To learn more, see Getting Started with IBM® Worklight Module 20 – Authentication concepts. Related modules 20.1, 21, 22 and 23 provide more information about form-based, adapter-based, custom, and WebSphere® LTPA-based authentication mechanisms.

For detailed information about how to configure authentication on the server side, see the IBM Worklight Developer Reference Guide section 12 – Authentication Configuration.

For detailed information about the client-side challenge handler API, see the IBM Worklight Developer Reference Guide section 6.11 – Authentication Methods.

Securing applications

Mobile applications should be protected against unauthorized access, particularly if they process sensitive information or access computing services on the internet or on an intranet. Worklight protects mobile applications by requiring the user to authenticate with the Worklight Server when the application starts.

You can protect an application by associating a security test (see Worklight security entities) with the application, or with application environments, in the application-descriptor.xml file.

By default, Worklight mobile applications communicate with the Worklight server, including adapters, over SSL, ensuring the confidentiality, integrity, and authenticity of the interactions between the applications and the server.

Securing adapter procedures

In the IBM Worklight platform, adapters act as intermediaries between mobile applications and back-end services. Adapter procedures should be protected against unauthorized access so that the back-end services the procedure runs are, in turn, protected.

You can protect an adapter procedure by associating a security test (see Worklight security entities) with the procedure in the containing adapter XML file.

Worklight adapters can be configured to communicate with back-end HTTP, web, and SQL services over SSL as well. Depending on the topology of the corporate network, the Worklight Server might reside on the corporate intranet or on a DMZ network on the internet. In the latter case, use SSL to protect communication between the adapter procedures that are running on the Worklight Server in the DMZ and the back-end services within the enterprise. In the former case, the Worklight Server is already protected within the corporate intranet. The use of SSL between the server and the back-end services also on the corporate intranet is largely a matter of internal corporate policy that is based on the information in play. For example, sensitive personal information should never be transmitted unsecured, even within a private corporate network.

An adapter procedure might be designed to invoke a service that resides outside the corporate intranet. Depending on the nature of the information, it might be prudent to ensure that such connections are also secured.

Securing resources

The IBM Worklight Server hosts the IBM Worklight Application Administration Console, the IBM Worklight Usage Reports, the IBM Worklight Application Center, and mobile web applications. Except for the IBM Worklight Application Center, these static resources can be secured against unauthorized use.

You can protect static web resources (other than the IBM Worklight Application Center) residing at specified URLs or URL patterns by associating security tests (see Worklight security entities) with the resources in the authenticationConfig.xml file.

To learn how to protect the IBM Worklight Application Center, see the IBM Worklight Application Center User's Guide section 2 – Installing and configuring the Application Center.

Securing data

In the wrong hands, personal information such as user IDs, pass codes, account numbers, contact lists, personal profile data, vacation plans, financial spreadsheets and more could lead to serious social, financial, health, or other problems for the rightful owner. Similarly, proprietary corporate information – which might include sensitive personal information – must be protected, otherwise the integrity, reputation, plans, and financial bottom line of a corporation, its employees, partners, and customers can come to harm.

If your mobile application must manage sensitive data on the device, it should use the encrypted offline cache to do so. The encrypted offline cache is a feature of the IBM Worklight client-side API that stores data in encrypted form on the device. Data is encrypted using a 256-bit encryption key that is constructed from a combination of a user or application-provided pass code and a randomly generated token from the Worklight server. The application must be able to connect to the Worklight server to open the cache. Subsequent operations to read, write, close, or delete the cache do not require a connection.

Even if your mobile application does not store any information on the device, loss of sensitive information in memory is still possible.

When designing your mobile application, particularly mobile web applications that run in the browser on the device, limit the user's ability to save, export or otherwise download sensitive data. For example, a mobile web application should present sensitive information to the user in HTML, not as a linked resource such as a PDF.

The average attention span for a mobile application is much lower than on notebook and desktop computers. Users switch between applications rapidly but without closing them. Applications that are open might remain authenticated to local or remote services that have sensitive data, such as the encrypted offline cache, or Worklight adapters and the back-end HTTP, web, or SQL services they delegate to. When you design your mobile application, consider closing secure connections, discard log-in credentials, close the cache, and so on after periods of inactivity.

By default, iOS takes a screen capture of the application and uses it to achieve the visual effect of the minimization and restoration of the application. The screen capture is not stored securely. You can use the setOnAppEnteringBackground API to hide any sensitive data on the display when an application is minimized and just before iOS takes a screen capture.

For more information about the encrypted offline cache, see the IBM Worklight Getting Started Module 7.8 - Encrypted Cache and the IBM Worklight Developer Reference Guide section 6.9.15 Encrypted Offline Cache.

For more information about the setOnAppEnteringBackground, see the IBM Worklight Developer Reference Guide section 6.9.17 Multi-tasking.


Feedback