IBM i5/iSeries Primer(c) Concepts and Techniques for Programmers, Administrators, and Sys[... ]ators

You could have your user profiles scattered all over the place, without organization; however, a nightmarish situation occurs when you have to maintain authorities on dozens of individual user profiles.

Group profiles and authorization lists are two ways to simplify the administrative part of system security. Group profiles and authorization lists let you make sets of users (or objects) and manipulate authorities as a group at the set level.

Even if you never plan to go to security level 30 or above, group profiles let you group your users and achieve some amount of organization.

The concepts of group profiles and authorization lists are complex. A full discussion of these topics is beyond the scope of this book.

Group Profiles

A group profile is a user profile like any other, which you create using the CRTUSRPRF command. Group profiles are different from "regular" user profiles because a group profile appears in the GRPPRF parameter of one or more other user profiles.

Group profiles can be given any name. If you want to use a naming convention for your group profiles, consider giving them names that begin with the characters GRP (for "group"), followed by some significant name like ACG for Accounting or SAL for Sales.

This example creates a group profile for the Human Resources department. You can call it GRP_HUM. The underscore character (_) is not required, but using an underscore makes the group profile name more readable:

CRTUSRPRF USRPRF (GRP_HUM) PASSWORD(*NONE) GRPPRF(NONE) + TEXT('Group profile for Human Resources')

PASSWORD(*NONE) guarantees that no one will be able to sign on using the GRP_HUM profile, which forces users to sign on as themselves. GRPPRF(*NONE) is a requirement for all group profiles, because group profiles cannot belong to another group profile. Because the GRPPRF parameter defaults to *NONE, normally you do not have to key in this parameter.

Now change users MARIA, LOURDES, and WANDA, so they reference GRP_HUM as their group profile. Because all three users work in the Human Resources department, they reference GRP_HUM.

CHGUSRPRF USRPRF(MARIA) GRPPRF(GRP_HUM) CHGUSRPRF USRPRF(LOURDES) GRPPRF(GRP_HUM) CHGUSRPRF USRPRF(WANDA) GRPPRF(GRP_HUM)

From now on, you can authorize all three users to the same objects, in a single stroke, by authorizing their group profile, GRP_HUM.

Two commands come in handy when working with group profiles. First, you can list the users who belong to a group profile using the DSPUSRPRF TYPE(*GRPMBR) command:

DSPUSRPRF USRPRF(GRP_HUM) TYPE(*GRPMBR)

Then, you can list all user profiles, broken down by the group profile in which they belong, using the DSPAUTUSR SEQ(*GRPPRF) command:

DSPAUTUSR SEQ(*GRPPRF) OUTPUT(*PRINT)

You may specify up to 15 supplemental group profiles in the SUPGRPPRF parameter of the CRTUSRPRF AND CHGUSRPRF commands. The user inherits authority from the supplemental group as well as from the primary group profile, In the following example, Maria receives authority from two group profiles, one for Human Resources and one for Payroll.

CHGUSRPRF USRPRF(MARIA) GRPPRF(GRP_HUM) SUPGRPPRF(GRP_PAY) Authorization Lists

Authorization lists are objects of type *AUTL that always reside in QSYS. You can create, delete, and maintain their contents.

Within the authorization list are entries, each of which contains a user profile name (or group profile) and an authority value such as *USE or *CHANGE.

An authorization list can secure any number of objects by attaching the authorization list to the objects it secures. When you attach the authorization list to an object, the object adopts the list of users and authorities contained within the authorization list. For example, secure output queue QPRINT with an authorization list, which you can call AUTL_ONE, as follows:

CRTAUTL(AUTL_ONE) AUT(*EXCLUDE) GRTOBJAUT OBJ(QPRINT) OBJTYPE(*OUTQ) AUTL(AUTL_ONE)

The first command creates the authorization list. The AUT parameter defines the default *PUBLIC authority. This authority applies to users who are not listed in the authorization list and do not have specific authority through their own user profiles or their group profiles.

The second command attaches QPRINT to AUTL_ONE. Up to this point, however, AUTL_ONE has been empty. A few entries are added as follows:

ADDAUTLE AUTL(AUTL_ONE) USER(VICKY) AUT(*USE) ADDAUTLE AUTL(AUTL_ONE) USER(GREG) AUT(*CHANGE) ADDAUTLE AUTL(AUTL_ONE) USER(KIM) AUT(*ALL)

Because users VICKY, GREG, and KIM are in the authorization list with *USE, *CHANGE, and *ALL authorities (respectively), all objects secured with AUTL_ONE will share those authorities.

You can remove authorization list entries using the RMVAUTLE command, or use the Edit Authorization List (EDTAUTL) command to work interactively and visually, which is better.

Two handy commands are available to work with authorization lists. The first, DSPAUTL, displays the entries (user name and authority) contained in the authorization list. The second, DSPAUTLOBJ, lists which objects are secured with a given authorization list.