Securing your REST API

With developers exposing application functionality as REST services, willy nilly all over the enterprise, the onus of securing these REST services is on them as well. Here I will discuss the options for means of authenticating your REST services. For authenticating REST services you have the following broad options:

1. Use HTTP Basic Auth, Digest, Form based or Client Certificates
2. Use custom token based authentication mechanisms
3. Use OAuth 2.0 - Two legged or Three Legged Auth

Using HTTP Basic Auth, Digest, Form based or Client Certificates

Since HTTP is the most popular implementation of REST, Java EE based authentication mechanisms hold true for REST service calls as well. Here we have 3 options, as mentioned well in Java EE Security documentation.

To secure REST API exposed at http://<hostname>:<portnumber>/web-app-context/webapi/rest-resource we will use the following configuration in web application's web.xml

<security-role> <role-name>admin</role-name> </security-role> <security-constraint> <display-name>SecurityConstraint1</display-name> <web-resource-collection> <web-resource-name>WRCollection</web-resource-name> <url-pattern>/webapi/*</url-pattern> </web-resource-collection> <auth-constraint> <role-name>admin</role-name> </auth-constraint> </security-constraint> <login-config> <auth-method>BASIC</auth-method> </login-config>

Above, configuration uses the "Basic Auth" scheme, similarly REST based (logical) resources, can be secured using DIGEST, Form Based and client-certificates schemes as well. Please refer Java EE security documentation for further details.

Also, suitable realm can be used to refer to credential stores. If you want to make the actual authentication to be portable across application servers you can use JAAS and write-up your own custom LoginModule and CallbackHandler.

So far so good, securing REST services is like any conventional Java EE web application. But....

Many times, the REST services are consumed by not conventional browser based UIs, but rather by mobile applications based on say android or iOS. In such cases, having a mobile app which needs a re-login after  HttpSession timeout of say 30 minutes(for tomcat), can be very tedious and undesirable. Instead most mobile apps allow user to enter the username and password, once and then store it on the mobile device as an app preference.

In order to provide a feature such as above, with mobile clients in mind, we can use "custom tokens with expirations". The idea itself is quite simple.

1. The first time a mobile user uses the app, he is asked for a username and password for authentication. 
2. This server backend provides a REST API such as /login which takes a Http POST and username and password as part of Http request body. 
3. The password itself can be sent across using encoding such as base-64 (over SSL obviously!) 
4. The server validates the username and password going against a credential store such as LDAP based or ActiveDirectory based. Once the user is authenticated, a unique token is generated by server, the server saves this token against the username, along with say a timestamp and expiry date time and also the token is sent back to the client.
5. The client stores this token say in HTML5 localstorage and uses it in subsequent REST requests, in a custom http header
6. For subsequent requests, the server looks at the custom header retrieves the token, validates that it is valid by checking against the username and also ascertaining that it has not expired as per expiry policy.
7. If token is valid, the request goes through, if token is invalid or expired, the server throws back a 401 error, which makes the client go back to login page for re-login

The above mechanism is depicted in representative code below, to clarify the explanation.

The server side authentication and token check can be done using, a servlet filter interceptor as depicted below:

package com.mastek.opensource.security.filters;

import java.io.IOException;

import javax.servlet.Filter;
import javax.servlet.FilterChain;
import javax.servlet.FilterConfig;
import javax.servlet.ServletException;
import javax.servlet.ServletRequest;
import javax.servlet.ServletResponse;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

public class SecurityTokenFilter implements Filter {
 
 @Override
 public void doFilter(ServletRequest req, ServletResponse resp, 
   FilterChain chain) throws IOException, ServletException {
  
  HttpServletRequest request = (HttpServletRequest)req;
  String token = request.getHeader("MyTokenField");
  
  //additionally check if the token is valid
  //valid can also check if token is expired as per policy
  if(token == null || token.length() == 0)  
     //send HTTP resp code 401: Unauthorized
     ((HttpServletResponse)resp).setStatus(HttpServletResponse.SC_UNAUTHORIZED); 
  else
     chain.doFilter(req, resp);
  
 }


 @Override
 public void destroy() {

 }
 
 @Override
 public void init(FilterConfig arg0) throws ServletException {

 }
 
}

The servlet filter entry in web.xml is shown below: <filter> <filter-name>SecurityTokenFilter</filter-name> <filter-class>your.package.SecurityTokenFilter</filter-class> </filter> <filter-mapping> <filter-name>SecurityTokenFilter</filter-name> <url-pattern>/webapi/*</url-pattern> </filter-mapping>

The ajax request which sends out the token in custom Http header and redirects to login page if server throws a 401 is depicted below:

$(document).ready(function() {
$.ajax({
    type: 'GET',
    url: "my-url",
    dataType: 'json',
    data: "{ 'name': 'somedata'}",
    beforeSend: function (request){
        request.setRequestHeader("MyTokenField", localStorage.userToken);
    },
    success: function(mydata) {
        console.log('data ret='+JSON.stringify(mydata)) 
    },
    error: function(mydata){
        if(mydata.status === 401){
            alert('Redirecting you back to login page....');
            window.location = "login.html";
        }
    }
});
 
});

I have'nt put up the /login API, but its easy to imagine that, as a service which takes in username and password, and returns back a token.

The above mechanism is still suspectible to man-in-the-middle attacks, for which the transport needs to be secured with SSL, any which ways. Libraries for generating hash as the unique token are available in javascript as well as java.

The flexible thing about custom tokens, is that you can put in code on your server side to implement any particular policy for the token expiration. Example tokens can be to expire in a day or in a week. Also, keeping track of active users in your system is easier.

I will leave the OAuth 2.0 two-legged mechanism for a subsequent article, since this one is getting too lengthy as it is :-)

Hope you enjoyed the discussion above, related to basics of securing REST services.

Cheers!

Backbone.js - Getting Started Tutorial

When I started learning backbone.js, though there were several getting started tutorials, all of them seemed a little aggressive, since they introduced all the backbone features in a single, supposedly simple application. In this tutorial I am going to introduce each of backbone basic concepts incrementally and kind of provide a less steeper introduction to backbone.js for beginners.

Lets jump right in....

We will start out with a bare bones html file, which can be thought off, as the anchor or home page for the backbone application. Lets name it bb-intro.html.

Initial listing of bb-intro.html

Next we will create a "router" in backbone, it is like a navigator component, which maps URLs to views/templates.

Lets have 3 pages(views) in our application, to be able to display these on demand we will define the following routes.

 var AppRouter = Backbone.Router.extend({
   routes : {
    "" : "showPage1",
    "page1" : "showPage1",
    "page2" : "showPage2",
    "page3" : "showPage3"
   },
   showPage1 : function() {
    new AppViewPage1().render();
   },
   showPage2 : function() {
    new AppViewPage2().render();
   },
   showPage3 : function() {
    new AppViewPage3().render();
   }
});

var appRouter = new AppRouter();
Backbone.history.start();

The route entry "" implies the default html page and refers to the following URL
http://<host-name>:<port number>/<web-context>/<path-to-html>/bb-intro.html
or
http://<host-name>:<port number>/<web-context>/<path-to-html>/bb-intro.html#


The entry "page1" refers to the following URL:
http://<host-name>:<port number>/<web-context>/<path-to-html>/bb-intro.html#page1

The entry "page2" refers to the following URL:
http://<host-name>:<port number>/<web-context>/<path-to-html>/bb-intro.html#page2

and so on....I think you get the picture here :)


Next up, is the views like AppViewPage1, AppViewPage2, AppViewPage3, these are as you might have guessed javascript objects defined as follows:

 var AppViewPage1 = Backbone.View.extend({
  template : _.template($('#page1').html()),
  render : function() {
   $('#container').html(this.template());
  }
 });
  
  
 var AppViewPage2 = Backbone.View.extend({
  template : _.template($('#page2').html()),
  render : function() {
   $('#container').html(this.template());
  }
 });
  
 var AppViewPage3 = Backbone.View.extend({
  template : _.template($('#page3').html()),
  render : function() {
          $('#container').html(this.template());
  }
 });

The code for each AppViewPage is quite simple stereotypical, for illustration purposes.
We use the underscore library's api _.template( ) to load a template string
And in the view's render method, we simply assign html content of the div with id "container" using familiar jQuery syntax.

Next up is the definitions of the template themselves. These are html templates containing valid html elements.



<script id="page1" type="text/template"> <div class="view"> <h2>This is Page 1</h2> <a href="#page2">Goto Page 2</a> </div> </script> <script id="page2" type="text/template"> <div class="view"> <h2>This is Page 2</h2> <a href="#page3">Goto Page 3</a> </div> </script> <script id="page3" type="text/template"> <div class="view"> <h2>This is Page 3</h2> <a href="#page1">Back to Page 1</a> </div> </script>

Thats it! When you access the above html in browser, it should show the following screens with proper navigation when clicked on the hyperlinks.

Notice that the hrefs in the templates, refer to relative URLs, with values like "#page1", "#page2" and "#page3". This is same as the values we specified in the mapping in our router definition.

Now that we are comfortable with navigating between views, using backbone. Lets turn our attention to features called model and collection provided by backbone.

Lets jump right in by defining a model and collection and try to use the same in our view.

 MyModel = Backbone.Model.extend({
  defaults : {
   title : 'Default Title',
   status : 'Initiated at '+new Date(),
   attrib1 : 'Value1',
   attrib2 : 'Value2',
   attrib3 : 'Value3'
  }
});

 MyCollection = Backbone.Collection.extend({
  model : MyModel,
 });
 
 var myCollection = new MyCollection();
 myCollection.add(new MyModel({title:'Page1'}));
 myCollection.add(new MyModel({title:'Page2'}));
 myCollection.add(new MyModel({title:'Page3'}));
 myCollection.add(new MyModel());

The above code defines a MyModel and MyCollection. We then instantiate a MyCollection object and add 4 MyModel objects with custom titles.

When the template is attached to the view, we need to additionally pass the collection as a template parameter. This can be done as shown in the code below:

  
var AppViewPage1 = Backbone.View.extend({
template : _.template($('#page1').html()),
   render : function() {
 $('#container').html(this.template({mydata:myCollection.toJSON()}));
   }
});

The template itself needs to be tweaked to iterate over the collection and start displaying the passed data parameters. This can be easily done as seen in the snippet below: <script type="text/template" id="page1"> <div class="view"> <h2>This is Page 1</h2> <h2>Data on page:</h2> <% _.each(mydata, function(row) { %> <%=row.title%> <br> <% }); %> <br><br> <a href="#page2">Goto Page 2</a> </div> </script>


Apart from above mentioned features, the backbone model does provide the following important features:

Ability to listen to changes in model
In the model's initialize function, we can listen for changes to specific model attributes as follows:

initialize: function(){
            this.on("change:myattrib1", function(model){
                var newvalue = model.get("myattrib1");
                alert("Changed myattrib to " + newvalue );
            });
}

Interact transparently with a REST service back end
On the model we can invoke stock framework methods like save( ), destroy( ) and fetch( ), which result in HTTP methods PUT, POST, DELETE and GET, getting fired under the hood by the framework against a URL specified in the model's attribute called 'urlRoot'.

Thus there is no need to explicitly use jquery or ajax to make server side requests, the backbone.js model does it for you transparently.

    var UserModel = Backbone.Model.extend({
        urlRoot: '/user',
        defaults: {
            name: '',
            email: ''
        }
    });

    var user = new Usermodel();
    // Notice that we haven't set an `id`
    var userDetails = {
        name: 'Ganesh Ghag',
        email: 'ganeshghag@gmail.com'
    };

    // Because we have not set a `id` the server will call
    // issue a post  /user with a payload of userDetails data above
    // The server should save the data and return a response containing the new 'id'
    user.save(userDetails, {
        success: function (user) {
            alert(user.toJSON());
        }
   })

Support for Model data validation
There is a provision in the backbone model to provide standard callback to validate model data before submission to server and also to raise error( ) callback in case validation fails. This is depicted below:

// If you return a string from the validate function,
// Backbone will throw an error
validate: function( attributes ){
            if( attributes.age < 0 ){
                return "Negative values are not allowed";
            }
},
initialize: function(){
            this.bind("error", function(model, error){
                alert( error );
            });
}

So far we have been able to use backbone to display views, navigate between views and bind and show model data and collections, into the views.

Lastly to attach events to elements in our backbone views is as easy as specifying events attribute of Backbone.View as follows:

SearchView = Backbone.View.extend({

        events: {
            "click input[type=button]": "doBtnClick"
        },
        doBtnClick: function( event ){
            alert( "from inside search button click" );
        }
}

});

With this we have covered most basics about the the backbone framework. You should now be heading towards more advanced tutorials on backbone.

Cheers!