Authorization Lists - Misconceptions in Object Authority

By Dan Riehl

Authorization lists allow you to secure several different objects that have the same object-level authorities by using a template approach, rather than maintaining the list of object authorities within each individual object. I think many people shy away from using authorization lists because they don't understand the lists' function. But when you think of an authorization list as simply an authorization template to be applied to many objects, it seems to make a bit more sense.

The best way to secure objects on the IBM i is by using a combination of group profiles and authorization lists. Doing so greatly eases maintenance tasks.

In auditing numerous systems over the years, I find that when authorization lists are used, there is often an error in setting the *PUBLIC authority, private authorities, and ownership of the objects secured by the list. There can also be errors due to improper ownership of the authorization list itself.

Among IBM i professionals, I've noticed three main misconceptions about using an authorization list:

• When we secure an object using an authorization list (*AUTL), we believe that we can view all the authorities to the object by simply viewing the authorization list. In effect, we are able to ignore the authorities that are set within the object itself. *AUTL is the only authority in effect.


• We also believe that since the authorization list contains a setting for *PUBLIC authority, the *PUBLIC authority specified in the authorization list will be applied to all objects secured by the list, regardless of what is specified in the object for *PUBLIC authority.


• The third issue is that we ignore the owner of the authorization list, since that will have no bearing on the authority to the objects secured by the list.

Let's look at some examples to try to dispel these common misconceptions. In Figure 1, the PRODLIB_O authorization list is owned by PAYUSER, providing *ALL authority to the authorization list to PAYUSER. The *PUBLIC authority to the authorization list is set to *EXCLUDE. Private authorities have been granted to GROUP_IT, GROUP_OPS, and QPGMR.

Figure 1: PRODLIB_O Authorization List

In Figure 2, the physical file PAYFILE is secured by our Authorization List PRODLIB_O. The Authorization List specifies that *PUBLIC authority is *EXCLUDE. But, the PAYFILE object itself specifies that the *PUBLIC authority is *CHANGE.

Figure 2: Object authorities for physical file PAYFILE

The file PAYFILE is owned by BOBTHETECH, giving BOBTHETECH *ALL authority to the PAYFILE, but BOBTHETECH is not listed in the Authorization List. The PAYFILE and the Authorization List specify different authorities for GROUP_IT, GROUP_OPS, and QPGMR. With all these disparate authorities listed, what are the actual authorities in effect for this file?

Using the examples in Figures 1 and 2, the actual effective authorities to the PAYFILE are these:

• BOBTHETECH   AUT(*ALL)
• GROUP_IT          AUT(*ALL)
• GROUP_OPS     AUT(*CHANGE)
• QPGMR              AUT(*ALL)
• *PUBLIC             AUT(*CHANGE)
• PAYUSER           AUT(*ALL)

So, even though the authorization list specifies differently, when there are conflicting authorities in the object and in the authorization list, the object wins, not the Authorization List. And since PAYUSER owns the *AUTL, PAYUSER has *ALL authority to the objects secured by the list.

Fixing the problem.

First, let's fix the ownership of the PAYFILE. IT staff should not own production objects, so we'll change the owner of the PAYFILE to PAYUSER and revoke BOBTHETECH's authority. Next, we will remove all the conflicting private authorities to the PAYFILE for GROUP_OPS, GROUP_IT, and QPGMR. Figure 3 shows these changes.

Figure 3: PAYFILE Object Ownership Change, Private Authorities Removed
                 and *PUBLIC *AUTL change

Now, let's fix the *PUBLIC authority. The only way to actually implement the *PUBLIC authority specified in the authorization list is to specify the *PUBLIC authority value for the secured objects as *AUTL, and this is the entry that should always accompany the use of an authorization list. *AUTL is an authority value that can only be specified as the object authority for the user *PUBLIC. If an object is secured by an authorization list, the *PUBLIC authority to all objects secured by the list should be specified as *AUTL. This tells the system to look to the authorization list for *PUBLIC's authority to the object. If you specify any other value for the Object's *PUBLIC authority (e.g., *USE, *CHANGE, *ALL), the Authorization List's authority for *PUBLIC will never be considered. Specifying *PUBLIC AUT(*AUTL) for all objects secured by the list is needed to maintain consistency and to avoid confusion over what authority *PUBLIC has to the objects secured by the list. It will always be found in the Authorization List

So, what are the effective authorities to the PAYFILE after we have done this cleanup? Now you can simply look to the *AUTL. All access will be resolved by the *AUTL, except that authority provided to PAYUSER, who is the owner of the PAYFILE. It is a good practice to have the object's and the Authorization List owned by an owning profile, perhaps even the same owning profile, since do not want ownership to ever convey any additional unwanted authorities.

About the Author

Dan Riehl is the Editor of the SecureMyi Security Newsletter and a Security Specialist for
the IT Security and Compliance Group

Dan performs IBM i security assessments and provides security consulting, remediation, forensic evaluations, and other customized security services for his clients. He also provides training in all aspects of IBM i security and other technical areas through The 400 School, Inc.

Dan Riehl on LinkedIn