During the seminars, attendees asked if it was possible to secure a section of a Web site or the entire Web site without creating a unique OS/400 user profile object for each user.

Imagine a Web site with 50,000 or perhaps 50 million Web users. Now, consider that in order to secure a specific location on your Web site, you would have to create an equal number of user profiles on the system to maintain security. This could be a lot of burden on the system. In addition, it would become difficult to maintain unique user profile names because there are only 10 characters available for a user profile name. This is where validation list objects come into play.

A validation list is an OS/400 object that may contain identification data, encrypted data, and descriptive data. A validation list may also be used to secure a folder on the IFS. By creating a validation list, adding "Web user IDs" and passwords to the list, then securing a folder with the validation list, you end up with a new model for user profiles: Web user profiles. The best part is that the user IDs stored in a validation list may be up to 100 bytes long, and their passwords may be up to 600 bytes long (encrypted). Additionally, you may store up to 1,000 bytes of miscellaneous data for each validation list entry. That's enough space to save all the information for most Web users.

Because validation lists are OS/400 objects, they are restricted to 10-character names and are placed in a library. You can use the Create Validation List (CRTVLDL) command to create the validation list and the Delete Validation List (DLTVLDL) command to delete the validation list. The bad news is that there are no validation list commands other than Create and Delete. There are only APIs.

Validation List APIs

Actually, there are two sets of validation list APIs. There are the traditional QSYADVLE-style APIs with eight-character names that can be called from any programming language (including RPG III), and there are the QsyAddValidationLstEntry-style APIs that may be called only from ILE languages, such as C, C++, and RPG IV.

The table below shows both types.

The validation list APIs with traditional API names, such as QSYADVLE, are called from RPG IV using the traditional CALL/PARM syntax or with the CALLP and a program prototype. The other APIs, such as QsyAddValidationLstEntry, may be called with a prototype from RPG IV, but they are really designed to be called from C or C++.

Using Validation Lists

While you can get some interesting function out of the validation list APIs, typically you want to do the following:

• Create a validation list
• Add entries to a validation list
• Remove entries from a validation list

Creating a validation list is easy; just issue the CRTVLDL command, specifying the validation list name and its library. Note, the object type is *VLDL.

Adding and removing entries from a validation list requires the use of the APIs. I have written two simple RPG IV procedure wrappers for the QSYADVLE and QSYRMVLE APIs. But rather than post the source code here, in the newsletter, I am featuring only the syntax for the procedures themselves. The source code for these procedures is shown at the end of this article.

Add Validation List Entry (ADDVLDLE)

The ADDVLDLE procedure adds an entry to an existing validation list object. If the validation doesn't exist or there is a duplicate entry, the procedure fails. The syntax for ADDVLDLE is as follows:

VLDL-NAME is the name of the validation list object. This parameter is required.

VLDL-LIBRARY is the name of the library that contains the validation list. This parameter is required.

ENTRY specifies the user ID to add to this validation list entry. This parameter is required and is case-sensitive.

PASSWORD specifies the password that the user will need to type. It is stored encrypted in the validation list. This parameter is required and is case-sensitive.

EXTRA-DATA specifies any additional data to store with the user validation list entry. This parameter is optional.

Remove Validation List Entry (RMVVLDLE)

The RMVVLDLE procedure deletes an entry to an existing validation list object if the validation doesn't exist. The syntax for RMVVLDLE is as follows:

VLDL-NAME is the name of the validation list object. This parameter is required.

VLDL-LIBRARY is the name of the library that contains the validation list. This parameter is required.

ENTRY specifies the user ID to be removed. This parameter is required and is case-sensitive.

Using a Validation List to Secure Your Web Site

You can secure your Web site with a validation list, OS/400 object-level security, or both. To secure the Web site with a validation list, add the Protection directive to your HTTP configuration file. In that Protection directive, you will specify the validation list name.

Once the Protection directive has been added and the HTTP server is ended and restarted, the IFS directory specified within the context of the Protection statement will be secured. Only those Web users whose user IDs appear in the validation list will be permitted to view and access Web pages in that directory.

In order to gain access, Web users will be required to enter their user ID and password, exactly as it appears in the validation list. Unlike traditional OS/400 user profiles and passwords, validation list user profiles and passwords are case-sensitive. Using the wrong case is perhaps the single biggest typographical error users make when entering these values. Be sure you let your Web users know that user IDs and passwords are case-sensitive.

To activate security using validation lists, specify the validation list name on the PasswdFile statement within the Protection directive of your HTTP configuration file (WRKCFGHTTP). Look at the spelling of this statement; it is "PasswdFile." Strange abbreviations run rampant in the HTTP configuration file world.

In the following example, a validation list named WEBUSERS in the QUSRSYS library is used to secure access to the IFS directory named /mywebsites/rpgiv/files/secure. All files and subdirectories in that folder are also secured by this Protection directive.

With the above Protection directive in place, anyone attempting to access a file in the /mywebsites/rpgiv/files/secure IFS folder will be prompted to enter a user ID and password. The system will then match the information that's entered against the entries in a validation list named WEBUSERS. Note the ServerID statement that is included this Protection directive. The ServerID statement is used to specify information that is displayed when the system prompts the user for a user ID and password. In other words, it informs the end-user of the name of the system they are about to sign on to. This name can be anything and does not need to be a real system name.

Validation List Summary

A validation list and a few lines in the HTTP configuration file can secure your Web site's private pages from prying eyes. Also, you could create a members-only section of your Web site, providing access only to those who have paid a registration fee.

Source Code

Validation List Wrapper RPG IV Source

Validation List Procedure Prototypes

Validation List Test Program

Note: To compile the test program with PDM option 14, you will need to create a binding directory. Please see the inline comments for compiling instructions.

Bob Cozzi is a programmer/consultant, writer/author, and software developer. His popular RPG xTools add-on subprocedure library for RPG IV is fast becoming a standard with RPG developers. His book The Modern RPG Language has been the most widely used RPG programming book for more than a decade. He, along with others, speaks at and produces the highly popular RPG World conference for RPG programmers.

---

MC Press books written by Robert Cozzi available now on the MC Press Bookstore.

		RPG TnT Get this jam-packed resource of quick, easy-to-implement RPG tips! List Price $65.00 Now On Sale
		The Modern RPG IV Language Cozzi on everything RPG! What more could you want? List Price $99.95 Now On Sale

Also Read

IBM i Security Essentials: 4 Components for an Effective Strategy

New IBM i Security Features and a Farewell

Securing IBM i: A Dual Responsibility