If money is your hope for independence, you will never have it. The only real security that a man will have in this world is a reserve of knowledge, experience, and ability.
—Henry Ford

Ah, it's been a long time since I went on a serious rant. For some time now, I've been the kinder, gentler Joe Pluta, with lots of time spent telling you the wonderful new things in both the IBM product lines and the larger IT world in general. I've managed to be diplomatic and even docile.

Not this time, baby.

This is going to be a little bit of an old-school Pluta article. I will pull no punches, and I may bruise a few sensibilities in the process. But the topics I deal with today need to be discussed, and they need to be discussed now.

My primary topic will be the various types of Web users and their access to objects on your System i. In the course of the article, I'll cover various approaches to Web application security. Many of these topics came up during my discussions at iSeries DevCon last week in Las Vegas. I go every year and present a whole slew of seminars and labs primarily on Web architectures and WDSC (and this year I even threw in a little EGL). I've been doing this for years, but this time a lot more people were asking specific questions about Web applications, and one of the big issues was security.

User Security

The number one topic for Web application security is actually a "twofer." User security is really two topics rolled into one: authentication and authorization. We need to separate these two. Authentication simply means ensuring that users are who they say they are. The most common form of authentication is a password, although it can range from nothing to biometrics to single sign-on (SSO), where in effect one machine tells another machine, "This guy's OK. Let him in." This is where Kerberos comes into play, and frankly I don't spend a lot of time trying to decide which way to recommend. How you determine user identity is a corporate decision. Some people insist on long, random passwords. This can lead to the "Post-it" exploit, because people tend to write their passwords on Post-it notes and leave them near (or sometimes even on) their terminals. Others are using SSO, but they're putting all the control on a Windows server. That's a scary thought to me: allowing access to my most secure machine based on the say-so of arguably the most exploited platform ever created.

On the flip side, authorization determines who can do what to whom. In the i5/OS world, that's typically done through object authority, while Apache accomplishes the same thing through authorization directives. In either case, the concept of authorization is that once you've authenticated someone, you now know what they can do. One major difference between the Web world and the System i is the fact that i5/OS doesn't really support the concept of an "anonymous" user. Even if the user is technically anonymous, they'll still need to run under a specific user profile.

User Types

In general, there are four broad categories of users: unauthenticated (anonymous) users, authenticated business-to-consumer (B2C) users, business-to-business (B2B) users, and internal users. Each is very different.

Let's start with anonymous access. Although there are more and more online shops, the majority of SMBs have no need for this sort of application; they allow anonymous access only to static content. However, in some cases, you might allow anonymous users to run Web applications. A good example is a shipment-tracking application. A direct-to-consumer storefront will probably want to allow anonymous access as well. Remember, though, that if you have to run a program on the System i, you will need a user profile. I recommend one umbrella profile for all your anonymous access, making sure that you log information like the IP address in each transaction just in case you need to do some cross-checking later.

Authenticated B2C users are a slightly different story. These are consumers for whom you've stored preference information and buying history to make it easier for them to use your site and also easier for you to pitch them more goods or services. They start out as an anonymous users and then create profiles, complete with user IDs and passwords. It is very unlikely that you will want to create a separate user profile on the System i for every Web user. Again, you will probably instead want an umbrella user profile that these users will run under. The user ID and password will be authenticated some other way, typically through your HTTP server and its standard validation technique (for example, Apache has several standard authentication techniques, including a text file, an ISAM database, and SQL tables). This user ID will be used primarily to retrieve their preferences. They'll need a user profile only when they have to run a System i program; at that point, they'll use a common user profile set up for this type of transaction (in this case, logging the authenticated user ID along with the IP address).

B2B users are somewhat more complex. Whereas B2C clients typically see little system data (with the possible exception of their current order information), B2B users are typically your clients or vendors who need to actually see or even update live production data on your machine. While any access to the data is obviously controlled through an application just like a B2C user, this is the first situation where concepts like group authority come into play. For example, certain B2B users may be "administrators" who can look at data for any user within their company. So you may need to implement some level of group access, while at the same time taking the utmost care to make sure that Vendor A can't see data for Vendor B. You may have one user profile per B2B user, or you may have a small number of more role-based profiles for each B2B company. You may or may not allow them to create their own users on the fly.

