Before I get started: In my last column, I presented some numbers comparing WebSphere and Tomcat. Those numbers elicited some interesting responses, and one in particular from David Morris made me decide to give Tomcat another shot. The reason is that the version of Tomcat shipped with the iSeries (Version 3.2.4) is considerably behind the current open-source version of Tomcat, Version 4.0.3. I was surprised by the results, which can be found at the end of this column as sort of a reprise.

Now on to the meat of this edition. One of the options I presented in my reader poll was comparing the classic HTTP server to the powered-by-Apache version. While I plan to explore this in some more detail, I thought I'd introduce the concept by talking about something that should be near and dear to the heart of every Web application designer: security. Internet security and HTTP servers are closely related because the HTTP server is the point at which the security protocol is defined. The HTTP server determines which users can access your machine and which applications they can access. Once they actually start the application, however, you then need to determine how to ensure that the application is running under the appropriate OS/400 user profile. Covering the entire spectrum will require two articles.

In this article, I will address the following issues:

1. Conversation security--how to secure the conversation between the browser and the Web application
2. User IDs and object security--what a user ID is and how it's used for security purposes
3. Identifying users--how to authenticate the user attempting to access the Web application
4. Web page access--how to use the user ID to determine which portions of your Web application a user can access

In my next column, I will address the next set of topics:

1. Invoking the business logic--how you actually run the business logic once the Web application is started
2. Using the toolbox--how to directly call non-Java programs, using the powerful ProgramCall class in IBM's Java Toolbox for the AS/400
3. Switching User Profiles--how to use the user ID to determine under which user profile the application will run

Conversation Security

Traditional HTTP conversations, those using port 80 in a typical Web serving setup, are unsecured. The traffic that passes back and forth over the wire is "in the clear," meaning that the information is transferred in TCP/IP packets that are not encrypted. You may not realize this, but a decent freeware packet-sniffing tool can allow anybody on your LAN to view every packet you send and receive. If your conversation is in the clear, it's easy for anyone to see everything you're doing. In fact, if you're on a cable modem, it's conceivable that your neighbors could actually view all your traffic.

Gives a whole new meaning to the phrase "neighborhood watch group," doesn't it?

There are various ways to provide secure Internet access, including encryption. One encryption technique uses Secure Sockets Layer (SSL) and digital certificates. Together, these technologies encrypt your Internet conversation and prevent eavesdroppers from grabbing important information. Another encryption option is a virtual private network (VPN). With a VPN, a "tunnel" is created between two IP addresses. This tunnel passes secured information back and forth over the Internet, connecting the two devices as if they were on the same network. This is a way to allow an Internet user access to some or all of the resources on a LAN without opening up the entire network to the outside world.

In any event, encryption is outside the realm of this column. I brought it up just in case you wanted to review your current Internet practices. This column is about user authentication. In the HTTP protocol, this is done through the "challenge" mechanism, wherein the browser pops up a little window asking for user ID and password.

