Using adopted authority in menu design

The availability of decision-support tools, such as Query/400, poses challenges for security design. No method exists in the resource security definitions for a user to have different authority to a file in different circumstances. However, using adopted authority allows you to define authority to meet different requirements.

For example, you might want users to be able to view information in files using a query tool, but you probably want to make sure that the files are changed only by tested application programs.

Note: Objects that adopt the owner's authority describes how adopted authority works. Flowchart 8: How adopted authority is checked describes how the system checks for adopted authority.

Figure 1 shows a sample initial menu that uses adopted authority to provide controlled access to files using query tools:

Figure 1. Sample initial menu
  MENU1         Initial Menu
 
          1.  Inventory Control (ICSTART)
          2.  Customer Orders   (COSTART)
          3.  Query             (QRYSTART)
          4.  Office            (OFCSTART)
 
  (no command line)

The programs that start applications (ICSTART and COSTART) adopt the authority of a profile that owns the application objects. The programs add application libraries to the library list and display the initial application menu. Here is an example of the Inventory Control program (ICSTART).

Note: By using the code examples, you agree to the terms of the Code license and disclaimer information.
Figure 2. Sample initial application program
PGM
ADDLIBLE ITEMLIB
ADDLIBLE ICPGMLIB
GO ICMENU
RMVLIBLE ITEMLIB
RMVLIBLE ICPGMLIB
ENDPGM

The program that starts Query (QRYSTART) adopts the authority of a profile (QRYUSR) provided to allow access to files for queries. Figure 3 shows the QRYSTART program:

Figure 3. Sample program for query with adopted authority
PGM
ADDLIBLE ITEMLIB
ADDLIBLE CUSTLIB
STRQRY
RMVLIBLE ITEMLIB
RMVLIBLE CUSTLIB
ENDPGM

The menu system uses three types of user profiles, shown in Table 1. Table 2 describes the objects used by the menu system.

Table 1. User profiles for menu system
Profile type Description Password Limit capabilities Special authorities Initial menu
Application owner Owns all application objects and has *ALL authority. OWNIC owns Inventory Control application. *NONE Not applicable As needed by application Not applicable
Application user 1 Example profile for anyone who uses the menu system Yes *YES None MENU1
Query Profile Used to provide access to libraries for query *NONE Not applicable None Not applicable
1
The current library specified in the application user profile is used to store any queries created. The Attention-key-handling program is *ASSIST, giving the user access to basic system functions.
Table 2. Objects used by menu system
Object name Owner Public authority Private authorities Additional information
MENU1 in QGPL library See Note *EXCLUDE *USE authority for any users who are allowed to use the menu In QGPL library because users do not have authority to application libraries
ICSTART program in QGPL OWNIC *EXCLUDE *USE authority for users authorized to Inventory Control application Created with USRPRF(*OWNER) to adopt OWNIC authority
QRYSTART program in QGPL QRYUSR *EXCLUDE *USE authority for users authorized to create or run queries Created with USRPRF(*OWNER) to adopt QRYUSR authority
ITEMLIB OWNIC *EXCLUDE QRYUSR has *USE  
ICPGMLIB OWNIC *EXCLUDE    
Files available for Query in ITEMLIB OWNIC *USE    
Files not available for Query in ITEMLIB OWNIC *EXCLUDE    
Programs in ICPGMLIB OWNIC *USE    
Note: A special owner profile can be created for objects used by multiple applications.

When USERA selects option 1 (Inventory Control) from MENU1, program ICSTART runs. The program adopts the authority of OWNIC, giving *ALL authority to the inventory control objects in ITEMLIB and the programs in ICPGMLIB. USERA is thus authorized to make changes to the inventory control files while using options from the ICMENU.

When USERA exits ICMENU and returns to MENU1, the ITEMLIB and ICPGMLIB libraries are removed from the USERA library list, and program ICSTART is removed from the call stack. USERA is no longer running under adopted authority.

When USERA selects option 3 (Query) from MENU1, program QRYSTART runs. The program adopts the authority of QRYUSR, giving *USE authority to the ITEMLIB library. The public authority to the files in ITEMLIB determines which files USERA is allowed to query.

This technique has the advantage of minimizing the number of private authorities and providing good performance when checking authority:
  • The objects in the application libraries do not have private authorities. For some application functions, public authority is adequate. If public authority is not adequate, owner authority is used. Case 8: Adopted authority without private authority shows the authority checking steps.
  • Access to the files for query uses public authority to the files. The QRYUSR profile is only specifically authorized to the ITEMLIB library.
  • By default, any query programs created are placed in the user’s current library. The current library should be owned by the user, and the user should have *ALL authority.
  • Individual users only need to be authorized to MENU1, ICSTART, and QRYSTART.
Consider these risks and precautions when using this technique:
  • USERA has *ALL authority to all entire inventory control objects from ICMENU. Make sure that the menu does not allow access to a command line or allow unwanted delete and update functions.
  • Many decision-support tools allow access to a command line. The QRYUSR profile should be a limited capability user without special authorities to prevent unauthorized functions.