Secure single sign on (SSO) for JForum
I recently developed a web application that used the excellent open source project JForum for its forum pages. The one thing that was missing from JForum though was a secure SSO module. In this article I’ll explain why the SSO solution bundled with JForum was not secure enough for our purposes and I’ll show you how I solved this problem.
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:
- Change the default encryption password used
- Install the JAR file in each of the applications
- Implement a cookie filter for your application
- 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.

November 5, 2009 - 10:50 am
Thanks for this. I just installed it and it worked first time.
Akesh.
April 16, 2010 - 12:52 pm
Hi!
Iǘe trying to implement sso into my app with jForum.
In my case, I am installing jForum at the same level of my app Ex.:
http://localhost:8080/app
http://localhost:8080/appForum
Everytime I try to use sso, I get logged as ANONYMOUS. The same happened after I completed your tutorial.
My question is, is the problem the folder structure of my projects? If so, there is a way to make it work without the need of changing my folders’ structure?
thanks
April 17, 2010 - 1:06 pm
It shouldn’t be a problem with the folder structure. As far as the browser is concerned it is interacting with the same server so it will send the same cookies for each request.
If you’re getting logged in as ANONYMOUS, then it looks like the cookie from your application is not being recieved by JForum.
Check the simple things first: do you have cookies enabled? Try using Firefox and use its cookie manager to examine the cookies for localhost. You should see one like that described in this article.
April 28, 2010 - 12:57 am
Hey! I could get it working. I don’t really know what was happening.
Now I have the following issue. I think its the way firefox works with cookies. No matter if I set the age of the cookie to 0 and add it again, the firefox keeps it until I close the browser.
April 28, 2010 - 8:08 pm
That’s what cookies do…. you need to delete it if you want to get rid of it immediately. Zero means delete when the browser closes, like a web session with a shop for example.