Using the Worklight Security Framework with Bluemix services
DrorAharon 270007BKVP Comments (4) Visits (3662)
The purpose of this blog is to explain how to integrate and use Bluemix services within a Worklight application while leveraging the Worklight Security Framework. The blog offers an overview of this feature, and a step-by-step example of usage.
This is a use-case of the feature -
In the example, I will show how a Worklight application can securely use a Bluemix service. Since Bluemix services cannot be accessed directly, the Bluemix service will be bound to a Bluemix application, which will expose an API for using the service. The source code for both Bluemix and Worklight applications, and a video sample, can be found here.
What is Bluemix?
Bluemix is an open-standard, cloud platform that can be used to quickly build, deploy, and monitor applications and services. Bluemix provides a broad set of services and runtimes that gives you control and flexibility for mobile development.
Only Bluemix applications can access Bluemix services. So, in order to use Bluemix services, they need to be bound to a Bluemix application. Bluemix offers applications in several languages, such as: Node.js, Java, Ruby. This blog will show how to create a Node.js application that uses a Bluemix service, and how to have protected access to the Bluemix application with the Worklight Security Framework.
Why use the Worklight Security Framework?
Starting from Worklight 6.2 it is now possible have SSO
For more details on this feature, see the 'Using the Worklight Server to authenticate external resources' PDF in the Worklight getting started link.
Overview of the final outcome:
User tries to access a resource of a Bluemix application which is protected by Worklight
Following is an example with step-by-step instructions on how to integrate the Node.js Bluemix application with a Worklight application. This example demonstrates how a Worklight application can use a simple Bluemix DB service, which is bound to a Bluemix application.
Creating a Worklight project
The authorization will be done with the oauth 2.0 protocol, using access tokens for authorization, and the scope of the access token will be a Worklight security test.
The first step, will be to create a Worklight project, and configure both the keystore that will be used to sign and verify the tokens, and the security test used to protect the resources. A detailed explanation on how to achieve this can be found in th
For this demo, the designated scope (Worklight security test) will be called 'TestScope', and it is configured as follows:
The keystore used is the default keystore. For production environment, avoid from using the default keystore.
Getting started with Bluemix
Bluemix saves developer a great deal of time by providing boiler plates. For this demo, the Node.js boiler plate was used to get started. The boiler plate creates a simple Bluemix application with a Bluemix DataBase service bound to it.
After logging in to Bluemix, go to 'CATALOG' and from Boilerplates, choose the 'Node JS Web Starter'.
Navigate now to your 'DASHBOARD' and you should see that both the application and the service were created. After a couple of minutes, Bluemix will have made all necessary configurations, and the application should be up and running. A green light will indicate that the app is running.
So now, if you enter the application url, you should see this screen:
This is a basic application with the abilities to get, put, and delete key-value pairs.
Notice that you will be able to perform all operations: Get, Put, Delete.
In order to edit the Bluemix application code, you need to follow the Bluemix instructions.
Enter the application configuration screen (by pressing the application from 'DASHBOARD') and follow the instructions that pop-up when pressing the 'VIEW QUICK START' button on the top right.
When installing the validator module, make sure you run the installation command from the Bluemix application root folder.
The Bluemix application has several files, but all necessary changes can be made in the 'app.js' file which is located in the application's root folder.
Open this file with your favorite editor. The application uses the 'express' module to create a web server that exposes REST API for the 'Get', 'Put', and 'Delete' operations; it also exposes some UI so it will be accessible from any web browser. In order to integrate with this module, it is necessary to create middleware for the validation purposes.
First, some requirements need to be added to the app.js:
Then, initialization of the validator:
And finally, the filtering method:
Notice, you may choose to pass on the authentication data received from the validator to the handlers.
For this demo, all users are allowed to use the 'Get' method, but 'Put' and 'Delete' abilities are not exposed to the common user, but only to users with Worklight authentication for the 'TestScope' security test created earlier.
This can be done quite easily using express.
cf push <app name>
Notice that after configuring the validator, if you enter the application URL, you will no longer be able to perform the 'Put' and 'Delete' operations, but the 'Get' operation will still be accessible.
All that's left is writing a Worklight application that will use the REST API exposed by the Bluemix application we've just created.
For this purpose, a small demo application was created, which reflects the capabilities of the Bluemix application.
If you want to see the Worklight application in action, you will need to change the initialization of the variable 'BLUEMIX_APP_URL' to point to your Bluemix application URL. This variable, along with most of the logic, can be found under <app root
Playing with the application
You can change both Bluemix and Worklight application code and see the effects.
You can edit the Bluemix application to protect different resources; secure the Get method, remove the protection from Put/Delete, or use the validator for all requests sent to the application (with app.use/app.all).
On the Worklight side, notice that the security test has the realm "wl_
Change the state from 'Active' to 'Access Disabled', and try to use a protected method. What you should see is that now you won't be able to authenticate against the Worklight Server, so you won't be able to receive a valid token to access the protected resource on the Bluemix application.
You might notice that your initial requests go through and only then you are rejected. This is due to the fact that the last access token retrieved is still valid. Only after it expires the request will be rejected by the Bluemix application, and the authentication flow between the Worklight application and the Worklight Server will be initiated.
*** Note: The demo app won't work with the Worklight 'preview' mode since it will violate the same-origin policy