Adoption of Authority is an IBM i security mechanism with which you can programmatically provide a user with elevated authorities for the purpose of allowing access to files and other objects in cases where access would normally be denied. For example, I do not want my help desk operators to be able to create user profiles, but I DO want them to be able to reset a user's password and status(*enabled). In order to routinely reset users passwords and status, the help desk user needs two special authorities, *ALLOBJ and *SECADM.

Rather than providing that severely high level of access in the help desk user profile, we instead provide a special menu option (Reset User) on the help desk main menu. We assign no special authorities to help desk staff user profiles.

When the help desk user selects the Reset User menu option, a specially prepared program is run, in which the help desk user simply enters the user ID and presses Enter. The special program then resets the User Status and Password and sends the help desk user back to their main menu.

This special program could not reset the profile unless it was able to convey to the user a temporary use of *ALLOBJ and *SECADM special authorities. This is exactly what adopted authority does. It conveys elevated capability to the user who runs the program.

Each IBM i program has an attribute that determines whose authority is used during program execution. You can choose to allow the program to run under the user's own authority, or the other choice is to allow the program to run under the authority of the owner of the program.

In the case of the help desk Reset User facility, the help desk user (having no special authorities) does not have sufficient authority to reset the password and status, so, it must be the owner's authority that is used in this case. And it is. The help desk user is temporarily "adopting" the authority of the owner of the Reset User program. The owner of the Reset User program must be a powerful user profile with both *ALLOBJ and *SECADM in his or her user profile.

There is only one step in creating an adopting program. Create the program or service program (or SQL package) and specify the value *OWNER for the USER parameter. (The default value is *USER.)

The program you created now adopts the authority of the owner of the program. In most cases, you will want to change the owner of the program to a user profile that has the required private and special authorities needed to perform the program functions.

When Is Adopted Authority Used?

When you run a program that adopts authority, the adopted authority is used only in cases in which the authorities and special authorities within your own user profile and all your group profiles are insufficient to perform an operation or to access an object.

Consider an example: We have a file named PAYFILE that is owned by the user DATAOWNER. Here are the authorities for the file PAYFILE.

User        Authority
DATAOWNER   *ALL 
*PUBLIC     *EXCLUDE

You want to display the file description for the PAYFILE to see how many records are in the file. You try the command DSPFD PAYFILE and get an error message that says you are not authorized to the file. In this case, the security system determined that neither your user profile nor any of your group profiles had sufficient authority to display the PAYFILE file.

Now let's introduce adopted authority into the picture. I have a program named QRYPGM that adopts the authority of DATAOWNER (the owner of PAYFILE). The QRYPGM program accepts as input the name of a file (PAYFILE) and runs the command DSPFD PAYFILE.

So, what happens now when I run the program QRYPGM, as in CALL QRYPGM PARM('PAYFILE')? The system still must go through all of its tests to determine whether I can access PAYFILE. As it turns out, my user profile, and all my combined groups still do not have sufficient authority to access PAYFILE.

Now, AFTER the system determines that I do not have sufficient authority, the system analyzes my job to determine whether the job is currently running under adopted authority, and if so, what authority is adopted. In this case, the job is running under the adopted authority of DATAOWNER. The system then checks whether DATAOWNER has sufficient authority to provide the requested level of access.

In this case, when the adopted authority of DATAOWNER is considered, I adopt the required authority to display the PAYFILE description.

What Is Adopted?

In adopted authority, only special authorities, private authorities, and primary group authorities are adopted, and they are checked only for the adopted owner profile. And, they are checked only when I do not have sufficient authority. User profile attributes such as Limited Capabilities, User Class, Job Description, Status, etc., are not adopted.

But What About the Owner's Group Profiles?

If the adopted Owner profile is a member of one or more group profiles, the group profiles are not considered in adopted authority. For example, if your profile is the adopted owner of a program, and you are a member of a group that has *ALLOBJ special authority, the *ALLOBJ special authority in that group is not adopted. What IS adopted are your own special authorities and private authorities.

But What About *PUBLIC?

During adopted authority checking, it is possible that *PUBLIC authority would appear to provide sufficient authority. However, during adopted authority processing, *PUBLIC authority is not considered. Let me explain. This is a bit complex.

Let's take the previous example of PAYFILE. The authorities for PAYFILE are as follows:

User       Authority
DATAOWNER  *ALL 
DAN        *EXCLUDE
*PUBLIC    *USE

When DAN types the command DSPFD PAYFILE, the response is "Not Authorized to PAYFILE," based upon DAN's *EXCLUDE authority.

When DAN runs the QRYPGM program that adopts DATAOWNER, the QRYPGM is able to successfully display the PAYFILE file description. While DAN still does not have authority to the file, the temporary adoption of the DATAOWNER profile lends DAN *ALL authority to the file.

In order to see the *PUBLIC issue here, let's assume that the QRYPGM is owned by the user profile JOHNEARL, and it is JOHNEARL's authority that is adopted. Since JOHNEARL does not have a private authority listed here for the PAYFILE, and since JOHNEARL does not have *ALLOBJ special authority, you would expect that the adopted authority would provide the *PUBLIC authority of *USE, but it does not. Even though JOHNEARL has authority to the file through it's *PUBLIC AUT(*USE) authority, and I am adopting JOHNEARL, that *PUBLIC authority cannot be used for adopted authority. To be clear: Adopted authority cannot be used to access an object through its *PUBLIC authority. This access request would fail with "Not Authorized to File."

Adoption Afterthoughts

Adoption of authority is always cumulative. You cannot reduce your authority by adopting authority; you can only gain additional authority. Adopted authority is evaluated only if the authority in your user and group profile(s) is insufficient to perform a function or access an object.

The Two Big Lessons

Any group profiles of the Adopted Owner of the program are NOT considered when doing authority checks for adopted authority.

*PUBLIC authority will never be considered during adopted authority checking.