Chapter 6. Authentication and Security

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...

Worklight security principles, concepts, and terminologies

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...

Examining generated realms, security test, and login modules

Realms, security tests, and login modules are defined in the authenticationConfig.xml file located at the server/conf folder of a Worklight project.

Open your Worklight project and locate the authenticationConfig.xml file and check for the following entries that are present by default to help you quick start with it:

Worklight application's authenticationConfig.xml file's location

Let's create a new Worklight project and examine what realms, security tests, and login modules are generated for us by default.

Generating realms

We can see that the following realms have been generated by default, which we can use or customize further:

<realms>
   <realm name="SampleAppRealm" loginModule="StrongDummy">
   <className>com.worklight.core.auth.ext.FormBasedAuthenticator</className>
  </realm>
   <realm name="WorklightConsole" loginModule="requireLogin">
   <className>com.worklight.core.auth.ext.FormBasedAuthenticator...

Creating adapter-based authentication

Adapter-based authentication is the simplest form of authentication provided in Worklight. It uses the adapter procedure/function to validate and authenticate the users and create their sessions. Plus, it provides all the features of the Worklight authentication framework.

Please use the following simple steps to implement adapter-based authentication:

1. Create a new Worklight project with the name ABADemo; for the application, use the name myAdapterBasedAuthentication.

2. Add an adapter and give it a name: myAuthAdapter. Paste the following sample function code into the adapter.js file:

   function onAuthRequired(headers, errorMessage){
     errorMessage = errorMessage ? errorMessage : null;
     return {
       authRequired: true,
       errorMessage: errorMessage
     };
   }
   
   function submitUserAuthentication(username, password){
     if (username==="adapter" && password === "adapter"){
       var userIdentity = {
         userId: username,
         displayName: username, 
        ...

Form-based authentication

Form-based authentication is similar to a web application in which the users have to fill out a login form in order to access a secured or protected resource. Worklight provides a similar authentication mechanism in which the server returns the HTML of a login form whenever an application tries to access a protected resource.

The Worklight application that uses form-based authentication must use a login module to validate the received credentials.

Security realm

Declare the security realm with the name myFormBasedAppRealm as follows:

<realm name="myFormBasedAppRealm" loginModule="myFormBasedAppLoginModule">
  <className>com.worklight.core.auth.ext.FormBasedAuthenticator</className>
</realm>

The login module

Now define the login module with the name myFormBasedAppLoginModule as we used the same for the loginModule attribute value to define the realm:

<loginModule name="myFormBasedAppLoginModule">
  <className>com.worklight.core.auth...

Custom authentication

It is possible that these Worklight-provided authentications do not fulfill your requirements. In such scenarios, Worklight provides you with an ability to create custom realms, login modules, and security tests based on your specific needs.

In this case, you will create your custom Java class that implements the WorkLightAuthenticator interface in order to create an authenticator. Similar to creating a custom login module, you need to extend the WorkLightLoginModule interface.

The login module will create a request object that contains the user ID and password, and based on the user-specified validation, it will create a user identity object, that is, a session object.

For more information on custom authentication, please refer to IBM Worklight Info Centre (http://pic.dhe.ibm.com/infocenter/wrklight/v5r0m6/index.jsp?topic=%2Fcom.ibm.help.doc%2Fwl_home.html).

Summary

In this chapter, we learned about Worklight security concepts, Worklight authentication processes, and various options to protect mobile applications, adapters, and resources. We briefly talked about various authentication mechanisms such as the ones that are adapter based, form based, and custom authentications.

We learnt how to implement adapter-based authentication in a Worklight application. We worked on an example by creating adapter-based authentication and examined the steps that an authentication process goes through. Moreover, we slightly touched form-based authentication and custom authentications as well. In the next chapter, we will be coming across some of the most advanced features and extensions, including push notifications, WL APIs, Cordova plugins, and offline cache mechanism, which allows you to extend your mobile application.