iSeries ADMINISTRATOR: The Value of Authorization Lists

Authorization lists are often an unused and misunderstood security-management tool. A feature that's been available since the first OS/400 release, authorization lists (a.k.a. authority lists) help security officers manage authority to objects (libraries, files, folders, directories, etc.) that all must be authorized in the same way. In other words, users require the same authority to many objects.

Here's how an authorization list could help you secure an accounts receivable application. First, create the authorization list using the Create Authorization List (CRTAUTL) command:

CRTAUTL AUTL(AR_AUTL)

(Note: OS/400 always creates authorization lists in QSYS.)

Then determine the objects to be secured with the authorization list. In this example, that's all of the files associated with the accounts receivable application.

To associate the authorization list with the files, do one of the following for all of the files:

1) Run the Grant Object Authority (GRTOBJAUT) command:

GRTOBJAUT OBJ(AR_LIB/AR_FILE01) OBJTYPE(*FILE) AUTL(AR_AUTL)

2) Run the Edit Object Authority (EDTOBJAUT) command specifying the authorization list name in the Object Secured by Authorization List field.

3) To associate an object in the IFS (including objects in QSYS.LIB) with an authorization list, use the Change Authority (CHGAUT) command:

CHGAUT OBJ(/QSYS.LIB/AR_LIB.LIB/AR_FILE01.FILE) AUTL(AR_AUTL)

Next, grant the authority to the appropriate users in the authorization list. This can be done in one of two ways:

1) Run the Add Authorization List Entry (ADDAUTLE) command:

ADDAUTLE AUTL(AR_AUTL) USER(KELSEY) AUT(*USE)

2) Use the Edit Authorization List (EDTAUTL) command, specifying the name of the authorization list. When the display comes up, press F6 to add new users and their authority.

For example, Kelsey uses *USE authority to access AR_FILE01 because OS/400 recognizes that the AR_FILE01 is secured with the AR_AUTL and that Kelsey has *USE authority to AR_AUTL. Kelsey will have *USE authority to any additional files or objects secured with AR_AUTL.

In addition to the ability to authorize users or groups to the authorization list, the AUTL defines the *PUBLIC authority for the objects it secures. To do this, you must get the objects *PUBLIC authority "pointing" to the authorization list. After associating the authorization list with the object, run the GRTOBJAUT command:

GRTOBJAUT OBJ(AR_LIB/AR_FIL01) OBJTYPE(*FILE) USER(*PUBLIC) AUT(*AUTL)

Then set the *PUBLIC authority of the AR_AUTL using the GRTOBJAUT or the EDTAUTL command:

GRTOBJAUT OBJ(AR_AUTL) OBJTYPE(*AUTL) USER(*PUBLIC) AUT(*EXCLUDE)

The Benefits Beyond ease of use, authorization lists provide a way to change authority to files, even when a file is open. Often in today's 24 x 7 environment, critical files are always open. If a file is open, authority to the file cannot be changed unless you've secured it with an authorization list. This allows you to change the authority because you're actually changing the authority to the authorization list, rather than the file itself.

Another benefit of authorization lists lies in smaller user profiles. Each time private authority is granted to an object, an entry is made in the owner's profile and the profile of the user being granted the private authority. When a file is involved, it gets messy. When granting private authority to a file, multiple entries are made to the owners and users profiles for every member of the file. Granting a private authority to a

multi-member file can literally add hundreds of entries to both user profiles. However, files secured by authorization lists have only one entry in each profile -- the entry for the users private authority to the authorization list.

While authorization lists physically reduce the size of user profiles, reducing the number of entries in a user profile has another benefit during system recovery. Fewer private authorities helps reduce the time needed to run the Save Security Data (SAVSECDTA) and subsequent Restore Authority (RSTAUT) commands.

An Authorization List is a special system-level object that resides in the QSYS library with object type *AUTL. Your system can contain multiple Authorization Lists, and it is recommended that they be created along application boundaries. So, one list could be used for Payroll while another list can be used for Inventory, and so on. An Authorization List simply defines user authority for objects that belong to the list. When an object is created, rather than creating individual private authorities to the object, just associate it with the appropriate Authorization List. The List, in turn, will control individual and *PUBLIC authority to all of the objects in the list. Using an Authorization List will simplify setting up new users and maintaining object authority on your system. It also has some nice side benefits. The individual size of user profiles is kept much lower using Authorization Lists. Also, system performance is improved when running SAVSYS backups and when saving security information on your system with the SAVSECDTA command.
One of the most significant advantages is that security changes can be made to a list even when objects in thelist are open and active on your system. That means you can make security adjustments on

your system even when the applications are active and running. Conversely, when using private object authorities, you can make security changes only when the file is not in use. That alone can save you loads of headaches and late night sessions on your system. To get started with an authorization list, you first need to create the list using the create authorization list (CRTAUTL) command. Be sure to set the *PUBLIC authority level using the AUT parameter. Once it is created, you can work with it using the edit authorization list (EDTAUTL) command. Using that command, you can add individual users who will need more authority than is allowed by the *PUBLIC authority setting. Once you have the list configured, it is time to use the list on the objects you want it to control. You can grant authority via the list using the grant object authority (GRTOBJAUT) command. Remember, only one authorization list can be used to secure a specific object. If you are implementing authorization lists on a system where private authorities were previously used, you might want to also use the edit object authority (EDTOBJAUT) command so that you can also

remove any private authorities that are now taken care of by the authorization list. You can also add new users to the list by a simple add authorization list entry (ADDAUTLE) command. Each individual entry in the list will control the level of authority that user is given to the object. Also remember that a private authority to an object will override the authority provided by the authorization list. If you are converting your security setup to use authorization lists, that will be an important consideration. A private authority will also override a group-profile setup, so that is something that will be important to review and check as well.