Finally, you have internal users. These are users who will be doing their job via the browser instead of via 5250. The reasons for this move are many, ranging from the ubiquitous nature of the client (you don't even have to install an open-source 5250 client like TN5250, much less iSeries Access) to the removal of the interactive tax to the ability to have a richer user experience. With the exception of a few power users and possibly your security administrator and/or operations functions, many SMBs can move the majority of their users to the Web. Given the nature of these users, there will be a user profile for each user, and depending on your security procedures, they may be given their password. These are not profiles that are added by user action.

Here, then, is the table of user types:

*Setup depends on your relationship with your business partners as well as their business needs.

Note that the "Add New Profiles" column pertains to the users themselves adding profiles, not the System i administrator. Obviously, the System i administrator will need to add profiles for all of these types.

Web User IDs vs. System i User Profiles

Now it's time to get specific. This is one of the first places where I will put my foot down.

Even if you have a one-to-one relationship between Web user IDs and System i user profiles, I insist that Web application designers separate the two. What I mean by this is that you should set up user profiles on the System i but use different user IDs and passwords for Web access. As I explained above, anonymous and even authenticated B2C users will probably share one of a very few common user profiles. These profiles can't even log onto a 5250 session; they may be configured with PASSWORD(*NONE), and they will certainly be created with INLMNU(*SIGNOFF). Instead, a traffic cop program will verify that the user (whether anonymous or authenticated) is authorized to run a given application and will then assign the appropriate user profile. This can be done by submitting a job under that profile or by using the profile handle APIs to swap the profile of the job that is handling the request. If your Web application is connecting to the System i via the IBM toolbox, the job will be named QZRCSRVS.

B2B and internal users are somewhat different. You will probably set up one user profile for each of these users, but even so, you will not actually give out the System i user profile and password. Even though i5/OS allows you to directly authenticate HTTP sessions against the user profiles on the system, I always recommend against it. That's because I am vehemently opposed to having System i user profiles and passwords out "in the wild." If you do that, those user profiles can be used to exploit any security holes you have in your system, from FTP to ODBC.

Simple example: If you leave an FTP server up (by show of hands, how many of you actually know whether your FTP server is up?), then users can download any objects they have access to. This includes program objects, message files, data areas, you name it. Files are of course the worst, since i5/OS has no intrinsic row- or column-level security constraints. If users can access a file, they can access all the data in the file. The same is true for ODBC: I'll address this in a little more detail shortly.

Other Topics

Several other topics for basic Web architecture need to be addressed. Some are security-related, and some are not, but I'll list them all here for completeness.

State

I always get a little frothy over this topic, and I'm going to leave the specific discussions for another day, but there are good uses for both stateless and stateful connections. In general, anonymous users need stateless connections while both B2B and internal users should use stateful connections. The case for B2C users depends very much on the nature of your application. If it's primarily a data entry and post scenario (such as a storefront), then I'd probably opt for a stateless conversation, while a more involved situation (such as online banking or other complex transactions) would make it viable to create stateful sessions, with the obvious caveat being that there are some limits on the number of persistent connections you can have. Then again, realistically you're talking about thousands of connections per IP address and there's no reason you can't have dozens of IP addresses, giving you an upward limit approaching a million simultaneous connections. If you have a million concurrent users, you're in Google or Amazon territory: Please drop me an email and let me know what worked best for you!

The Perils of ODBC

This topic always gets me in trouble. Why? Because my stand on ODBC is simple: It's bad. Not sometimes bad, not bad but with good uses, just bad. There are almost no situations where it makes sense to give a user read access to your production data by file and field name ("table" and "column" name in SQL lingo), and there is absolutely no way I would ever allow update access.

Yet I continue to hear from people who insist that it's easy to allow ODBC access or even that it's somehow "right" to do so. One of my favorite phrases is, "It's their data anyway!" That may be true, but the integrity of that data is our job, and allowing unfettered update access to production data makes it impossible to ensure that integrity.

It's very simple: Once you allow users access to a file using ODBC, you have almost no control over that access. They can download every field in every record and review that data at their leisure. The only way you can possibly circumvent this is through an exit program, and that exit program may add significant overhead, especially as it needs to parse individual requests to somehow determine whether the user has access to the files and fields (tables and columns) in the request. And consider the maintenance nightmare that such a program entails; can you imagine trying to maintain a list of tables and columns that each user is authorized to?

If that wasn't enough to get you off of ODBC for good, let me present one other little tidbit: ODBC inextricably binds your client layer with your database layer. All the work we've done with Model-View-Controller (MVC) and all the talk about database independence and so on goes out the window with ODBC. Not only does ODBC require that the user know the names of your files and fields, but also that they understand the internal workings of them. This means you can't change a field name (or even change how a field works) without identifying and fixing every affected ODBC program out there.

If you limit database access to your server applications, then you can make any necessary changes; the user sees only the output of the application, and those applications can be updated immediately if a database change is made. It's a lot harder to update every Excel spreadsheet in your organization that has links to a System i database table.

Note that one of the possible answers to this particular dilemma is the use of trigger programs. But while you can probably lock down a lot of the holes using triggers, the overhead associated with triggers can be enormous. Consider not only the actual runtime overhead of having to analyze every request, but also the maintenance effort to design and create the trigger programs themselves, as well as the potential disruption of your production processes due to the testing process.

FTP Access

This is another often-overlooked loophole. I pointed out earlier that it was relatively easily to just download a file via FTP. The binary data in the file might not be that easy to read (although it's not very difficult either), but with FTP's remote command execution capabilities, you can copy files (including spooled files) to physical files or copy physical files to comma-delimited IFS files and then download them with impunity. As in ODBC, short of turning off the service entirely, the only real security is an exit program. And a malicious user might even be able to do some damage using FTP.

This is the other reason that I insist that designers not put real user profiles and passwords out into the wild. Instead, let the application traffic cop handle the handoff between external Web user IDs and internal user profiles.

Thanks for Tuning In

This is a very touchy subject and one that becomes more complex as your user requirements become more sophisticated. I didn't even touch on the security measures required for making sure that the Web applications aren't being spoofed. That's an entirely different topic for a different day. But I think we covered enough for one round in this article.

Joe Pluta is the founder and chief architect of Pluta Brothers Design, Inc. and has been extending the IBM midrange since 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. He has written several books including E-Deployment: The Fastest Path to the Web, Eclipse: Step by Step, and WDSC: Step by Step. Joe performs onsite mentoring and speaks at user groups around the country. You can reach him at This email address is being protected from spambots. You need JavaScript enabled to view it..

Joe Pluta is the founder and chief architect of Pluta Brothers Design, Inc. He has been extending the IBM midrange since the days of the IBM System/3. Joe uses 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. He has written several books, including Developing Web 2.0 Applications with EGL for IBM i, E-Deployment: The Fastest Path to the Web, Eclipse: Step by Step, and WDSC: Step by Step. Joe performs onsite mentoring and speaks at user groups around the country. You can reach him at This email address is being protected from spambots. You need JavaScript enabled to view it..

---

MC Press books written by Joe Pluta available now on the MC Press Bookstore.

		Developing Web 2.0 Applications with EGL for IBM i Joe Pluta introduces you to EGL Rich UI and IBM’s Rational Developer for the IBM i platform. List Price $39.95 Now On Sale
		WDSC: Step by Step Discover incredibly powerful WDSC with this easy-to-understand yet thorough introduction. List Price $74.95 Now On Sale
		Eclipse: Step by Step Quickly get up to speed and productivity using Eclipse. List Price $59.00 Now On Sale

Also Read

Legacy application modernization: A comprehensive approach to modernize your business

How Low Code Helps Businesses Modernize their IBM i Apps

Why Migrate When You Can Modernize?