ShowTable of Contents
Single Sign-on (SSO) is a basic requirement for WebSphere Portal to integrate with external Web applications, enabling portal users to go seamlessly to other Web applications without logging in again.
A WebSphere Portal site is an integration of people, business processes, and applications. In many WebSphere Portal projects, clients want to integrate their Portal sites with external Web applications, such as the JForum Web application, to add additional functions such as the discussion board to their Portal sites.
Portal users should be able to access those external Web applications without being challenged to log in again. This article presents a solution to integrate WebSphere Portal with the JForum Web application, using SSO, describing the detailed steps to realize that solution.
After that solution is implemented, portal users can seamlessly navigate the JForum categories, forums, and topics from a portlet of a WebSphere Portal without being asked to log into JForum.
JForum Web application architecture
JForum is powerful and robust discussion board software – a forum – that is implemented in JavaTM. It has been widely known for half a decade and powers many large forums around the globe, including Electronic Arts' gaming forums, JavaRanch (one of the largest and oldest Java communities), GUJ (the biggest Java development community for Portuguese speakers).
It provides an attractive interface, an efficient forum engine, an easy-to-use administrative panel, an advanced permission-control system, and much more. It is an Open Source project, maintained by serious developers.
It's no wonder that many users want to integrate the JForum Web application into their WebSphere Portal sites so that their sites can also offer this efficient discussion-board capability to their portal users.
The JForum Web application applies a role-based, access-control pattern to JForum categories and their contained forums. Users are assigned to user groups, and user groups are associated with categories and forums. Hence, if a user is a member of a user group and that user group is associated with a category and a forum, then that user has the right to access that category and forum; otherwise, he is not able to join either that category or that forum.
To realize this role-based, access-control pattern, each JForum user has an entry in the JForum database table, jforum_users (see table 1). For the purposes of this article, the most important fields of table 1 are username and user_password; a user uses the values in those two fields to log in the JForum Web application.
Table 1. jforum_users database table
The JForum user groups are defined in the JForum database table, jforum_groups (see table 2). You can see that you can also define the parent-child relationship among user groups using this table.
Table 2. jforum_groups database table
The user group membership of a user is defined in the JForum database table, jforum_user_groups (see table 3). The JForum Web application uses this table to determine the user group membership of a user.
Table 3. jforum_user_groups database table
JForum categories, forums, and topics
The discussion board in JForum is organized into categories, forums, and topics. The categories and forums are created by a JForum system administrator, and topics are created by JForum users.
The JForum system administrator uses the JForum administration console to create JForum categories and forums, and to assign JForum categories and forums to JForum user groups.
After that, when a user logs into the JForum Web application, if he is a member of a user group and that user group is assigned to a JForum category and forum, then he can have access to that JForum category and forum, and he can also create topics in that forum.
Importing data from a directory server into JForum tables
Since we are integrating a WebSphere Portal site with the JForum Web application, the users of the JForum Web application are portal users. The information for those portal users and their group membership are usually defined and stored in a directory server for a WebSphere Portal site.
Therefore we must export the data for those portal users and their group membership from that directory server and then import the data into the JForum database tables. For example, suppose we have user1, user2, user3, and user4 in the directory server, and they are the members of the user groups group1, group2, group3 and group4, respectively, in the directory server for a portal site.
We can then export the data from that directory server, construct the SQL statements shown in table 4, and then execute those SQL statements to import those users and their user group memberships into the JForum database tables.
Table 4. Import users and groups into JForum database tables
Directory server for JForum
We can configure the JForum Web application to use an external directory server to authenticate a user by modifying the JForum configuration file SystemGlobals.properties as shown in listing 1.
Listing 1. Modified SystemGlobals.properties file
After that, a user can use their user id and password stored in the directory server to log in to the JForum Web application.
If we integrate the WebSphere Portal site with the JForum Web application, then we should find the user id and password of the current portal user, so that we can use that user id and password to log in a portal user to the JForum Web application automatically by a portlet, not by that portal user.
In WebSphere Portal, a portlet can find the user id of the current portal user from the IBM WebSphere Application Server (WAS) credential. Unfortunately, however, that credential doesn’t store the password of the current portal user. Thus the portlet can’t find the password of the current portal user from the WAS credential, so it cannot log in the current portal user to the JForum Web application using his user id and password.
Therefore it's of no use to configure the JForum Web application with the external directory server that is used by the WebSphere Portal and to use the user id and password against that directory server to log in the current portal user to JForum.
Using the JForum database
Since the current portal user has already been authenticated by the WebSphere Portal site against the directory server, the JForum Web application can trust that user id of the portal user.
The portlet of a Portal site can find the user id of the current portal user from the WAS credential, and that user id has already been imported into the JForum database tables; therefore, we can simply use the user id of the current portal user to log in to the JForum Web application.
To validate a user in the JForum Web application, the validateLogin() method of the DefaultLoginAuthenticator java class is used. This method gets the user id and password of a portal user and then executes a SQL statement to find the user id of that user in the jforum_users table. This is implemented by the Java statements in the try block in listing 2.
Listing 2. Find the user via user id and password
To use only the user id to log in the JForum Web application, we change the code of listing 2's log-in method and the UserModel.login SQL statement, as shown in listing 3.
Listing 3. Find the user via user id only
Also, we need to change the following UserModel.login SQL statement:
Thus the JForum Web application needs only the user id to log in a user into its application.
Using the iFrame portlet
One approach of integrating WebSphere Portal with a Web application is to use the iFrame portlet. WebSphere Portal provides the iFrame portlet out-of-box, and we can customize this portlet to log in the current portal user to the JForum Web application.
The iFrame portlet should get the user id of the current portal user, and then use that user id to log in the JForum Web application. Here are the steps for the iFrame portlet to implement this design:
1. Get portlet service (see listing 4).
Listing 4. Get portlet service