So far, we have covered data handling using multiple features and techniques of mobile and enterprise data applications by using SQL and HTTP adapters. In this chapter, we will explore the security capabilities of IBM Worklight.
We can protect our applications and adapter procedures against unauthorized access request and transfer secure data between mobile and enterprise applications. We will also learn about the general security principles, concepts, and terminologies.
Worklight has a built-in authentication framework that allows the developer to configure and use it with very little effort. The Worklight project has an authentication configuration file, which is used to declare and force security on mobile applications, adapters, data, and web resources, which consist of the following security entities.
We will talk about the various predefined authentication realms and security tests that are provided in Worklight out of the box.
To identify the importance of mobile security, you can see that in today's life, we keep our personal and business data on mobile devices. The data and applications are both important to us. Both the data and applications should be protected against unauthorized access, particularly if they contain sensitive information, which is transmitted over the network. There are number of ways via which a device can be compromised, and it can leak data to malicious users.
IBM Worklight provides various security roles to protect applications, adapter procedures, and static resources from an unauthorized access.
Each role can be defined by a security test that comprises one or more authentication realms. The authentication realm defines a process that will be used to authenticate the users.
The authentication realm has the following parts:
- Challenge handler: This is a component on the device side
- Authenticator and login module: This is a component on the server
One authentication realm can be used to protect multiple resources. We will look into each component in detail.
- Device Request Flow: The following screenshot shows a device that makes a request to access a protected resource, for example, an adapter function, on the server. In response to the request, the server sends back an authentication challenge to the device to submit its authenticity:
Request/Response flow between Worklight application and enterprise server diagram
The challenge handler component is written in JavaScript, and it is used to control the authentication process. Whenever WL Server sends a response, challenge handler is responsible to detect any possible authentication challenge that the server has sent over to it. Once a challenge handler has detected an authentication challenge that has come from the server, it will collect the required credentials on the device and will send them back to the server for further processing.
For example, a user is trying to access a protected adapter function, let's say a database record. WL Server will automatically detect this action and return a challenge to the device to prove its authenticity. Now, when the response comes back to the device, a challenge handler will further process it by collecting credentials and sending them back to the WL Server.
There can be multiple challenge handler instances for each realm application that needs to be authenticated. When an authentication flow is completed, the challenge handler sends a notification back to the Worklight framework indicating whether the authentication was a success or a failure.
There are some predefined methods that you will use to create a challenge handler and submit credentials back to the WL Server. We will learn about them later.
The authenticator component is written in the Java language and exists on the server side. It is used to collect the credentials sent by a client application. The credentials are passed on to a login module for validation. It can be used to collect any type of information accessible from an HTTP request object—cookies, headers, body, or any other properties. One authenticator type can be used by multiple authentication realms.
The following diagram shows how the same authenticator type can be used for several realms.
These are the three predefined authenticators present in Worklight Server:
- Adapter-based authenticator: This authenticator is implemented via adapter procedures to collect and validate credentials from the client application.
- Form-based authenticator: This authenticator sends a challenge in the form of an HTML login form to clients. It is useful for both web environments as well as mobile applications.
- Header-based authenticator: This authenticator does not check for interactive credentials' collection but is used to check for specific HTTP headers.
In addition to a predefined authenticator, a user can create his or her own authenticator components in Java.
A login module exists on the WL Server, and it is used to verify the user credentials and then create a user identity object, which contains the user properties throughout the life of the session.
Validation of credentials can be done in various ways, for example:
- Through a web service
- By looking up the user in a user's table in a database
- By using the WebSphere® LTPA token
It is possible to add custom properties in the user identity object according to your specific needs. The login module is also responsible to destroy the user identity object once the session has been terminated. It can be configured to automatically record login attempts for audit purposes. A login module can be used by multiple authentication realms.
Similar to the custom authenticator, it is also possible to create your own custom login module in Java.
An authentication realm comprises a challenge handler, authenticator, login module, and a definition of the authentication process. One authentication realm can be used by more than one security test. Each authentication realm defines its flow as shown in the following diagram:
Each authentication realm has one authenticator and one login module only.
The following are some questions of the flow:
- Once the authentication process has been triggered, what should happen next?
- What type of challenge should it send back to the client application?
- If a request arrives from a device, what credentials should it collect from it?
- How and when should the credentials be collected?
- How should the credentials be validated and sent to the server?
- What will be the result of the credentials' validation?
- What will be the properties of the user identity object?
There are several predefined authentication realms available in Worklight, for instance, remote application disable or an application authenticity.
A security test is created with an ordered set of authentication realms that are used to protect a resource such as an adapter procedure, an application, or a static URL. Security test defines one or more realms against which users must have to authenticate in order to access backed adapter function or resource. If multiple realms have been used, then the developer has to define the order in which the authentication should be performed.
You can create custom security tests along with default security tests that you can use for mobile and web environments' protection. The following diagram shows multiple security tests:
A security test can use more than one realm, and one realm can be used for multiple security tests.