While group profiles can make managing authorities more efficient and versatile, inheritance of a group’s private and special authorities can make users far more powerful than their base profiles might suggest. An answer to that weakness can be found in a lesser-known—but arguably more powerful—inheritance technique called profile swap, which allows a job to change midstream to run under a different profile.
For example, when the FTP server starts, its “listener” jobs start and run under the QTCP profile. When a user logs in to FTP and issues a request, though, we want the authority check to be run against that user rather than QTCP. To support this, the OS performs a profile swap 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, which will show 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.
There are some distinct differences between adopting authority—which gives a user temporary authority via the owner of an application program—and a profile swap:
- Authority adoption works only for native object access. A profile swap is effective in both native and IFS environments.
- 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 swapped 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 the underlying profile during the adoption process. In contrast, a profile swap literally changes a 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 for IBM i removes the heavy lifting of profile swaps and enhances functionality far beyond the raw API support of the base operating system. So much functionality, in fact, that IBM used to include it on their CDs!
Users of Authority Broker for IBM i can use preauthorized swap profiles to obtain a temporary change in authority. Users can also run the swap directive from a command line or embed it in a program, making 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; and authorized users can run detailed reports of command-line activities after they’re done. Authority Broker for IBM i also supports segregation of duties, time-restricted switching, tamper-proof logging, and activity exporting.
Lessen the risk of data loss and corruption with privileged user management software. Find out how Authority Broker for IBM i can enhance your system security when you request a demo.