Job User Name And Current Job User
May 19, 2015 Patrick Botz
|
I see developers make one mistake way more often than any other. They assume that the job user name also represents the user profile under which a job is currently executing. This is, and always has been, an invalid assumption. The job user name only represents the userID under which the job was originally started. The user profile that a job is executing under at any given point in time (i.e., the current user) may or may not be the same as the job user. This may seem like a trivial and harmless mistake. But it often isn’t. In previous tips and posts (see the Related Stories below) I’ve described a security architecture that is effective, cheap to implement and, most importantly, creates an access control environment that is cheap to administer. Briefly, the preferred security architecture is one where:
Using the job user instead of the current user often makes it much more costly to retrofit existing applications with this architecture. This is because many of the mechanisms provided by the OS for developers to use to accomplish item 3 above manipulate the current user and groups values. The system never uses the job user value to check authority to an object. (The one exception to this has no effect on this discussion.) When implementing an application, developers need to consider the how the security architecture is implemented before determining whether they need to use the job user or the current user. In nearly all cases, developers actually need the current user value. There may be the odd case where they really do want the job user, but this will usually only occur, in applications that were implemented with the preferred security architecture. So how do you find the current user for a job? Easy. You use the same tools you use to get the job user. You just refer to a different value. In CL, RTVJOBA command retrieves both values. The USER parameter contains the Job user. This is what nearly everyone uses. The CURUSER parameter contains the current user value. When retrofitting an application, the change is trivial. Assume you have existing CL code that retrieves the job user value. Something like the following code snippet appears in your CL program: DCL &USRPRF CHAR(10) /* The user of the job */ RTVJOBA USER(&USRPRF) /* Retrieve the user of the job */ /* . . . rest of the code */ You only need to make the following change to use the correct user information: RTVJOBA CURUSER(&USRPRF) /* . . . rest of the code */ In RPG and other programming languages, the QUSRJOBI API returns the same values. One difference that could create some complexity, however, is that the current user value is only returned in the JOBI0600 receiver format. This format incurs a higher performance hit than the JOBI0100 format. If the performance of this particular application is of extreme importance, then you will want to do some performance testing before rolling the change into production. The changes required in your application will depend entirely on each specific call to the API. If the only reason you call the API is to get the name of the user under which the job is executing, then you will only need to change the format name and the offset from which you copy the user value. If, however, your code uses other values returned by the API, then more changes may be needed. You may need to add an extra call to the QUSRJOBI API to get the current user. Here is the link to the QUSRJOBI API documentation. As President and CTO of Botz & Associates, Patrick’s expertise includes security strategy, security policy enforcement, password management, single sign-on (SSO), industry and government compliance, and biometrics. He is the architect of the SSO stat! service. Previously he worked as Lead Security Architect at IBM, and he founded the IBM Lab Services security consulting team. You can connect with Pat here. RELATED STORIES
|