(Note: Digital certificates can also be used for authentication purposes, provided the target Web site accepts them. Both the classic HTTP server and the powered-by-Apache server can handle client digital certificates, but that's a different topic for a different day.)

User IDs and Object Security

The common denominator among most security setups is the concept of the user ID. A user ID in UNIX is similar to a user ID in Windows and to a user profile in OS/400. In all cases, the operating system somehow prompts for a user ID and password; if they're valid, the user is granted certain rights to system resources. And this is where things diverge rather quickly.

OS/400 grants authority to objects based on either user profile or authority list. It's a bit more complex, of course, with concepts like public authority and group profiles coming into play, but the general idea is that access to an object is determined directly by the user profile used to sign on.

In UNIX, security is also based on the user ID, but the mechanism is quite different. Everything is treated as a file, and access is given to each file via a set of security bits. I won't go into detail here, but there are basically three levels of security: public, group, and owner, all of which can be changed by the "chmod" command. Click here for a quick overview of Unix permissions.

While fine for a certain level of security, the permission bits are pretty rigid. In order to provide more flexibility, files can have permissions specified in an access control list (ACL). The interaction between permission bits and ACLs can be complex and is outside the scope of this column.

Interestingly enough, the concept of UNIX-like security is becoming more and more relevant to iSeries users, ever since the advent of the Integrated File System (IFS). Until the IFS was introduced, OS/400 (at least to the programmer) recognized only a single, flat layer of libraries, and those libraries contained objects. That was as deep as the hierarchy ever went. The only exception was data files, which had one more level, that of file members. Back in the S/38 days, you addressed an object by its name and library: MYPROG.MYLIB. One of the biggest changes in the move to the AS/400 was the change in syntax to library/object naming, as in MYLIB/MYPROG. At the time, many of us thought that this might signal the eventual introduction of nested libraries in OS/400, such as MYLIB/MYDEVLIB/MYTESTLIB/MYPROG. This never came about; instead, the IFS was introduced, which supported many different types of file systems all under one roof, with the QSYS library system being just one of them.

While our original authority concepts--user profiles, object authority, and authorization lists--are still valid, the IFS brings a whole new set of requirements and capabilities to the table. In essence, the Change Authority (CHGAUT) command combines the features of Grant Object Authority (GRTOBJAUT) with those of chmod. You might want to take some time to find out more about how IFS security works and how the UNIX-like capabilities of the CHGAUT command are integrated with the OS/400 concepts of object authority and authority lists. Click here for a good overview of the IFS, information on using chmod, and a good overview of QShell.

Identifying Users

Both IBM's classic HTTP server and the new powered-by-Apache server support various ways of authenticating users. Notice that I'm talking about the HTTP servers, not the Web application servers (WebSphere and Tomcat). That's because user authentication is performed by the HTTP server. The authenticated user name (if there is one) is passed to the servlet via the getRemoteUser method of the HttpServletRequest object.

Both classic and powered-by-Apache support authentication using either a standard validation list or a Lightweight Directory Access Protocol (LDAP) directory. The simplest method is the validation list. In both classic and powered-by-Apache, you can set up a validation list that contains a list of user IDs and passwords. Normally, this information is stored in a validation list object on the iSeries (an object of type *VLDL). You can also store the information in a group file, which allows even finer tuning of access control. Click here for an overview of group files and validation lists from IBM's Technical Studio and an in-depth guide to protecting your server in IBM's WebMaster's Guide.

LDAP is an industry standard (no matter how loose the term has become) for providing access to objects in a distributed environment. LDAP underwent some major changes in its formative stages. For example, LDAP Version 2 supported Kerberos authentication, while Version 3 has deprecated that in favor of Secure Authentication and Security Layer (SASL) support. LDAP V3 is a proposed standard, while LDAP V2 is a draft standard. I'm reasonably sure that everyone is moving toward V3, but you'll need to do more research to figure that out. I suggest starting at the OpenLDAP Web site.

Finally, both servers provide an additional technique for identifying users. With this method, the information entered at the HTTP challenge is validated against existing iSeries user profiles. While this technique has certain appeal, there are some disadvantages, which I'll explore in more detail in another article.

Web Page Access

Okay, we've gotten to the point where we have identified a user. How does this allow access to a given Web page? That depends on the HTTP server. This is where the classic HTTP server and the powered-by-Apache server begin to diverge.

With the powered-by-Apache server, you create contexts, which are in effect directories within your application. Each context has its own set of attributes, one of which is the authentication scheme. If you have multiple directories, you must specify the authentication for each directory individually. It's not particularly difficult, but if you need to change several contexts from, say, basic authentication to LDAP, you must do it for each one.

Conversely, with the classic HTTP server, you create entities known as "protection setups." A protection setup defines the various authentication criteria. It can use anything from a simple user ID and password validated against the iSeries user profiles to a combination of client-side digital certificates and authentication against a validation list, as well as anything in between. Once you've defined one or more protection setups, you can then use them to protect directories within your Web application. You can specify different protection setups at different levels quite easily. Not only that, if you want to change a group of related directories, you can assign them all to the same protection setup and then just change that protection setup.

One final difference is that, with the classic HTTP server, you can also specify access control lists (ACLs) for individual directories. This technique allows you to define the access to a directory regardless of the server instance accessing it. It's less flexible, but it's a way to have global access settings that cross HTTP server instances, without having to repeat them for each instance.

Your Choice

In this article, I've covered the basics of user authentication and how to use this authentication to secure the components of your Web application. At this point, you should be able to decide which authentication method fits your needs and be able to define your application in such a way that you can allow different groups of users access to different parts of your application by placing them in separate directories (or contexts, in Apache terms). However, this only determines how the users get in. What they can do once they gain access is covered in the next column, where I'll explain how Internet security and OS/400 object security are related.

Tomcat Statistics Reprised

I promised that I would include an update of my Tomcat performance numbers. Well, with a lot of guidance from David Morris, I managed to install the open-source, standalone Tomcat Version 4.0.3 in about an hour. In another 30 minutes, I configured the server to run applications converted by my PSC400 product. I then ran my standard battery of tests and got some pretty surprising results.

To review, my test was a series of 20 panels of varying sizes. The total communication for all 20 panels was 5KB up and 80KB down. Test #1 ran three simultaneous clients executing the test three times, while the Test #2 ran 20 simultaneous clients each repeating the sequence 20 times. All were run on a small Model 270 with zero interactive CPW and 370 batch CPW. Figure 1 shows the results, averaging the values over all 20 panels:

Figure 1: Average response time comparison, WebSphere and Tomcat

To my surprise, the standalone Tomcat outperformed WebSphere pretty significantly at low volumes and was almost identical in performance at high workloads. Not only that, but Tomcat 4.0.3 seemed to stay consistent throughout the test (unlike the Version 3.2.4 I tested last month). That consistency can be seen in the graph of average response time, shown in Figure 2.

Figure 2: Average response time, Tomcat 4.0.3 standalone, 20 users, 20 passes

Each line of Figure 2 shows the response time for each user for one of the panels in the test. Some panels took longer than others, but the point is that the timings were very consistent throughout all the users; there was no slowdown due to extended system load like I saw in the Tomcat 3.2.4 results in my previous column.

Now, you need to be careful with this data. While it seems that this is an unadorned vote in favor of Tomcat, it's not quite that simple. Standalone Tomcat doesn't include the full-blown Apache HTTP server, and configuring standalone Tomcat isn't exactly straightforward, especially when it comes to accessing files in the IFS. Then again, I was able to configure the machine in about 90 minutes, even though I am by no means a Tomcat expert. Doubtless, my experience with WebSphere and Tomcat on the iSeries helped, but even so, it wasn't like it took me a week to figure everything out.

Also on the negative side, Tomcat occasionally behaved oddly, primarily with session management. In order to recover, I had to stop and restart the server. Since I haven't taken the time to fully diagnose this problem, I can't really blame Tomcat, but I'd certainly suggest that you use a heavy-duty stress tester like Web Roller before putting Tomcat into production.

Joe Pluta is the founder and chief architect of Pluta Brothers Design, Inc. He has been working in the field since the late 1970s and has made a career of extending the IBM midrange, starting back in the days of the IBM System/3. Joe has used WebSphere extensively, especially as the base for PSC/400, the only product that can move your legacy systems to the web using simple green-screen commands. You can reach Joe at This email address is being protected from spambots. You need JavaScript enabled to view it..