In this post I’ll demonstrate how the same principle can be applied in a Grails application.

Basically, just about everything from the previous post is the same, except for how the filtering of requests and the sending of the cookies from the host application is performed.

In Grails it is simple to write web filters. Just create a Groovy class with a name that ends with ‘Filters’ in your conf folder and add closures that define the filtering behaviour:

class MyFilters {
    def filters = {
        myFirstFilter(controller: '*', action: '*') {
            before = {
                  //code here is executed before the controller has been accessed
            }
            after = {
                  //code here is executed after the controller has been accessed
            }
            afterView = {
                  //code here is executed after the view has been rendered
            }
        }
    }
}

in this example, there is a single filter called ‘myFirstFilter’ that will be applied to all actions on all controllers, which illustrates the three filtering points available in Grails.

So given a Grails application service called ‘userService’ that returns us a domain object for the currently logged in user, then we could write a cookie sending filter which uses the SSO plug-in like this:

class SecurityFilters {
  def userService;

  def filters = {
    jForumSecureSSOCookie(controller: '*', action: '*') {
      after = {
        if (userService.getUser()) {
          def user = userService.getUser();
          def encryptedValues = SecurityTools.getInstance().encryptCookieValues(user.email, user.username);

          Cookie c = new Cookie(SecurityTools.FORUM_COOKIE_NAME, encryptedValues)
          c.maxAge = -1;
          c.path = "/"
          c.comment = "SSO cookie for language spider forum"
          response.addCookie(c)
        } else {
          //user is not logged in so kill the cookie
          //(removing cookies does not work reliably in all browsers)
          Cookie c = new Cookie(SecurityTools.FORUM_COOKIE_NAME, "")
          c.maxAge = -1;
          c.path = "/"
          c.comment = "SSO cookie for language spider forum"
          response.addCookie(c)
        }
      }
    }
  }
}

Because, Grails runs in a Java environment, all other configuration, including the JAR file deployment remain as discussed in the previous post.

As the SSO code I wrote didn’t have any dependency on our applications classes, I decided to package and release it as a JAR file that anyone can use.  If you’d like to use it, then you can download it from the tools page on this website; instructions on how it words and how to configure JForum to use it are detailed below.

Integrating JForum into an existing application

JForum is indented to be used as either a stand-alone forum, or as an integrated solution for existing sites. The simplest way to integrate JForum with an existing application is simply to deploy it as a second named application under the same domain. For example, if your application is running on a server at:

http://www.myapplication.com/

then just run the JForum application under the same domain as a separate application, for example:

http://www.myapplication.com/forum

you can then just link to it from your web pages. Customise the JForum page templates to look like those from your own application and you’re almost done.

The last thing that you’ll want to do is automatically log users in to the forum once they’re logged into your application. If you don’t do this then your users will have to re-register with JForum just to use the forum pages! Fortunately, JForum ships with a simple SSO module. Unfortunately it’s not very secure.

If you’re running JForum on the same domain as the application your are integrating it with, then cookies set by one application will be visible to the other; as far as the browser can tell, its interacting with a single application. The standard SSO solution that ships with JForum exploits this fact and if your application sets a cookie with the user’s screen name and email address, JForum will automatically log them in to the forum pages for you.

This is a neat and simple solution but it does have a real security hole. If a hacker decides that they want to log into the forum and post messages as another user, then all they need to do is make their browser send a cookie with the name and email details of the users account they want access and JForum will then just log them into it. This is easy to do with something like Firefox’s firebug plug-in and doesn’t require any great skill.

JForum does provide an API with hooks for implementing your own SSO integration. In the JForum documentation, the example demonstrates how, in addition to receiving the user’s credentials (again via a plain text cookie), you could make calls to your database to access further user information. This does not address the security issue outlined above. Further work is required to achieve this.

A more secure solution

In the solution I developed, rather than sending a plain text user name to JForum in a cookie, an encrypted value is passed between the applications instead. By using a strong encryption algorithm it is possible to authenticate the user just once in the main application, and then send an encrypted token in the cookie that can be used to authenticate the user in JForum. This approach has the distinct advantage of preventing any hackers from being able to spoof user names by simply sending them in a cookie.

So, for example, if you encrypt your user’s name and email address before sending them in a cookie, anyone examining the cookie data will see something resembling:

b259fa5bb42d8c53280c54bbb16d9b814574443d903eb85ba5594ef58b374c8d

this can be decrypted by JForum and the users name and email address retrieved from it.

Configuring and using the JForumSecureSSO plug-in

The steps involved to use this plug-in are:

1. Change the default encryption password used
2. Install the JAR file in each of the applications
3. Implement a cookie filter for your application
4. Configure JForum to use your encrypted cookie

Lets look at these in more detail:

1. Change the default encryption password used

If you take a look in the META-INF folder in the jforum-secure-sso.jar file you’ll find a properties file that contains a property called security.password. The default value for this property is ‘change this’.

This property value is the password used by the encryption libraries as a seed for the encryption that is carried out on the cookie data. Update the JAR file by changing the password to a value that only you know – you should make this at least 16 chars long.

Note that you won’t use this password anywhere else in your application so you could just enter some random characters here.

2. Install the JAR file in each of the applications

Copy the JAR file with the modified password into the WEB-INF/lib folders of both your application and JForum too. This ensures that the encryption routines in the JAR files will now both be using your secret password when encrypting/decrypting the data.

3. Implement a cookie filter for your application

In order to ensure that an encrypted cookie is sent for any authenticated users, you’ll need to add a little functionality to your application.

There are a number of variations on how you might do this depending on the security system that you are using. For this reason, there are no classes in the JAR file that do this for you – time for you to cut a little code!

Generally, the best way to send the cookie will be from within a Web Filter. These are a standard feature since Servlet 2.3 specification and are are supported by all but the most antique application servers. The filter should be applied to all URLs that your application supports and will need to send an encrypted cookie, something like this:

import uk.co.smartkey.jforumsecuresso.SecurityTools;

//get your user's details from wherever they are available in  your application
User user = session.getAttribute('user');

//encrypt them using your secret password
String encryptedData = SecurityTools.getInstance().encryptCookieValues(user.getEmail(), user.getUserName());

//send the cookie using the predefined cookie name
Cookie c = new Cookie(SecurityTools.FORUM_COOKIE_NAME, encryptedData)
c.maxAge = -1;
c.path = "/"
response.addCookie(c)

4. Configure JForum to use your encrypted cookie

In the JForum configuration file, you’ll need to set the following properties to ensure that your data is loaded and used to log your users in using SSO:

authentication.type=sso
sso.implementation=uk.co.smartkey.jforumsecuresso.JForumSecureSSO
sso.redirect=http://www.myapplication.com/login.jsp

More details of these settings are available at the JForum web site.

Comments

If you think this could be of use to you, then you can download the distribution files from our tools page. This project has been tested to work with JForum 2.1.8 running on Tomcat 6 and is built using Maven. The source code is included in the distribution and is released using the same BSD license as JForum. If you’d like to add any functionality, I’ll be happy to include it in a future release.