Securing Net.Data

By:  Bob Cancilla
Title:  AS/400 Internet Practioner
Date:  04/10/1999 - 10:47 PM (UCT)

As you may have discovered on this website, Net.Data is the true killer-ap for developing e-Business websites! You have discovered that itÈs easy to use and totally exploits the power of the AS/400 and its database.

A major issue that soon arises once you have configured Net.Data and written a few macros is security and user authentication.

This is the first of two articles that IÈm writing on this subject. This one is generic and lays out the conceptual approach to securing a Net.Data environment. YouÈll find that the principles laid out in this article actually apply to any CGI programming environment and not just Net.Data. The follow-up article will include specific examples and server configuration examples.

You can secure Net.Data macros and support multiple macro directories with multiple Net.Data INI files.

LetÈs consider a company who has asked its "WEBMASTER" to create a website that supports four types of user:

  • General Public Ì this is your standard about your company, products, and services website. There is no security or authentication, anyone can visit the site.

  • Customer Information Ì this area of the site is secure. A customer must "login" to access only their account information. IÈll use my Insurance company as an example here, where we have two types of customer:

  • Insurance Agents Ì these are the companies real customers.

  • Policyholders Ì they must buy insurance via an agent, but we provide information to them as a service to them and our agents.

  • Employee Information Ì lets assume that you want your salespersons to have remote access from anywhere in the world to your website, access customer information, and write orders via the Internet.

To support these different users, we must:

Protect your directories


When you access a website secured with user authentication, the browser requests a page from a secure directory. The server knows based on its configuration that the directory is secure and sends a 401 Access Restricted return code back to the browser. This causes the browser to pop-up its little authentication pop-up screen that asks for a user and password (you see it when you access member areas of IGNITe/400).

The user-id and password are stored in the browserÈs cache for the domain name, authentication realm, and directory that you are attempting to access and the request for the resource is retransmitted to the server with the user-id and password. Every additional request for a secured resource includes the user-id and password as part of the request.

Once you define the rules to the server, authentication is automatic. The authentication mechanism is the parent of cookies and is actually the original cookie. Authentication remains in the browserÈs cache until you exit the browser.

Now the challenge is defining authentication on your server.

Use PROTECTION directives to implement authentication on the IBM HTTP server. On I/NetÈs servers, Netscape, and Apache use directory based configuration.

Server based authentication can support four types of authentication. These types can be mixed and matched:

User Authentication

User authentication uses a user file (validation list on IBMÈs HTTP server) to store user-idÈs and passwords. Basic user authentication validates that the user exists in the serverÈs user file (or validation list), and that the password entered is valid. At present, all servers use an encryption scheme called MD5 encryption to encrypt passwords. It is not perfect, but it is more secure than the average hacker will want to deal with. Very much like IBMÈs user profile security, you as the webmaster will not be able to see a password once it is defined to the server.

The IBM HTTP server is the only server that supports using AS/400 user profiles and passwords in place of a server file or validation list. This is a great facility for dealing with employees who all ready have an AS/400 user profile.

Group Authentication

On all servers that IÈm aware of is implemented by creating a group file in an IFS directory on your server. The group file contains a group name and the user-id of individual users who are members of the group. The IBM HTTP server offers an incredibly flexible arrangement allowing you to embed groups within groups. NCSA servers (WebServer/400, CommerceServer/400, Netscape, and Apache) offer a simpler construct where you have

GROUP:USER (i.e. AGENCY:BOB where a user named BOB is a member of the AGENCY group).


IP Address Authentication

This form of authentication restricts access to a directory to a fully qualified or generic IP address. I do NOT recommend ever using this form of authentication since users from AOL and other proxy based ISPÈs will never be able to access your website. AOL may change the userÈs IP address on every access to the server.


Domain Name Authentication

Just like IP authentication, you can also restrict access to persons accessing your site from specific fully or generically qualified domains. This is a particularly costly form of authentication. To use domain name authentication the server must look up and resolve the userÈs IP address using reverse DNS. Most people donÈt want to incur this cost.


Authentication Rules

Authentication implements two simple rules. They are REQUIRE and DENY. Permit allows a user to access a secured directory and DENY prevents a user from accessing the directory.

You could write a set of rules which states:



An important feature of sever authentication is the HTTP METHOD. You must specify the METHOD that the authentication rule applies. I specify GET which support general HTML page access and POST which supports my HTML forms. There are other methods which you may or may not include in your rule.

Defining users for the example (top)

In our example, we will use USER authentication and GROUP authentication.

We will use %%SYSTEM%% for employees which will cause the server to authenticate against the AS/400 user profiles for employees.

We will create a single VALIDATION LIST (or user file) to store policyholders and insurance agents.

We will create two groups, one called AGENT, and one called POLICYHOLDER.

