You can group objects with similar security requirements by using an authorization list.
Conceptually, an authorization list contains a list of users and the authority that the users have to the objects that are secured by the list. Authorization lists provide an efficient way to manage the authority to similar objects on the system. However, in some cases, they make it difficult to keep track of authorities to objects. You can use the Print Private Authority (PRTPVTAUT) command to print information about authorization list authorities.
Authorization List Security
You can group objects with similar security requirements using an authorization list. An authorization list, conceptually, contains a list of users and the authority that the users have to the objects secured by the list. Each user can have a different authority to the set of objects the list secures. When you give a user authority to the authorization list, the operating system actually grants a private authority for that user to the authorization list. You can also use an authorization list to define public authority for the objects on the list. If the public authority for an object is set to *AUTL, the object gets its public authority from its authorization list.
The authorization list object is used as a management tool by the system. It actually contains a list of all objects which are secured by the authorization list. This information is used to build displays for viewing or editing the authorization list objects.
You cannot use an authorization list to secure a user profile or another authorization list. Only one authorization list can be specified for an object. Only the owner of the object, a user with all object (*ALLOBJ) special authority, or a user with all (*ALL) authority to the object, can add or remove the authorization list for an object.
Objects in the system library (QSYS) can be secured with an authorization list. However, the name of the authorization list that secures an object is stored with the object. In some cases, when you install a new release of the operating system, all the objects in the QSYS library are replaced. The association between the objects and your authorization list would be lost.
Planning Authorization Lists
An authorization list has these advantages:
- Authorization lists simplify managing authorities.
- User authority is defined for the authorization list, not for the individual objects on the list. If a new object is secured by the authorization list, the users on the list gain authority to the object.
- One operation can be used to give a user authority to all the objects on the list.
- Authorization lists reduce the number of private authorities on the system. Each user has a private authority to one object, the authorization list. This gives the user authority to all the objects on the list. Reducing the number of private authorities in the system has the following advantages:
- Reducing the size of user profiles
- Improves the performance when saving the system (SAVSYS) or saving security data (SAVSECDTA)
- Authorization lists provide a good way to secure files. If you use private authorities, each user will have a private authority for each file member. If you use an authorization list, each user will have only one authority. Also, files that are open cannot have authority granted to the file or revoked from the file. If you secure the file with an authorization list, you can change the authorities, even when the file is open.
- Authorization lists provide a way to remember authorities when an object is saved. When an object is saved that is secured by an authorization list, the name of the authorization list is saved with the object. If the object is deleted and restored to the same system, it is automatically linked to the authorization list again. If the object is restored on a different system, the authorization list is not linked, unless ALWOBJDIF(*ALL) is specified on the restore command.
Advantages of Using an Authorization List
From a security management view, an authorization list is the preferred method to manage objects that have the same security requirements. Even when there are only a few objects that would be secured by the list, there is still an advantage to using an authorization list instead of using private authorities on the authorized to the objects. It is also easier to secure any new objects with the same authorities as the existing objects.
If you use authorization lists, then you should not have private authorities on the object. Two searches of the user’s private authorities are required during the authority checking if the object has private authorities and the object is also secured by an authorization list. The first search is for the private authorities on the object; the second search is for the private authorities on the authorization list. Two searches require use of system resources and might impact performance.
If you use only the authorization list, only one search is performed. Also, because of the use of authority caching with the authorization list, the performance for the authority check will be the same as it is for checking only private authorities on the object. As application requirements change, more work files may be added to the application. Also, as job responsibilities change, different users run month-end processing.
An authorization list makes it simpler to manage these changes. Use these steps to set up the authorization list:
- Create the authorization list: CRTAUTL ICLIST1
- Secure all the work files with the authorization list: GRTOBJAUT OBJ(ITEMLIB/ICWRK*) + OBJTYP(*FILE) AUTL(ICLIST1)
- Add users to the list who perform month-end processing: ADDAUTLE AUTL(ICLIST1) USER(USERA) AUT(*ALL)
Use authorization lists
iSeries™ Navigator provides security features designed to assist you in developing a security plan and policy, and configure your system to meet your company’s needs. One of the functions available is the use of authorization lists. Authorization lists have the following features:
- An authorization list groups objects with similar security requirements.
- An authorization list conceptually contains a list of users and groups, and the authority each has to the objects secured by the list.
- Each user and group can have a different authority to the set of objects the list secures.
- Authority can be given by way of the list, rather than to individual users and groups. Tasks that can be done using authorization lists include:
- Create an authorization list
- Change an authorization list
- Add users and groups
- Change user permissions
- Display secured objects
To use this function, perform these steps:
- From iSeries Navigator, expand your server—>Security. You will see Authorization Lists and Policies.
- Right-click Authorization Lists and select New Authorization List. The New Authorization List allows you to:
- Use: Allows access to the object attributes and use of the object. The public may view, but not change the objects.
- Change: Allows the contents of the object to be changed, with some exceptions.
- All: Allows all operations on the object, except those that are limited to the owner. The user or group can control the object’s existence, specify the security for the object, change the object, and perform basic functions on the object. The user or group can also change ownership of the object.
- Exclude: All operations on the object are prohibited. No access or operations are allowed to the object for the users and groups having this permission type. Specifies the public is not allowed to use the object.
When working with authorization lists you will want to grant permissions for both objects and data. Object permissions you can choose include:
- Operational: Provides the permission to look at the description of an object and use the object as determined by the data permission that the user or group has to the object.
- Management: Provides the permission to specify the security for the object, move or rename the object, and add members to the database files.
- Existence: Provides the permission to control the object’s existence and ownership. The user or group can delete the object, free storage of the object, perform save and restore operations for the object, and transfer ownership of the object. If a user or group has special save permission, the user or group does not need object existence permission.
- Alter (used only for database files and SQL packages): Provides the permission needed to alter the attributes of an object. If the user or group has this permission on a database file, the user or group can add and remove triggers, add and remove referential and unique constraints, and change the attributes of the database file. If the user or group has this permission on an SQL package, the user or group can change the attributes of the SQL package. This permission is currently used only for database files and SQL packages.
- Reference (used only for database files and SQL packages): Provides the permission needed to reference an object from another object such that operations on that object may be restricted by the other object. If the user or group has this permission on a physical file, the user or group can add referential constraints in which the physical file is the parent. This permission is currently used only for database files. Data permissions you can choose are listed below.
- Read: Provides the permission needed to get and display the contents of the object, such as viewing records in a file.
- Add: Provides the permission to add entries to an object, such as adding messages to a message queue or adding records to a file.
- Update: Provides the permission to change the entries in an object, such as changing records in a file.
- Delete: Provides the permission to remove entries from an object, such as removing messages from a message queue or deleting records from a file.
- Execute: Provides the permission needed to run a program, service program or SQL package. The user can also locate an object in a library or directory.
For more information on each process as you are creating or editing your authorization lists, use the online help available in iSeries Navigator.
To simplify managing authorities, use an authorization list to group objects with the same requirements. You can then give the public, group profiles, and user profiles authority to the authorization list rather than to the individual objects on the list. The system treats every object that you secure by an authorization list the same, but you can give different users different authorities to the entire list.
An authorization list makes it easier to reestablish authorities when you restore objects. If you secure objects with an authorization list, the restore process automatically links the objects to the list. You can give a group or user the authority to manage an authorization list (*AUTLMGT). Authorization list management allows the user to add and remove other users from the list and to change the authorities for those users.
Recommendations:- Use authorization lists for objects that require security protection and that have similar security requirements. Using authorization lists encourages you to think about categories of authority rather than individual authorities. Authorization lists also make it easier to restore objects and to audit the authorities on your system.
- Avoid complicated schemes that combine authorization lists, group authority, and individual authority. Choose the method that best suits the requirement, rather than using all of the methods at the same time.
Look at the group and individual authorities on your Library description forms. Decide if using authorization lists is appropriate. If so, prepare Authorization list forms and update your Library description forms with the authorization list information.