When designing security for your iSeries 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.
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. 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.
If you have any specific questions about Authorization Lists and how to implement them, feel free to contact me via e-mail at "email@example.com".
About the author: Rich Loeber is president of Kisco Information Systems Inc., in Saranac Lake, N.Y. The company is a provider of various security products for the iSeries market.
MORE INFORMATION ON THIS TOPIC
Are my objects really secure?
One user that comes from an OS/390 environment writes, "I have recently been assigned to the iSeries system. When reviewing the security of my objects -- through WRKOBJ display authority -- I see that the objects are not secured by an Authorization List and PUBLIC has full access. How secure are my objects?" Security expert Carol Woodbury responds.
Working with Authorization Lists
Former security expert Dan Riehl explains the impact on the use of objects that are not affiliated with an Authorization List.
Keep iSeries security simple
Security on the iSeries can seem like a monumental task. For most iSeries shops, the number of objects on your system is astronomical. The key to implementing an effective security design is to keep it as simple as possible. The designers of OS/400 security had this in mind when they created the security layer on your system, so it is entirely possible to achieve.
Tightening iSeries security
As your company grows, so do the security risks -- from inside and outside threats. Be aware of what's lurking around the corner. Our resources can help you to protect your shop.