Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

Web Menu security integrates with RPG apps

Jim Mason shows you how to build a Web menu system that delivers user authentication and integration with back-end applications.

There are many options to buy or build Web security front ends for your iSeries applications that you Web-enable. Each option has different benefits and tradeoffs. In this article we'll look at the approach we used to build the ebt-now QuickWebMenu system. It offers key features that need to be addressed in most Web applications:

  • Authenticating Web users with a userid and password
  • Generating custom menus for Web users based on their group profile
  • Sharing Web user session information with iSeries host programs and jobs

This article also describes how we used WDSC tools to build the menu system.

The problem: Authenticating and integrating Web users with iSeries applications

As a Web solutions provider, we help iSeries customers develop and implement many types of iSeries Web applications. A common problem to all of them is how to authenticate Web users for application access and integrate with iSeries host applications. These are the challenges for Web application security:

  1. Authenticating the user -- ensuring the user is who he claims to be
  2. Authorizing the user to applications -- providing a custom menu for authorized applications
  3. Mapping the Web user to a valid user profile on the iSeries
  4. Sharing Web user session information with iSeries jobs for better Web integration

Options to authenticate and integrate Web users

IBM promotes several Web security implementation options centered around J2EE and WebSphere using Lightweight Third Party Authentication (LTPA). Another WebSphere option is authentication of a Web user against iSeries user profiles directly. You could set up user profiles for all Web users.

Web security option Advantages Issues
WebSphere using JAAS
(Java Authentication and Authorization Service)
* Platform independent user authentication and authorization framework
* Common solution for all server applications: iSeries, Windows, etc.
* Optionally can require digital certificates for users
* Many options on security implementation
* No link for Web data, iSeries job
* Complex security model
* Requires significant Java programming to implement
* Requires setting up deployment descriptors for all security roles
Single Signon
* Platform independent user authentication and authorization products for single signon to multiple systems
* Common solution for all server applications: iSeries, Windows etc
* No link for Web data, iSeries job
* Complex to setup
* SSO products are usually expensive
* Requires digital certificates for users or the equivalent
Java Networking and Directory Interface
* Use of LDAP v3 standard directory interface to store user signon information and application lists
* Common solution for all server applications: iSeries, Windows, etc.
* Optionally can require digital certificates for users
* No link for Web data, iSeries job
* Requires significant Java programming to implement
* Requires setting up an LDAP compliant server (iSeries LDAP, Domino Directory, OpenLDAP, etc.)
iSeries Logon * Create user profiles for all Web users or setup in authorization lists
* Doesn't require programming
* Works for WebSphere Express
* No link for Web data, iSeries job
* Does require a lot of manual setup IF you have many Web users
* Only works with iSeries applications
* Not as secure as digital certificates
Web menu security * Not platform or server dependent
* Works with any application server: WebSphere, Tomcat, etc.
* Links Web data with RPG, CL or COBOL jobs
* Common solution for all server applications: iSeries, Windows, etc.
* Setup for many users can be automated easily using WDSC data tools or a simple RPG program
* Covers authentication, menus and Web data integration
* Programming needed if writing the Web menu security application (vs. buying it)
* Cost of Web menu security software if purchasing vs. building
* Not as secure as digital certificates

What the Web menu security system delivers

The Web menu security application reviewed here offers a simple solution to handle the four challenges of Web application security:

  1. Authenticating the user -- ensuring the user is who he claims to be
  2. Authorizing the user to applications -- providing a custom menu for authorized applications
  3. Mapping the Web user to a valid user profile on the iSeries
  4. Sharing Web user session information with iSeries jobs for better Web integration

The first three items are relatively straight forward if you've thought about securing a Web application. The last item is a more advanced requirement. If a user logs on to your Web site, you've authenticated him by looking up his userid and password somewhere. You probably also have identified his company or organization. You not only want to log him on to the iSeries application automatically at this point, but you'd also like to integrate his identity in your RPG or COBOL applications easier.

A simple Web workflow makes this integration need clearer:

  • A user logs on to the Web site with a valid user id and password
  • A custom Web menu is displayed listing his authorized applications
  • The user selects the Order Inquiry option that runs a WebFaced RPG 5250 program
  • The Order inquiry program should display the user's specific orders automatically

To do that, the user's company id had to be passed from the Web environment to the iSeries program so we could display just that company's orders.

There are lots of Web security options, but not many also provide a framework for integrating Web user identities with iSeries applications. The Web menu security system shown here is a simple security option that is appropriate for companies needing simple Web security at a low cost. Some of the other options listed earlier offer richer Web security models at a greater complexity and cost.

Using the Web menu security system

Here, a Web user is presented with a simple logon Web page. The user can enter a valid userid, password and, optionally, a specific protection realm to logon to. If the user doesn't enter a realm, the default realm (blank) is used.

The menu security system finds the associated group profile for the Web user, builds the menu for that group dynamically from the menu database, and displays it on the menu page.

The user can select any menu option. Here we've selected a simple option that calls an RPG 5250 application that was WebFaced. Since the userid and the associated organization id (the user's account numer 026785) was sent from the Web menu application to the RPG 5250 application, the RPG program directly displayed the customers orders.

The RPG application now has access to Web user session information automatically as part of an iSeries job. This greatly simplifies the work in integrating Web user information with iSeries applications.

How Web menu security works

