Appendix A: All-Object Authority

By default, all-object (*ALLOBJ) special authority allows the user to access any resource on the system whether (or not) private authority exists for the user.  Even if the user has *EXCLUDE authority to an object, *ALLOBJ special authority still allows the user to access the object.  A user with *ALLOBJ can view, change, or delete any object.  These users can also grant object authority to other users on the system.

NOTE:
Listed below are the steps which IBM performs when checking a user’s authority on an object:
  1. Does the user profile have *ALLOBJ authority specified in his user profile? If so, authority is granted to use the object.
  2. Does the user profile have individual authority to the object? The user will be granted or denied access based on whatever object authorities he/she possesses in the object.
  3. Does the user profile have authority through an external authorization list that is associated with the object? If present, the user is granted or denied access based on those authorities in the authorization list.
  4. Is the user a member of a group profile that has *ALLOBJ authority? If so, the user is granted access to the object.
  5. Does the user profile’s associated group profile have authority to the object?  The user will be granted or denied access based on whatever object authorities the group profile has.
  6. Does the user profile’s associated group profile have authority through an external authorization list that is associated with the object?  If present, the user is granted or denied access based on those group authorities in the authorization list.
  7. Does the object have *PUBLIC authority sufficient enough to allow the user to access the object? The user is granted or denied access based on the public user's authority to the object.

When encrypting or decrypting data, normal IBM authority checks are used to determine if the user has rights to the Key Store (*VLDL) object, which holds the encryption/decryption Key.  If the user has *ALLOBJ, then IBM will indicate the user is authorized, which will allow the user to access the Key to encrypt or decrypt data.

Additionally, when determining if the user is authorized to the full or masked value (on a decryption operation), IBM authority checks are used to check the user’s permission to the Authorization Lists that may be specified for the field in the Powertech Encryption for IBM i registry.  If the user has *ALLOBJ authority, then IBM will indicate the user is authorized to the Authorization List, which will allow the user to access the full decrypted value.

For best security practices, there should be no users on the system with *ALLOBJ special authority.  However, this may not be seen as an acceptable option if legacy customer applications “break” when *ALLOBJ authority is removed.  Therefore there are two recommended options for helping customers to deal with *ALLOBJ authority.

OPTION #1 – Move the user’s *ALLOBJ authority to a Group Profile

Because of how IBM checks object authority (indicated above), you could move the *ALLOBJ special authority from the individual user profile level to a group profile (which you assign the user to).  The user will then get its *ALLOBJ authority from the group profile, giving the user (by default) access to all objects on the system.   Then you can *EXCLUDE this user from certain objects such as the Key Stores and Authorization Lists used in Powertech Encryption for IBM i. 

Follow the steps below to implement this option:

  1. Create a Group User Profile with *ALLOBJ special authority using the CRTUSRPRF command.
  2. Using the CHGUSRPRF command, change the individual’s User Profile to remove *ALLOBJ special authority and associate them (using the GRPPRF parameter) with the Group Profile created in step 1.  The individual will still have *ALLOBJ authority, but only through their Group Profile.
  3. Edit the authorities on the Key Store object using the EDTOBJAUT command.  Add the individual User Profile (that you want to exclude) to the object and specify *EXCLUDE for the Object Authority.

OPTION #2 – Have Powertech Encryption for IBM i perform its own authority check for *ALLOBJ users

An option is available on the Key Policy level in Powertech Encryption for IBM i, which allows you to indicate how to handle users with *ALLOBJ authority.  This option is labeled “Limit all-object authority” with the parameter keyword of LMTALLOBJ.  Valid options are *NO and *YES.

If LMTALLOBJ(*YES) is specified at the Key Policy level, then Powertech Encryption for IBM i will perform its own authority check on any requested Key Store or Authorization List for users with *ALLOBJ authority.  The user profile (or group profile which it belongs) must be specifically listed as an authority entry (with at least *USE authority) on the Key Store or Authorization List.

KeyStore Authorization Check

  1. If LMTALLOBJ(*YES) is specified at the Key Policy level and if the user has *ALLOBJ special authority, then the following steps will be performed to determine if the user has authority to a Key Store (*VLDL) object containing the Key requested for encryption/decryption operations:
  2. Does the user profile have an authority entry on the object? If the entry is at least *USE, then the User is authorized to the object. Otherwise if the entry is not at least *USE, then the user will be considered as not authorized.  
  3. Does the user have a group profile or one or more supplemental group profiles that have an authority entry on the object? If the entry is at least *USE, then the user is authorized to the object. Otherwise if the entry is not at least *USE, then the user will be considered as not authorized.  
  4. Check the *PUBLIC authority entry on the object. If the entry is at least *USE, then the user is authorized to the object. Otherwise if the entry is not at least *USE and an Authorization List is not attached to the Object, then the user will be considered as not authorized.  
  5. Is an Authorization List attached to the Key Store object, and is the user profile in that List? If the entry is at least *USE, then the user is authorized to the object. Otherwise if the entry is not at least *USE, then the user will be considered as not authorized.  
  6. Is an Authorization List attached to the Key Store object, and does the user have a group profile or one or more supplemental group profiles that exist in that List? If the authority is at least *USE for any of the group entries, then the user is authorized to the object. If none of those entries are at least *USE, then the user will be considered as not authorized.
  7. If an Authorization List is attached to the Key Store object, then check the *PUBLIC entry in that List. If the entry is at least *USE, then the user is authorized to the object. Otherwise if the entry is not at least *USE, then the user will be considered as not authorized.  

Field Registry Authorization List

Authorization Lists can currently be assigned to a field in the Field Encryption Registry to indicate which users are authorized to the full or masked values.  If LMTALLOBJ(*YES) is specified at the Key Policy level and if the user has *ALLOBJ special authority and authorization list(s) are specified for the field, then the following steps will be performed to determine if the user is authorized.

  1. Does the user profile exist in the Authorization List? If the authority is at least *USE, the user is authorized. Otherwise if the entry is not at least *USE, then the user will be considered as not authorized.  
  2. Does the user have a group profile or one or more supplemental group profiles, and one or more group profile entries exist in the Authorization List? If the authority is at least *USE for any of the group entries, the user is authorized. Otherwise if the entry is not at least *USE, then the user will be considered as not authorized.  
  3. Check the *PUBLIC entry in the Authorization List? If the authority is at least *USE, then the user is authorized. Otherwise if the entry is not at least *USE, then the user will be considered as not authorized.  

NOTES / RISKS:

  • A user with *ALLOBJ authority can change the authority on any object on the system including Key Store (*VLDL) objects and Authorization Lists. So if an *ALLOBJ user becomes restricted by LMTALLOBJ(*YES) in Powertech Encryption for IBM i, they could simply grant themselves authority to the Key Store or the Authorization List.  Since you cannot restrict an *ALLOBJ user from changing authorities, the only option you have is to audit authority changes with the CHGOBJAUD command.
  • Program adopted authority will not be recognized for users with *ALLOBJ authority when LMTALLOBJ(*YES) is specified. For instance, if an *ALLOBJ user is running a program that adopts authority from the owner of the program, this *ALLOBJ user will not adopt authority to a Key Store if the program owner is authorized to the Key Store.