Using Authorization Lists

By Rich Loeber

When designing security for your IBM i system, there are lots of things you can do to simplify the task and keep maintenance of security settings to a minimum. Some of these include implementing group profiles and supplemental group profiles. Another important one is using Authorization Lists.

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. But, one of the most significant advantages is that security changes can be made to a list even when objects in the list are open and active on your system. This means that you can make security adjustments on your system even when the applications are active and running. Conversely, when using private object authorities, you can only make security changes when the file is not in use. This 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 this 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 that 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.

Remember that a private authority to an object will override the authority provided by the Authorization List. If you are converting your security setup over to use Authorization Lists, this will be an important consideration. A private authority will also override a group profile setup, so this is something that will be important to review and check as well.

If you have any questions about anything in this tip, just ask me and I'll give you my best shot. My email address is rich at kisco.com. All email will be answered.