To setup the Web menu security system, an administrator creates records in three files:

  • User
    one record for each user on the system. The user record must identify the corresponding group the user is assigned to.
  • Group
    Each user group to be created has a group name and identifies the name of the corresponding top-level menu to be accessed in the menu item file.
  • Menu item
    The menu item file defines all menu items on all menus. A menu is made up of multiple menu records. A single menu record can point to a URL to invoke a program, run an iSeries command or call another menu.

Typically, companies have only a small number of groups to set up for different types of Web users. In addition, there are a number of menu item records needed to create all the menu options on all Web menus. The largest number of records to add is normally the users. Given that this is just an iSeries table, you could use a number of options (CPYF, WDSC SQL utilities or a simple RPG program) to generate the user records from another file (e.g., a customer, student or employee file).

Below is a screenshot showing a menu item defined for the Orders application and the test1 menu. The option is labeled 'Order Inquiry (pass user id as parm)' on the menu displayed to the user. The actual URL called below is to call a WebFacing Order Inquiry program (strpar) on the iSeries.

Notice the convention for declaring variables in a URL, ${zpara.server} for instance. The variables can be loaded from configuration files, the user records or Web session data. This way, the actual values can be resolved dynamically when the URL is created as a menu option on the user's Web menu. Using variables resolved at runtime not only makes the URLs more secure, but also allows easy changes to the application or security without recompiling and redeploying your application.

For the URL above, variables are declared for many values. The Web user id and password variables are referenced as: ${qwuserName} and ${qwpassword}. Below is a sample configuration table where Web variables OTHER THAN user security information can be declared and initialized. These variables are used to provide a default signon for a WebFacing application. They are stored in the userparms1.txt configuration file in the Web application.

Building a Web menu security application with WDSC

Now that you know how the Web menu security system works, let's see the basic steps used to build this example:

  • Create menu database files
  • Create Web database applications to update the menu database
  • Create a Logon and Menu page
  • Create Struts Action classes and Java beans to handle authenticating the user, building the menus dynamically

Setting up a Web menu database
I've included the DDL for the sample menu tables. You can use WDSC Data perspective tools to import DDL and create tables on the iSeries. You could also use iSeries Navigator to do this.

Creating a Web menu application
If you are using the new version of WDSC (5.1.2 or newer), I recommend using the Java Server Faces wizard in WDSC to create the table maintenance applications ( File > New > Other > Web > Faces JSP File). This is a much more productive way to build table maintenance applications than using the older Database Web pages wizard I used in an earlier release (5.1.0). In Page Designer, it's easy to drag Faces components from the Palette and add them to a Web page (an input text component or a label component for instance). The best part of a Faces application is adding the Relational Record List or Relation Record parts from the Data drawer in the Palette. They allow you to quickly build drag-and-drop subfiles and record forms on a Web page linking to your iSeries tables (here the menu database tables).

You'll need to create a full maintenance application for each of the three tables above: QSUSR, QSGRP and QSMIT. Each application should have the following pages for a table: search. Selection list (subfile), Add, Edit, Delete and View.

Creating a Logon page and a Menu page
I created the Logon page as a simple JSP (Java Server Page) in WDSC's visual Page Designer tool in the Web perspective (New > Other > Web > JSP). I added the Struts tag libraries to the Web page:

<%@ taglib uri="/WEB-INF/struts-html.tld" prefix="html" %>

<%@ taglib uri="/WEB-INF/struts-bean.tld" prefix="bean" %>



This allows you to use the Struts input text field tags and Java beans in your JSP.

The menu page is more complex to develop because it receives the Menu map to build the menu from as session data and dynamically constructs the menu using a Java scriptlet for loop to iterate over the menu options and add them as HTML to the page.

Creating Struts actions and Java beans to handle menus
The simple workflow for the menu application has the Signon.jsp Struts form action invoke a SignonAction class. The Signon Action class uses a SignonProcessor Java bean to lookup the user id and password against the QSUSR table to see if the logon is valid.

If the logon is invalid, the user is returned to the Logon page and the signon errors are listed there. If the logon was valid, the Signon Action class is forwarded control to the Menu Action class. The Menu Action class used a MenuProcessor Java bean to read the menu options from the QSMIT table for the selected application and menu name. The menu processor bean builds a TreeMap for the menu and stores it in a session data variable. The UserMenu.jsp reads the menu map from the session to build the menu.

Summary on Web menu security


About the author: ebt-now StructuredSoft jemason@ebt-now.com

Hopefully this tip gave you some more insight into Web application security and integration when using iSeries applications and data. If you already have a Web menu system that delivers user authentication and integration with back-end applications, you're all set. If not, follow the guide here to productively build the application using WDSC's Web tools. If you don't want to build the application, see the ebt-now Web site for information on buying one. If you want to learn how to build Web applications for the iSeries, ebt-now offers Web-based classes and hands-on labs where you can build a wide variety of iSeries Web applications using IBM's WDSC tools. Jim Mason is president of and training manager at . ebt-now provides iSeries WebSphere Studio training services. StructuredSoft has the StructuredJ Java Web development plug in for WDSC and the open-source StructuredSoft Developer platform for iSeries. Jim is creating a self-study course for RPG programmers that teaches "hands-on" rapid visual development with WDSC for all types of iSeries and e-business applications without the need to become a Java expert. The course will be published by Rochester Initiative. You can reach Jim at .

Dig Deeper on Web Tools

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.