Integrating StrongLoop with MobileFirst Platform

Overview

Most mobile applications need to access data stored in the enterprise's back-end system of records and other back-end systems. The traditional way for accessing those back-end systems in MobileFirst Platform (MFP) is using adapters. Adapters are pieces of code written in JavaScript that are called fom the mobile application using RPC over HTTP and that make a call to some back-end system.

In addition to the ability to integrate with back-end systems from within a mobile application using adapters, MFP provides the following capabilities which are very important to any mobile application:

  • Security – Protect each one of the APIs which are called by the mobile application, allowing for different levels of security for each API.
  • Operational Analytics – Monitoring all events that occur in the system and storing them to gain significant information that can be used to enhance the system's performance as well as gain insight into the usage of the applications and the back-end services.

Recently, the de-facto standard for accessing back-end systems has become RESTful APIs, because of performance, scalability, simplicity and other reasons. This is true for all types of applications, but especially mobile applications because of the demands on performance.

IBM added support for REST APIs with MFP version 7.0 and has continued to enhance that function in more recent releases. The REST adapters can be written in Java (JAX-RS) or JavaScript and deployed to the MFP server.

In addition to deployed adapters, we also support external REST APIs. External REST APIs are any REST service which runs outside the context of MFP and can still be called from within a mobile application. Not only it can be invoked from a mobile application, it can also be protected using the MFP security and logged to the MFP Analytics as if it was an adapter running inside MFP. This capability is extremely important as it allows operators to see how specific back end services may be contributing to problems on mobile applications. The following article describes how MFP integrates with external node.js REST APIs: www-01.ibm.com/support/knowledgecenter/SSHS8R_7.0.0/com.ibm.worklight.dev.doc/dev/r_oauth_filter_onprem.html

This article shows how to integrate StrongLoop and MFP so that the REST APIs that were created by StrongLoop and run on the StrongLoop server will be treated as external REST services, just as described above.

Authentication through an access token over OAuth 2.0

The OAuth 2.0 authorization framework enables an application to obtain limited access to an HTTP service.

The implementation uses three roles of the OAuth protocol:

  • Client: An application that requests protected resources.

    In this case the client is a mobile application invoking the WLResourceRequest API in the MFP SDK to access remote resources. This API handles the OAuth-based security model protocol and invokes the required challenges.

  • Authorization Server: The server that issues access tokens to the client after it has successfully authenticated the resource owner and obtained authorization.

    In this case the MFP server will act as the authorization server. It will authenticate and authorize clients by running a series of challenges to the client. When the client answers all challenges appropriately, MFP will send back to the client an Access Token which can be used to access external resources.

    The following diagram shows the flow in which the client obtains an access token from the MFP server.

    missing_alt
  • Resource Server: The server that hosts the protected resources. It can accept, and respond to, protected resource requests by using access tokens.

    In this case the StrongLoop server, together with the node.js TokenValidation library, will act as the resource server while all the REST APIs hosted on the server are the different resources. The Token Validation library will intercept all REST API calls, will validate the OAuth Access Token, and if the token is valid and contains the right scopes, will invoke the REST API.

    The following diagram shows how StrongLoop, using the npm token validation library, verifies the access token off-line, i.e., without accessing the MFP server. For this to work, the library will connect MFP once to get the public key and will then do all validation locally.
    missing_alt

Configuring the StrongLoop API

For your StrongLoop Server to accept the access token, you must add the node.js Token Validation library, passport-mfp-token-validation, to your code. The passport-mfp-token-validation npm module provides passport validation strategy and a verification function to validate access tokens and ID tokens that are issued by the MobileFirst Server. It also supports logging events to the MobileFirst Platform Analytics server.

The library can be downloaded through npm:

$ npm install passport
$ npm install passport-mfp-token-validation

Once installed, it can be used for protecting APIs as well as reporting analytics events.

The following code example shows how to use an MFP Strategy in a StrongLoop application to initiate Analytics logging and to protect APIs. The code changes are done in the server/server.js file.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
var passport = require('passport-mfp-token-validation').Passport,
    mfpStrategy = require('passport-mfp-token-validation').Strategy;
passport.use(new mfpStrategy({
    publicKeyServerUrl:'http://mfp-host:10080/WLProject',
    // The analytics item is optional and only required if you wish
    // to log analytics events to MFP.
    analytics : {
	  onpremise: {
    		url : 'http://mfp-host:10080/analytics-service/data',
    		username : 'admin',
    		password : 'admin'
	  }
    }
}));
app.use(passport.initialize());
// Helper functions to have one liner API protection
var cont = function(req, res){
    next();
};
var auth = function(scopes) {
    return passport.authenticate('mobilefirst-strategy', {
        session: false,
        scope: scopes
    });
}

Then, for every API you would like to protect, add the following lines to the same file:

1
2
3
4
//protect the GET CoffeeShops API with MFP strategy using scope 'Realm1'
app.get('/api/CoffeeShops', auth('Realm1'), cont);
//protect the PUT CoffeeShop API with MFP strategy using scope 'Realm2'
app.put('/api/CoffeeShops/:id', auth('Realm2'), cont);

Please note, the function that you specify in each line above must call next() so that the StrongLoop implementation will be called (just like in the cont() method above). You should not define new end-points, just invoke the ones created by StrongLoop.

Using the WLResourceRequest API on the client

The MobileFirst WLResourceRequest API provides built-in support for accessing REST APIs using the MobileFirst access tokens for the following platforms:

  • Hybrid – JavaScript
  • Android
  • iOS
  • Windows Phone 8.1

Use of WLResourceRequest

This JavaScript example shows how to use the client-side API for access an external REST service.

1
2
3
4
5
6
7
8
9
10
11
12
function callProtectedRestAPI() {
    var url = EXTERNAL_SERVER_URL + REST_CONTEXT_ROOT + PATH_PROTECTED;
    var request = new WLResourceRequest(url, WLResourceRequest.GET);
    request.send().then(
        function(response){
            showResult(response.responseJSON.description);
        },
        function(error){
            showErrorResult('failed to get scope!');
        }
    );
}

Additional Resources

Additional information about the Token Validation library and all of its parameters can be found here.

In depth information about the OAuth Security Model can be found here.

Details about how to configure the MFP server to support external resources can be found here.

Inclusive terminology note: The Mobile First Platform team is making changes to support the IBM® initiative to replace racially biased and other discriminatory language in our code and content with more inclusive language. While IBM values the use of inclusive language, terms that are outside of IBM's direct influence are sometimes required for the sake of maintaining user understanding. As other industry leaders join IBM in embracing the use of inclusive language, IBM will continue to update the documentation to reflect those changes.
Last modified on August 17, 2016