Let me begin with a no-brainer: Do you think that enterprise mobile apps must be secure? The answer, without batting an eyelid, is yes. So, what are the challenges in securing mobile apps? Are they different from other enterprise software? If yes, are the solutions different?
If you’re looking for answers to the above questions and more, you’ve come to the right place. In this post, I will provide a layman’s guide to understanding how IBM Worklight addresses the security problems that are unique to mobile.
The challenge-response design
A typical mobile app will have a client-side component that frequently accesses server-side resources. For example, a banking app could get crucial information such as account balance or the status of a fund transfer from the server. Or it could even send commands such as a money transfer instruction to the server. To ward off spurious and malicious requests, IBM Worklight employs a challenge-response design to authenticate requests coming from an app.
For every request coming to the IBM Worklight Server, it challenges the app with a preconfigured set of challenges. These challenges could be in any form—a username and password combination, a hash of a secret key (usually a secret password is not sent over the network but instead hashed into something else) or even the output of a fingerprint scanner. The app must respond to the challenge in a satisfactory manner, failing which, the app is denied access to the original request.
At the heart of the challenge-response design of Worklight is a concept known as a security test. A security test defines all the protection mechanisms that are employed on a server resource to prevent unauthorized access. Apps, adapters and event sources can all be protected by security tests.
Every security test is comprised of one or more authentication realms. Each realm is designed to handle one particular type of security threat. For example, the anti-XSRF realm is designed to ward off cross-site scripting threats. Therefore, a combination of multiple realms in a security test can effectively block all unauthorized access to a server resource.
Authentication and login modules
Each realm consists of an authentication module and a login module. These are server-side units, which, put together, have the responsibility of validating data provided by the client app in response to a challenge. For example, a realm might request a username and password from the user. The authentication and login modules have the job of validating the username and password from a database or a Lightweight Directory Access Protocol (LDAP) server.
All the terms explained so far reside on the Worklight Server. The apps require some logic on the client side to make sense of the challenges posed by the server. Challenge handlers fill in this gap. They have the responsibility of responding adequately to challenges posed by the Worklight Server. For example, a realm that might request username and a password will have a client-side counterpart in a challenge handler that will present a form to gather the username and password from the user.
This is an introductory post on the terms used in IBM Worklight with respect to security. Stay tuned for my next post about Worklight security, in which I plan to discuss how to put these concepts to work. You can leave a comment below or reach me on Twitter @kulkarni_.