23
Mon, Dec
3 New Articles

Weaving WebSphere: Web Application Security

Development Tools
Typography
  • Smaller Small Medium Big Bigger
  • Default Helvetica Segoe Georgia Times


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:

User Type Characteristics
User Type
Web User ID
User Profile
Add New Profiles
Anonymous
No
Common
No
Authenticated B2C
Yes
Common
Web only
B2B
Yes
*
*
Internal User
Yes
One per Web user
No

*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..

BLOG COMMENTS POWERED BY DISQUS

LATEST COMMENTS

Support MC Press Online

$

Book Reviews

Resource Center

  • SB Profound WC 5536 Have you been wondering about Node.js? Our free Node.js Webinar Series takes you from total beginner to creating a fully-functional IBM i Node.js business application. You can find Part 1 here. In Part 2 of our free Node.js Webinar Series, Brian May teaches you the different tooling options available for writing code, debugging, and using Git for version control. Brian will briefly discuss the different tools available, and demonstrate his preferred setup for Node development on IBM i or any platform. Attend this webinar to learn:

  • SB Profound WP 5539More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.

  • SB HelpSystems ROBOT Generic IBM announced the E1080 servers using the latest Power10 processor in September 2021. The most powerful processor from IBM to date, Power10 is designed to handle the demands of doing business in today’s high-tech atmosphere, including running cloud applications, supporting big data, and managing AI workloads. But what does Power10 mean for your data center? In this recorded webinar, IBMers Dan Sundt and Dylan Boday join IBM Power Champion Tom Huntington for a discussion on why Power10 technology is the right strategic investment if you run IBM i, AIX, or Linux. In this action-packed hour, Tom will share trends from the IBM i and AIX user communities while Dan and Dylan dive into the tech specs for key hardware, including:

  • Magic MarkTRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now!  Request Now.

  • SB HelpSystems ROBOT GenericForms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.

  • SB HelpSystems ROBOT GenericIT security is a top priority for businesses around the world, but most IBM i pros don’t know where to begin—and most cybersecurity experts don’t know IBM i. In this session, Robin Tatam explores the business impact of lax IBM i security, the top vulnerabilities putting IBM i at risk, and the steps you can take to protect your organization. If you’re looking to avoid unexpected downtime or corrupted data, you don’t want to miss this session.

  • SB HelpSystems ROBOT GenericCan you trust all of your users all of the time? A typical end user receives 16 malicious emails each month, but only 17 percent of these phishing campaigns are reported to IT. Once an attack is underway, most organizations won’t discover the breach until six months later. A staggering amount of damage can occur in that time. Despite these risks, 93 percent of organizations are leaving their IBM i systems vulnerable to cybercrime. In this on-demand webinar, IBM i security experts Robin Tatam and Sandi Moore will reveal:

  • FORTRA Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:

  • FORTRAManaging messages on your IBM i can be more than a full-time job if you have to do it manually. Messages need a response and resources must be monitored—often over multiple systems and across platforms. How can you be sure you won’t miss important system events? Automate your message center with the Robot Message Management Solution. Key features include:

  • FORTRAThe thought of printing, distributing, and storing iSeries reports manually may reduce you to tears. Paper and labor costs associated with report generation can spiral out of control. Mountains of paper threaten to swamp your files. Robot automates report bursting, distribution, bundling, and archiving, and offers secure, selective online report viewing. Manage your reports with the Robot Report Management Solution. Key features include:

  • FORTRAFor over 30 years, Robot has been a leader in systems management for IBM i. With batch job creation and scheduling at its core, the Robot Job Scheduling Solution reduces the opportunity for human error and helps you maintain service levels, automating even the biggest, most complex runbooks. Manage your job schedule with the Robot Job Scheduling Solution. Key features include:

  • LANSA Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.

  • LANSAWhen it comes to creating your business applications, there are hundreds of coding platforms and programming languages to choose from. These options range from very complex traditional programming languages to Low-Code platforms where sometimes no traditional coding experience is needed. Download our whitepaper, The Power of Writing Code in a Low-Code Solution, and:

  • LANSASupply Chain is becoming increasingly complex and unpredictable. From raw materials for manufacturing to food supply chains, the journey from source to production to delivery to consumers is marred with inefficiencies, manual processes, shortages, recalls, counterfeits, and scandals. In this webinar, we discuss how:

  • The MC Resource Centers bring you the widest selection of white papers, trial software, and on-demand webcasts for you to choose from. >> Review the list of White Papers, Trial Software or On-Demand Webcast at the MC Press Resource Center. >> Add the items to yru Cart and complet he checkout process and submit

  • Profound Logic Have you been wondering about Node.js? Our free Node.js Webinar Series takes you from total beginner to creating a fully-functional IBM i Node.js business application.

  • SB Profound WC 5536Join us for this hour-long webcast that will explore:

  • Fortra IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn: