Carol explores the pros and cons of using authorization lists to secure IBM i objects.

Authorization lists (Autls) are a tool provided by the operating system that allows you to simplify the management of authorities on IBM i objects. But many organizations aren’t leveraging them. By fully explaining both the benefits and pain points of authorization lists, I’m hoping to convince more organizations to take advantage of them.

To best explain what an authorization list is, let me present a scenario. I have a finance application, and at the end of the month a file is created by the manager to summarize transactions. Several batch jobs run that update the file. Once all of the end-of-month jobs have run, a handful of people from the finance department need to download the results into spreadsheets. No one else should have access to this file.

I don’t need to have an authorization list to solve this authorization puzzle. I can grant these authorities to the following profiles and life is good:

            BATCHJOB1     *CHANGE

            BATCHJOB2     *CHANGE

            FINANCE1        *USE

            FINANCE2        *USE

            FINANCE3        *USE

            FINANCE4        *USE

            FINANCE5        *USE

            *PUBLIC           *EXCLUDE

But why should the manager have to remember all of the authorities that need to be granted each month? Enter authorization lists. In this scenario, I would create an authorization list:

CRTAUTL AUTL(FINANCE) AUT(*EXCLUDE) TEXT('Finance authorization list')

Then, using the EDTAUTL command, I’d grant the same authorities listed above to the FINANCE authorization list. See Figure 1.

Figure 1: Use EDTAUTL to authorize profiles to the FINANCE autl.

Each month, when the manager creates the new file, all that needs to happen is that she attaches the authorization list to the file:

GRTOBJAUT OBJ(*LIBL/FINOCTEOM) OBJTYPE(*FILE) AUTL(FINANCE)

Then she points the *PUBLIC authority of the file to the authorization list (unfortunately, you can’t do this at the same time you attach the list):

GRTOBJAUT OBJ(*LIBL/FINOCTEOM) OBJTYPE(*FILE) USER(*PUBLIC) AUT(*AUTL)

Later, if you determine there are other files that have these same authority requirements, you repeat the same process: Associate the file (or other object) with the authorization list, and set the *PUBLIC authority to come from the autl. You can also secure IFS objects with an authorization list. Here are those commands:

CHGAUT OBJ('/finance') AUTL(FINANCE)

CHGAUT OBJ('/finance') USER(*PUBLIC) DTAAUT(*AUTL) OBJAUT(*NONE)

Regardless of where the object is located, the result is that whatever authority the profile has to the FINANCE autl is the authority to the objects attached to the authorization list.

This scenario greatly simplifies the management of the authorities to these files, but I can simplify it even further by using a group profile. If I create a group profile called FINDWNLOAD and make the FINANCE1, 2, 3, 4, 5 profiles a member of that group, I can replace those users’ authority to the autl as shown in Figure 2.

Figure 2: Profile’s authority has been replaced with authority to their group.

This step simplifies the maintenance even further because the manager no longer has to remember to modify the authority to the authorization list when FINANCE1 leaves the department and is replaced by FINANCE53. Just place FINANCE53 in the FINDWNLOAD group and those users will have the authority they need.

Other Benefits

In addition to simplifying the management of authorities, perhaps an even bigger benefit is the fact that you can affect the authority of a *FILE object that’s in use. In the previous example, if the finance manager was still granting private authorities to individuals and a new member joined the team, she would have to wait to grant the authority to her new team member until the file wasn’t in use. The operating system prevents you from changing the authority of a file that’s open (that is, in use.) Any attempt to add a new authority or remove or modify an existing authority times out (fails). If, however, the file is secured with an authorization list, you can manage the authorities to the list even when the file is open. This means you don’t have to end an application to be able to manage authorities as long as its *FILEs are secured with an authorization list.

Another benefit of using authorization lists is that they reduce the number of private authorities on the system. In the original scenario, the system was storing at least seven private authorities for each file secured. (It’s likely more, especially if the file is a multi-member file. Then the private authorities are multiplied by the number of members.) Why do you care whether there are a lot of private authorities on the system? You care when you perform a Save Security Data (SAVSECDTA) and you especially care when performing a Restore Authority (RSTAUT). See this article for more details.

The Downsides

One downside of using authorization lists is that an object can be secured by only one authorization list. While I have run into the situation where I wanted to attach two authorization lists to the same file, it’s not a situation that craters a project. In this case, you typically have to create a third authorization list, authorize the profiles from both original lists, and switch the file to be secured by the third list. The downside is that you now must administer three authorization lists rather than just two. But even with this additional list, it’s still better than administering authorities to individual objects.

Another downside is that you can still grant private authorities to the object in addition to securing it with an authorization list. I try very hard to have authorities come from either the authorization list or from the object itself but not both. I like to look at one place for the authorities, either the object or an autl. (That’s one reason I like to point the object’s *PUBLIC authority to the authorization list; it allows me to look at the autl and know all of the authorities in effect.) When authorities come from both places, I really have to stop and think which authorities are in effect, especially when the same profile has been granted a private authority as well as having authority to the autl and the authorities are different. Or a profile has authority to the authorization list, and the profile’s group has a private authority to the object. To determine which authority is in effect takes knowledge of the IBM i authority-checking algorithm. Call me lazy, but I don’t want to think that hard!

Working with Authorization Lists

I’ve shown you a few of the CL commands associated with authorization lists, but you may prefer to use the IBM Services in QSYS2 to work with authorization lists. Two views allow you to get information about authorization lists:

QSYS2.Authorization_list_user_info provides what the name suggests: the list of profiles authorized to an authorization list. Run your SQL SELECT statement with no WHERE clause and you’ll have a list of all autls along with all the profiles authorized to them.

QSYS2.Authorization_list provides the list of objects secured by this list. This is one of my favorite SQL views because of the speed at which the information is returned as compared to the corresponding CL command. If you have ever run the Display Authorization List Objects (DSPAUTLOBJ) command for an authorization list that secures lots (as in thousands) of objects, you’ll know that the results can take a significant length of time to be displayed. Using this view returns the list of objects for a specific authorization list very quickly, especially compared to DSPAUTLOBJ. See Figure 3 for an example of the output.

Figure 3: Results using QSYS2.Authorization_List_Info SQL Service

Another benefit of using this view is that it includes any IFS objects that are secured by the autl, unlike the output from DSPAUTLOBJ.

Summary

I find authorization lists to be an under-used feature of IBM i security. I hope that this article will help you find ways to make use of this feature, allowing you to start saving time administering your IBM i security authorities.

 

Carol Woodbury is President and CTO of DXR Security and has over 30 years’ experience with IBM i Security. She started her career as Security Team Leader and Chief Engineering Manager for iSeries Security at IBM in Rochester, MN. Since leaving IBM, she has co-founded two companies – SkyView Partners and DXR Security. Her current company - DXR Security - specializes in penetration testing for IBM i. Her practical experience together with her intimate knowledge of the system combine for a unique viewpoint and experience level that cannot be matched.

Carol is known world-wide as an author and award-winning speaker on security technology, specializing in IBM i Security topics. She has written seven books on IBM i Security. Carol has been named an IBM Champion since 2018 and holds her CISSP and CRISC security certifications.

 

---

MC Press books written by Carol Woodbury available now on the MC Press Bookstore.

		IBM i Security Administration and Compliance: Third Edition Don't miss the newest edition by the industry’s #1 IBM i security expert. List Price $71.95 Now On Sale
		IBM i Security Administration and Compliance: Second Edition Get the must-have guide by the industry’s #1 security authority. List Price $71.95 Now On Sale
		IBM i Security Administration and Compliance For beginners to veterans, this is the definitive security resource. List Price $69.95 Now On Sale

Also Read

Securing IBM i: A Dual Responsibility

Top IBM i Security Issues of 2024

Why Cleaning Up Is an Important Part of Your IBM i Security Practice