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
2. Get the current portal user (see listing 5).
Listing 5. Get current portal user
3. Get the user id of the current portal user (see listing 6).
Listing 6. Get user id of current portal user
4. URL Creation.
When logging in to the JForum Web application, the first page displayed is the log-in page. A user enters his user id and password, and then clicks the Submit button to submit this log-in form.
The JForum Web application receives this form request, validates the user id and password against the jforum_users database table, and then displays the category page that presents all the categories this user is authorized to access. This log-in page is generated by the forum_login.htm file shown in listing 7.
Listing 7. forum_login.htm file
Since we will log in the current portal user by programming from this .htm file, we can construct the following URL to skip the log-in page and display the category page directly, if the user is validated by the JForum Web application:
5. Log in to JForum Web application.
The iFrame portlet applies the following iFrame tag to log in the JForum Web application:
Then, when the portal user goes to this iFrame portal, the JForum Web application is invoked, and it will log in the portal user automatically, using the user id that is the third parameter of the above http request.
Finally, the JForum Web application sends the category page back to the iFrame portlet, so that it displays the JForum categories that this portal user can access, without prompting the user for his user id and password to log in the JForum Web application again.
Changing the look and feel
Each JForum Web page includes a header section and a footer section. After log in to the JForum Web application, the iFrame portlet displays the JForum Web page with the header section and the footer section. However, this is not consistent with the look and feel of a Portal site for clients, so we must customize the JForum Web pages to remove the header and footer sections.
We can do this by modifying several JForum .htm files, such as header.htm, bottom.htm, folder_description.htm, forum_list.htm, forum_show.htm, and post_form.htm files, commenting out those table rows that display the header and footer sections.
After these modifications, the JForum Web application displays the JForum Web pages in the iFrame portlet without the headers and footers from the JForum Web application. When you go to the iFrame portlet, it displays all the JForum categories you can access, as shown in figure 1.
Figure 1. Categories user can access
If you click the forum link, in this case, Test Forum, the iFrame portlet will display the topic view page as shown in figure 2.
Figure 2. Topic view page
Finally, when you click the topic link, in this case, Support JForum – Please read, the iFrame portlet will display the message view page as shown in figure 3.
Figure 3. Message view page
You should now be familiar with the steps to integrate the JForum Web application with WebSphere Portal, using SSO. This process includes importing a data directory of users and groups into JForum database tables, modifying the JForum log-in codes, issuing a URL from an iFrame portlet, and customizing the JForum Web pages to change their look and feel to fit into a Portal site.
You can use these steps to integrate the JForum Web application into your WebSphere Portal site for your clients, or you can follow this approach to integrate other Web applications into a WebSphere Portal site with SSO, if applicable.
JForum home page:
developerWorks WebSphere Portal product page:
About the author
Yixing Gong is a Senior Architect, dual certified by IBM as an IT Architect and IT Specialist. He has worked on architecting, designing, and building enterprise Web applications on IBM WebSphere Application Server, enterprise portal applications on WebSphere Portal, and SOA-based, business-process portals on WebSphere Process Server since these products' inceptions. He holds a Ph.D. degree in Computer Science from the Technical University of Nova Scotia, Canada. You can reach him at email@example.com