Why Use Authorization Lists?

By Carol Woodbury

The Authorization List is a security administration tool that has been available since Release 1.0 of OS/400. Authorization lists or authority lists, as some people call them, are a tool that help security administrators manage authority to objects (libraries, files, folders, directories, etc) when all of the objects need to be authorized in the same way. In other words, they make an administrator’s life significantly easier when users need the same authorization level to a bunch of objects.

Let’s walk through the steps of securing the files for an HR (Human Resources) application with an authorization list.

Create the authorization list using the Create Authorization List command.

            CRTAUTL AUTL(HR_AUTL)

Note: All authorization lists are created in the QSYS library. This is not optional.

Determine the objects you’re going to secure with the authorization list.

In this example, you are going to secure all of the files associated with a Human Resources application.

To associate the authorization list with the files, run the following command. This associates all of the files in the HR_LIB library with the HR_AUTL authorization list.

            GRTOBJAUT OBJ(HR_LIB/*ALL) OBJTYPE(*FILE) AUTL(HR_AUTL)

To associate an authorization list with an object in the Integrated File System use the Change Authority (CHGAUT) command

            CHGAUT OBJ(‘/ADP_FTP_TRANSFER’) AUTL(HR_AUTL)

For the users needing authority to the files which are secured by the list, grant them authority to the list.

Run the Add Authorization List Entry (ADDAUTLE) command. In this case, the Human Resources group profile, GRP_HR is being granted *USE authority to the HR_AUTL authorization list.

            ADDAUTLE AUTL(HR_AUTL) USER(GRP_HR) AUT(*USE)

Optionally you can use the Edit Authorization List (EDTAUTL) command, specifying the name of the authorization list. Using EDTAUTL, you can easily add and remove users from the list, and specify their authorization to the list… and therefore, the objects secured by the list.

And the Effect is . . .

After following these steps, when a member of the Human Resources group (GRP_HR) accesses FILE001 in library HR_LIB, they will access it with *USE authority because IBM i will recognize that the FILE001 is secured with the HR_AUTL authorization list, and that their group has *USE authority to the list.

Specifying *PUBLIC Authority

In addition to specifying private authorities, as we have just done with the HR_GRP group profile, you can also specify that the objects’ *PUBLIC authority will be determined by the authorization list. I like to do this because then I can quickly and easily change the *PUBLIC authority to many objects with one command. If you want to have *PUBLIC authority come from the object itself, nothing needs to be done. If you want the *PUBLIC authority to come from the authorization list, you must set the objects’ *PUBLIC authority to ‘point to’ the authorization list securing the object. To accomplish that, run the GRTOBJAUT(Grant Object Authority) command as shown here.

Then set the *PUBLIC authority of the HR_AUTL using either the GRTOBJAUT or the EDTAUTL command.

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

(Note: The *PUBLIC authority in the authorization list is only considered when the object is secured with *PUBLIC AUT(*AUTL).

The Benefits of using Authorization Lists

Beyond making it significantly easier to grant users (or groups) the same authority to multiple objects, authorization lists provide a way to change authority to files, even when the file is open. This is one of the most significant benefits of authorization lists and the primary reason I use them so often. Modifying the authority of a file that’s open is often a challenge in today’s 24x7 environment. Many critical files are open continuously. When a file is open, IBM i prevents its authority from being changed. However, if the file is secured with an authorization list, changing authorities is not a problem. That’s because you are actually changing the authority to the authorization list, not the file itself.

Another benefit of authorization lists is fewer entries in user profile objects. For every private authority granted to an object, an entry is made in the object owner’s profile as well as the profile of the user being granted the private authority. When a file is involved, it gets really messy. When granting private authority to a file, multiple entries are made to the owner’s and user’s profile for every member of the file. Granting a private authority to a multi-member file can literally add hundreds of entries both user profiles. However, if the file is secured by an authorization list, there will be one entry in the owner’s profile for each user authorized to the list and one entry in the profile of each user authorized.

In addition to reducing the physical size of user profile objects, reducing the number of entries in user profiles has another benefit. Fewer private authority entries mean reduced time during a Save Security Data (SAVSECDTA) and on the subsequent Restore Authority (RSTAUT) if you ever have to recover a system.

Performance considerations

While the use of authorization lists used to cause performance problems in the early days of OS/400 that is no longer the case. Authorization lists extended the path of an authority check and had a noticeable performance impact in some cases. However, an authority cache was added early in Version 4 which caches - on a per user basis - up to 32 private authorities and, additionally, up to 32 private authorities to authorization lists. So in general, if a user accesses objects that are secured by the same authorization list, the authority will come from this cache and it is a very fast check. Given all of the optimization of algorithms and additions like this cache, you have to have a security scheme that’s incredibly poorly architected and that’s virtually impossible to maintain to come close to having your security scheme be the cause of a performance issue on today’s systems.

The drawback

The only drawback that I see with authorization lists is that they are only restored when restoring all profiles, that is, running RSTUSRPRF (*ALL). To move an application secured by an authorization list from one system to another, you will have to first create the authorization list on the new system before restoring the application. Once you’ve restored the application, you will have to re-grant all the private authorities to the authorization list. If you are a software vendor and you decide to ship your application secured by an authorization list, during your product’s installation process, you will have to create the authorization list before restoring the application.

Which is better – Group profiles or Authorization lists?

One is not better than the other. They are both management tools – one (group profiles) helps you manage like users and the other (authorization lists) helps you manage like objects. I often see users authorize group profiles to an authorization list.

The message here is that you should use whichever tool or tools make your job easier. If that means using both group profiles and authorization lists, go right ahead.

About the Author

Carol Woodbury is co-founder and President of SkyView Partners, Inc, a firm specializing in security and compliance software and services for the IBM i and AIX.