Previous Midrange Computing articles have introduced and described a new security model called application-only access. (For more information, see "Application-only Access: Implementing the Strategy," MC, February 1996 and "Application-only Access: Security Exposures Revealed," MC, January 1996.) Security expert Wayne O. Evans developed application-only access after realizing that most existing security methods were inadequate in the face of networked tools and utilities such as ODBC and FTP. This month, I'm going to focus on how one company, Joseph E. Seagram and Sons, implemented application-only access.

Seagram, an international beverage and entertainment company, is in the process of a financial systems consolidation. Six business units across North America currently use different mainframe financial systems that will migrate to a single AS/400 running JD Edwards (JDE) software. Seagram has a worldwide network of systems, including 50 AS/400s running V2R3 and V3R1, a handful of mainframes, and thousands of PCs and UNIX systems. With all the different systems worldwide, security of data has become a greater concern for management.

The JDE application provides green-screen security but has never integrated or supported any other types of security in the application. The JDE security mechanism is implemented through a customized data access routine, leaving all other access methods wide open. This means that if a JDE user accesses the JDE data outside of the JDE application, he has complete access to the data. Take this problem to the next level, and that user could download the balances file, modify a certain account balance, and upload the changed file. No one would know the file was modified because that user is authorized to the file and no audit trail would have been created.

MIS notified management of this security hole and filled it by adding an exit program to the OS/400 registration database using the Work with Registration Information (WRKREGINF) command. That single change prevented all users from using any PC Support-based or Client Access-based (original or optimized) file transfer program to upload anything to the system. This strategy provides excellent security from file transfer uploads, but since IBM has yet to address the security of certain TCP/IP programs to the AS/400 and Seagram is migrating to TCP/IP, any user with access to FTP (TCP/IP's file transfer program) could circumvent the Registration Database Exit program. Seagram's MIS wanted a secure environment and did not want to have to worry about every back door into the system. So they decided to implement application-only access.

After it was determined to implement application-only access, the implementation team (which consisted of Wayne O. Evans, Jeffrey Hare from JDE, and me) faced many challenges, but we were determined to make it work because we felt that the benefits of limiting user access exceeded the effort to hurdle the challenges. As the methodology for application-only access states, program and data objects should be secured from the user community unless a user is in the application.

We created the group profile GRPJDE for all JDE users in order to simplify security administration. The JDE data and program libraries and the objects in those libraries were secured from the group GRPJDE and from *PUBLIC. Only the owner of the objects, user profile JDE, had access. We modified the initial JDE program, J98INITA, to adopt the authority of user profile JDE.

Now, the group profile GRPJDE has *USE authority to the program J98INITA, and *PUBLIC has *EXCLUDE in order to ensure that only those users in group profile GRPJDE can run the application. (JDE has a second entry program, J98INIT, but the Seagram installation is using J98INITA exclusively. If Seagram were using this second entry program, we would have granted *USE access to the group profile GRPJDE.)

Once interactive users were able to gain access to JDE through adopted authority from the J98INITA program, batch reporting presented the following two problems.

Problem: Users were not authorized to libraries on the library list.

When a user profile adopts authority, batch jobs initiated by that user have the authority that the user profile had before that profile adopted. The adopted authority is not propagated to the batch job.

Solution: We granted *USE access of the JDE library objects (not the objects in the library) to the group GRPJDE. This change allowed the batch job to start running.

Problem: Users were not authorized to objects referenced by job.

Although the batch job started running, it ended abnormally because of the lack of authority to the objects the application referenced. (The batch job does not inherit the adopted authority of the user profile that initiated the job.)

Solution: We created a new subsystem, JDEBATCH, from a copy of QBATCH and modified it to route all requests to program JDEADOPT (see 1). The QBATCH subsystem's default routing data entry, QCMDI, calls program QCMD. Program JDEADOPT calls QCMD but also adopts the authority of user profile JDE. All jobs running through JDEBATCH adopt the authority. The JDEADOPT routing entry program allows access to the JDE programs and data.

Solution: We created a new subsystem, JDEBATCH, from a copy of QBATCH and modified it to route all requests to program JDEADOPT (see Figure 1). The QBATCH subsystem's default routing data entry, QCMDI, calls program QCMD. Program JDEADOPT calls QCMD but also adopts the authority of user profile JDE. All jobs running through JDEBATCH adopt the authority. The JDEADOPT routing entry program allows access to the JDE programs and data.

To secure the subsystem, we modified the authority for the single job queue (a JDE requirement) for JDEBATCH so that *PUBLIC is *EXCLUDE and GRPJDE is *CHANGE. Only user profiles in the group GRPJDE can add jobs to the job queue and, therefore, run batch jobs through JDEBATCH. To prevent other users from using the JDEADOPT program, the *PUBLIC authority is *EXCLUDE and only the GRPJDE group profile has access. We created additional protection by storing the JDEADOPT program in a library that is authorized only to the users of the GRPJDE group profile. This does allow users of the group GRPJDE to perform SBMJOB to the JDEBATCH subsystem, but end users have LMTCPB *YES and do not have access to a command line to submit a job. A registration database entry was added to prevent users from executing a remote command.

Once the users could sign on to the system, run JDE interactively, and submit reports, all was complete except for one minor detail. The JDE implementation team had suggested World VISTA, the JDE modified ShowCase VISTA product, as the end-user reporting tool that would satisfy end-user reporting requirements. With application-only access, we eliminated the end user's ability to access the data outside of JDE. We had to allow the users read-only access to the data. So we changed all of the JDE data objects to allow GRPJDE *USE access to the data, ensuring that they could use World VISTA to report.

While we were developing this security schema, the end users were live on a separate AS/400 (a 300 series), and we were preparing a new AS/400 320 in anticipation of many more sites and users. We set up the 320 with the application-only access in order to limit the capabilities of the end users when they signed on to the new system.

We could have implemented application-only access on the 300 without interfering with the end users, but we would have had to be careful regarding the subsystem JDEBATCH. As stated earlier, JDE requires a single-threaded job queue and subsystem. To implement application-only access on a live system, we would have had to migrate all the end users from QBATCH to JDEBATCH at one time.

Some minor issues related to PC access have come up, and we will solve them using other group profiles and exit programs. Uploading data to the AS/400 from a PC requires two things. The first requirement is an interface from an existing PC system. The Client Access exit program can be modified so that only one specific PC is able to upload particular data.

The second requirement is that some of our marketing users use a custom Excel application that interacts with one or two JDE data files through ODBC. These users will have GRPMKT as a supplemental group, along with GRPJDE as their primary group. GRPMKT will have *CHANGE access to those specific objects that the ODBC application interacts with.

Application-only access has some opponents, especially those who feel that the poor performance of object-authority checking outweighs the benefits. However, security on any system is vital for protection not only from hackers, but from errant employees, renegade consultants, and simple end-user accidents.

Also, the Primary Group Profile (PGP) authority that V3R1 added to objects speeds up authority checks if the job accessing the object has the authority of the object's owner. We used the PGP authority to grant the group profile GRPJDE *USE access to production data files, so the authority check is quick.

In summary, the system is very secure, security was greatly enhanced, and, most importantly, the end users have noticed no difference in their day-to-day interactions with the AS/400 and the JDE application.

William C. Rausch is a JDE and AS/400 technical specialist on the Global Reporting Team at Joseph E. Seagram and Sons, based in New York City. He holds a BA in Computer Science from Rutgers University. You can contact him at 212-572-7840 or by E-mail at This email address is being protected from spambots. You need JavaScript enabled to view it..

Implementing Application-only Access: A Case Study

Figure 1: Application-only Access Batch Environment