Adopted authority risks and recommendations

You should use adopted authorities with care to prevent possible security risks.

Allowing a program to run using adopted authority is an intentional release of control. You permit the user to have authority to objects, and possibly special authority, which the user will not normally have. Adopted authority provides an important tool for meeting diverse authority requirements, but it should be used with care:

Adopt the minimum authority required to meet the application requirements. Adopting the authority of an application owner is preferable to adopting the authority of QSECOFR or a user with *ALLOBJ special authority.
Carefully monitor the function provided by programs that adopt authority. Make sure that these programs do not provide a means for the user to access objects outside the control of the program, such as command entry capability.
Make sure that programs that adopt authority and call other programs perform library qualified calls. Do not use the library list (*LIBL) on the call.
Control which users are permitted to call programs that adopt authority. Use menu interfaces and library security to prevent these programs from being called without sufficient control.

However, using adopted authority can also greatly increase the security of an application. For example, within an application you can set PUBLIC(*EXCLUDE) authority on all objects for the application. By using adopted authority while the application is running (using the authority of the application owning profile as the source of authority via program adopted authority) the user is authorized to the objects while the application is running. Once the application ends, the user no longer has authority to the application objects as the program adopted authority is no longer available. This technique prevents the user from accessing the data outside the application environment as the PUBLIC(*EXCLUDE) authority prevents access.