PowerTech Authority Broker provides a safe way to inherit authority by using a powerful IBM i feature.

In last month's TechTip, I spent some time talking about how users can inherit authority through group profiles. Despite my strong support of group profiles, I warned of the vulnerabilities of groups when not carefully architected. Inheritance of a group's private and special authorities can make users far more powerful than their base profiles might suggest. This risk increases if users are assigned to multiple groups. To help manage this, I suggested using PowerTech Compliance Monitor to quickly and easily report on a user's special authority—including those authorities gained via inheritance from a group.

A lesser-known, but arguably more powerful, inheritance technique is the profile swap. Introduced by IBM to support TCP/IP services, a profile swap allows a job to change midstream to run under a different profile than the one that started it. For example, when the FTP server starts, its "listener" jobs all start and run under the QTCP profile. However, when a user subsequently logs in to FTP and issues a request, we obviously want the authority check to be run against the logged-in user rather than QTCP. To support this, the OS performs a switch from the QTCP profile to the logged-in user before executing the request.

To see this support in the operating system, run the Display Job (DSPJOB) command and select option 1. You will see not only the traditional job name, user, and number at the top of the screen, but also the "current user profile." This normally contains the job user but also indicates when there's an active profile swap. Programmers should note that the RTVJOBA command was enhanced with the current user (CURUSER) parameter to allow the retrieval of the currently active user separately from the original job user. Unless the job user is to be retrieved regardless of an active swap, I recommend using CURUSER instead, as this parameter still returns the job user information if there's no active swap.

Many people ask me if a profile swap is the same as adopting authority—a programmatic technique that allows a user to gain the additive authority of an application program object's owner. A full explanation of authority adoption is outside the scope of this article, but the basic premise also is to provide temporary elevation of authority. There are, however, some distinct differences between adoption and a profile swap:

• Authority adoption works only for native object access and does not carry through to IFS objects. A profile swap is effective in both native and IFS environments.
• Adoption is cumulative for each program called. While several techniques prevent adopted authority from carrying through to a subprogram call, the default setting allows authorities to accumulate. You can adopt the authority of multiple profiles as additional programs are called.
• Profile swapping relinquishes the authority of the original profile before assigning the authority of the swap profile. This enables the unique ability to lower the authority of a user (for example, a user with *ALLOBJ special authority can swap to a profile that has read-only rights before accessing Query.)
• Adoption never alters who the underlying profile is during the adoption process. In contrast, a profile swap literally changes the user to the target user—almost as if they had signed on. The user therefore assumes run-time attributes beyond just authorities, such as default output queue and command line access.

PowerTech Authority Broker removes the heavy lifting associated with profile swaps, and enhances the functionality far beyond the raw API support found in the base operating system. So much functionality, in fact, that IBM used to include it on their CDs!

Authority Broker users can use preauthorized swap profiles to obtain a temporary change in authority. You can run the swap directive from a command line or embed it in a program. This makes the swap transparent to the end user (think contractors and software vendors!) Real-time notifications can advise managers and auditors when users temporarily alter their authority (see Figure 1), and you can run detailed reports of command-line activities after they're done. Of course, Authority Broker supports segregation of duties, time-restricted switching, tamper-proof logging, and activity exporting.

Figure 1: PowerTech Authority Broker satisfies regulatory compliance requirements by controlling and auditing profile swaps for elevated access. (Click image to enlarge.)

Click here for more information on Authority Broker. To learn about the entire line of PowerTech security solutions, visit www.powertech.com.

as/400, os/400, iseries, system i, i5/os, ibm i, power systems, 6.1, 7.1, V7, V6R1

Robin Tatam is the Director of Security Technologies for PowerTech, a leading provider of security solutions for the System i. As a frequent speaker on security topics, he was also co-author of the Redbook IBM System i Security: Protecting i5/OS Data with Encryption. Robin can be reached at 952.563.2768 or This email address is being protected from spambots. You need JavaScript enabled to view it..