What is User Class and When is it Used?

The User class of a user profile is often misunderstood and assumed to provide more control that it does. This article explains when the User class is used and clears up some misperceptions.

The purpose of the User class parameter is to act as the first step in defining the role a profile is going to belong to – end user (*USER), system operator (*SYSOPR), programmer (*PGMR), security administrator (*SECADM) and security officer (*SECOFR). As such, when you create or change a user profile, specify a value for the User class parameter and leave the Special authority parameter with the default of *USRCLS, the profile is created or changed to have the special authorities that correspond to that role as shown in the table below.

Defaulting the user’s special authorities is the main purpose of the User class parameter.

The next use of the User class is when you IPL the system from QSECURITY 20 to a higher level. When you IPL from level 20, the system examines the users’ User class setting and adjusts the users’ special authorities to match their User class. This makes more sense if you see how special authorities are assigned at security level 20. See the table below:

The notable special authority granted to all User classes at security level 20 is, of course, *ALLOBJ! When the system is IPLed to a higher level, this, along with the other ‘extra’ special authorities are adjusted to match the User class settings in Table 1.

The third and final use of the User class parameter is what a user will see when they encounter an IBM -supplied menu. The options they see vary based on the user’s User class setting. A user assigned to the *SECOFR User class will see all menu options but the user in the *USER User class will likely see fewer menu options.

Now let’s clear up some misperceptions about User class:

• The User class setting is NOT examined when the system checks authority. Yes, the system checks to see if the profile has *ALLOBJ special authority but that is a specific check for that special authority. It is NOT a check for the User class setting. Do not assume that a user has (or doesn’t have) authority to an object based on their User class setting!

• Just because a profile is in a specific User class, you cannot assume that the special authorities assigned to the profile match the User class defaults. When creating or changing a user profile, you can specify specific values for the special authority parameter. For example,

  CRTUSRPRF CAROLW USRCLS(*USER) SPCAUT(*ALLOBJ)

  When you specify special authorities that don’t match what is normally granted for that User class value, the profile is created but you’ll receive the message “User class and special authorities do not match system supplied values.” This is simply a warning message and can be ignored. Because of this, you must explicitly check the user’s special authorities - not their User class setting - when determining what capabilities they have.

Contributed by:
Carol Woodbury
IBM i Security SME
Kisco Systems