In April, I wrote a post named "Prevent malware-ridden devices from accessing IBM Worklight adapters" that discussed integration techniques between Trusteer and IBM Worklight 6.1.
Trusteer, an IBM company, provides the Trusteer Mobile SDK, which collects multiple mobile device risk factors and provides them to the mobile app, enabling organizations to restrict mobile app functionality based on risk levels.
In Worklight Foundation 6.2 the integration is easier than before, because parts covered in my previous blog post are now integrated directly into the product. Here I will explain the basic steps needed to use Trusteer in your Worklight application.
Installing the Trusteer Mobile SDK
As before, the Trusteer Mobile SDK is provided separately from Worklight, so ask your sales representative. The process may be easier if you ask for a WLC file (Worklight Component). The WLC file can only help for hybrid applications. For native projects, you will still need to install manually.
If your project is a hybrid Android app, the process should be very easy with a WLC file. Just install the file and enter your license information in nativeResources/assets/tas.license.
If your project is a hybrid iOS app, the WLC file will also install files within nativeResources; however, you’ll need to make some modifications in XCode since Worklight Components are unable to modify XCode projects. Also, don’t forget to modify the tas.license file.
If your project is native (Android or iOS), you will need to manually install the provided files.
In all cases, see step-by-step instructions in the Worklight documentation.
Using the Trusteer Mobile SDK
In Worklight 6.2, you no longer need to manually call Trusteer’s C functions to get the calculated risk assessments. The entire process is abstracted for you by a new Worklight application programming interface (API).
In Objective-C, use the WLTrusteer class. The riskAssessment method will return an NSDictionary ready for consumption.
In Java, use the equivalent WLTrusteer class and its getRiskAssessment method.
In any case, as you’ll see next, using the client-side API is completely optional since all of this information is automatically sent to the server without your intervention. However, the client-side API is still useful since you may want to update the user interface depending on the current risk assessments.
As soon as the Trusteer Mobile SDK is installed and active, every HTTP request to the Worklight Server will contain the Trusteer risk assessments. You no longer need to manually add global HTTP headers. Worklight will do that for you automatically.
Also in 6.2, you no longer need to write your own custom authenticator. Worklight provides an authenticator for you (com.worklight.core.auth.ext.TrusteerAuthenticator) that is designed to help you protect resources using the result from the Trusteer assessment.
New projects come with a sample (commented-out) login module and realm for Trusteer protection. You will be able to specify which scenarios are acceptable and which are not. For example, you can choose to block malware devices and alert rooted devices. See all the options and examples here.
You’ll also need to write a security test that will use your new Trusteer realm and protect the resources as needed.
If the Worklight server sends a block or alert event according to your Trusteer realm options, you’ll want to notify the user or change the application behavior.
To do so, you need to write a challenge handler that follows the special Worklight protocol. The challenge handler will receive a reason code that you can show to the customer or use to make a decision.
In Objective-C, use WLClient’s registerChallengeHandler to pass an object that follows the WLChallengeHandler protocol. If the server sent a block event, handleFailure will be called. For an alert, handleSuccess will be called.
In Java, use WLClient’s registerChallengeHandler to pass an object that implements the interface WLChallengeHandler. If the server sent a block event, handleFailure will be called. For an alert, handleSuccess will be called.
See simple examples in the documentation.
To learn more I recommend following the sample guides and sample projects provided here. And feel free to leave a comment or a question below.