Using authorization lists

An Authorization List is a special system-level object that resides in the QSYS library with object type *AUTL. It 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. 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.

• Using an Authorization List will simplify setting up new users and maintaining object authority on your system.
• The individual size of user profiles is kept much lower using Authorization Lists.
• System performance is improved when running SAVSYS backups and when saving security information on your system with the SAVSECDTA command.
• 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.

To get started with an Authorization List:

• Create the list using the Create Authorization List (CRTAUTL) command.
• 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.

To work with Lists:

• Grant authority via the list using the Grant Object Authority (GRTOBJAUT) command.
• 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 to remove any private authorities that are now handled by the Authorization List.
• Add new users to the list with the 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. And a private authority will also override a group profile setup.

To audit authorization lists:

• Create a database list of all objects secured by your Authorization List

  DSPAUTLOBJ AUTL(myautl) OUTPUT(*OUTFILE)
  OUTFILE(QTEMP/AUTLOBJS)

  Substitute the name of your Authorization List where you see "myautl"

• Use DSPOBJD to create a database of all objects in a library or a subset of objects in the library. To create the database for all objects in a given library, the following command format can be used:

  DSPOBJD OBJ(mylibrary/*ALL) OBJTYPE(*ALL) OUTPUT(*OUTFILE)
  OUTFILE(QTEMP/LIBOBJS)

  If you then want to add more objects from another library, use the following command format:

  DSPOBJD OBJ(mylibrary2/*ALL) OBJTYPE(*ALL) OUTPUT(*OUTFILE)
  OUTFILE(QTEMP/LIBOBJS) OUTMBR(*FIRST *ADD)

Once both databases have created use an ad-hoc query reporting tool to match the two databases and generate a control report. For example, create a report to list the library name, object name, object type and object text description. The primary file in the query is the list of objects in the library and the list of objects from the Authorization List is the secondary file. For the key matching, select the library name, object name and object type as they should be unique. For the type of match, select the 3rd option that shows as "Unmatched records with primary file". This will end up only printing those objects that are in the library but are not secured by the Authorization List.

Our product iSecMap includes built-in support to audit authorization lists.