We will define policyholders to the POLICYHOLDER group and insurance agents to the AGENT group.

In my web sites, I allow users to enroll themselves and maintain their own passwords and account information. To do this you will need a program that calls the IBM API to add a user to a validation list and will have to use Net.DataÈs flat file interface (FFI) to maintain the group file. I/NET provides commands. APACHE requires FFI to maintain the configuration files, as does NETSCAPE. Both Netscape and Apache provide APIÈs to add a user. The issue here is the password encryption. The APIÈs call the function to encrypt the passwords.

Define your directory structure (top)

The next step in the process is to design your directory structure. You should be using AS/400 IFS directories to store all of your HTML pages, images, multi-media objects, and Net.Data macros. This article will assume that you are.

My web directories for the site in this article would look something like this:


/webstuff -- a general directory that groups all of my websites together

/macros Ì stores Net.Data macros

/includes Ì Net.Data include files

/insco -- the root directory for the insurance company we are supporting

/private -- a directory used to hide directories from the world

/agents -- the directory where objects used by insurance agents are stored.

/policyholder Ì directory for policyholder stuff

/employee Ì directory for employee stuff

/othersite -- a root directory for another web site hosted on this machine.


Figure 1: Website directory structure

In this example, I will use one pair of Net.Data macro and include file sub-directories. I could easily have created a pair under /agents, /policyholder, and /employee. There are advantages and disadvantages of both methods.

If you wish to share a macro between types of user, use this approach. If you wish to isolate macros completely from each type of user, create sub-directories under each userÈs sub-directory.

Protect your directories (top)

Once you have defined your directory structure, you must define authentication rules to your server. I will not discuss the specific syntax for AS/400 servers here. IBM uses the PROTECTION directive. Be sure to define your directives so that any child directories of the directory specified is protected under the same rule.

                          /webstuff/insco/private/policyholder -- will be secured to allow members of the group POLICYHOLDER and restrict all other users for HTTP methods GET and POST.

                          /webstuff/insco/private/agents -- will be secured to allow members of the group AGENTS and restrict all other users for HTTP methods GET and POST.

                          /webstuff/insco/private/agents -- will be secured to allow members of the group EMPLOYEES and restrict all other users for HTTP methods GET and POST.


Create Net.Data CGI libraries (top)

This is perhaps the most important step in the process. You will need to create a separate library for each type of user under QSYS:




Each of these libraries must contain two objects: the Net.Data INI file and a stub program that you must write to call DB2WWW. This is the secret to this whole exercise.

You must create a program (CL ILE is fine, but it must be an ILE program) that calls Net.Data. A CL ILE program will contain exactly one line:

CALL qhttpsvr/db2www

ThatÈs it, the whole program! For purposes of this document we will call the program NDCALL (you can name anything you want). It is an extremely important program. If you try to copy DB2WWW to different libraries and call it directly, you will get some very nasty errors.

DB2WWW is the main Net.Data CGI program. DB2WWW retrieves and stores the name of the library from where it was called. This is used to establish the environment under which it runs. The issue here is if you call DB2WWW in two different libraries in the same server request processor, Net.Data will fail.

By using a little stub program to call it, it thinks its being called from QHTTPSVR every time it is called.


Define server alias for each CGI library (top)

This technique uses a little trick that will force your web server to authenticate your macros for you.

First define the following aliasÈs:

/agents/ /private/agents/

/agents/cgi-dta/ /qsys.lib/ndagent.lib/ndcall.pgm/

/policyholder/ /private/policyholder/

/policyholder/cgi-dta/ /qsys.lib/ndpolhlr.lib/ndcall.pgm/

/employee/ /private/policyholder/

/employee/cgi-dta/ /qsys.lib/nemplee.lib/ndcall.pgm/

/cgi-dta/ /qsys.lib/db2www.lib/ndcall.pgm/

Putting it all together.

You have assigned directory-based authentication to the employee, policyholder, and agents directories and their subdirectories. You have created a set of aliasÈs that trick the server into doing authentication on Net.Data macros.

Let say you want to call a macro called empmacro.mac that is used exclusively by employees. You would code the following URL:

You will be prompted to login as an employee if you attempt to type in the URL and execute the macro from the browser address line or if you link to it from any other URL on your system.

In the example above, the alias º/cgi-dta/È is defined to allow Net.Data macros to be called for the general public (no authentication).

The trick that makes it work is the alias. The server will look at your URLÈs and think that /employee/cgi-dta/ is a sub-directory of the /employee/ sub-directory and apply the authentication rules because you told the server to apply the rules to the directory and all of its sub-directories.

Good luck with this. I hope it is helpful. As I said before, we will post a follow-up article that has some specific examples.


Return to the Home Page

© Copyright 1998, 1999 by IGNITe/400sm
This page last updated on: Sun Jun 27 20:55:29 1999