A client on our AS/400 requires a production ID set up with extra security to allow the programmers to do some things they cannot do with their own ID's. What I want to do is when one of the programmers logs on with the production ID call in a program that will have the user enter his or her own ID and password and update a log before allowing them into the production ID. Has anyone ever called in the password API in a program that allows you to compare a users password? If so how is it done? Thanks in advance.
Unconfigured Ad Widget
Collapse
Announcement
Collapse
No announcement yet.
Calling password API in CL program
Collapse
X
-
Calling password API in CL program
Wade, Take a look at the Get Profile Handle (QSYGETPH) and Set Profile (QWTSETP) APIs that are documented at http://publib.boulder.ibm.com/pubs/h...s/QSYGETPH.htm , and http://publib.boulder.ibm.com/pubs/h...s/QSYRLSPH.htm . The Get Profile Handle API will take a user-ID and a password, verify the password and then return a profile handle. Ed Fishel
-
Calling password API in CL program
John, I'm testing the API's QSYGETPH, QWTSETP and QSYRLSPH by calling a utility CL program that initially gets the profile handle and swaps the profile. I then do some processing in my main CL program and then call the CL program again to release the same handle (via a parm) with QSYRLSPH. The problem is that when my main CL program is finished, my signon user profile is not the current profile. Isn't QSYRLSPH supposed to "unswap" the profiles for me? Or do I need to "unswap" the profiles myself with additional calls to QSYGETPH and QWTSETP? Thanks Chris Ringer
Comment
-
Calling password API in CL program
Hello Chris, You have to save the original user's handle and explicitly swap back to it, here's an example: http://publib.boulder.ibm.com/cgi-bi.../QB3APD03/A.22 Best regards, Carsten Flensburg
Comment
-
Calling password API in CL program
Perhaps, I should explain my situation... As far as I know, the IFS does not support adopted authority but I have users that need to copy/delete/rename files in IFS folders where the users ordinarily only have *Read authority. I can meet this demand by temporarily swapping profiles for the interactive job (needs to be done interactively, not in batch). Does anyone have a better idea? Thanks. Chris Ringer
Comment
-
Calling password API in CL program
You are correct about the Integrated File System not using adopted authorities as we conventionally associate them with a program. In V4R5 there are however new Unix-type APIs that provide many of these types of functions. Check out the various Set group ID, Set effective group ID, Set effective user ID, etc. APIs found in the Integrated File System APIs category.
Comment
-
Calling password API in CL program
Hello Bruce, Is the CPYFRMSTMF command included in the non-adopting IFS security setup? Currently I have a problem where a program adopting *ALL authority to the target file gets a CPFA09C exception when issuing a CPYFRMTSTMF command. If I change the file's *PUBLIC authority to *USE or give the user *USE private authority to the file the command works fine. If I then remove adoption from the program it fails again - *USE is of course not enough to replace the member. And that's what puzzles me - the adopted *ALL authority is only providing *CHANGE plus *OBJMGT access in conjunction with a public or private *USE authority to the file? Best regards, Carsten Flensburg
Comment
-
Calling password API in CL program
I can fully understand your puzzlement on this. What's happening is that CPYFRMSTMF is using traditional file interfaces to the target file, and so while the Integrated File System command is not using the adopted authority, the underlying implementation of traditional data management (that is called) is. Normally we don't see implementation details like this surface to the user, but this is an unfortunate exception to that general rule. Whether this would be considered a bug or a feature I'm not sure.
Comment
-
Calling password API in CL program
I've just implemented the so called "application-only" security concept - pretty close to the original design as laid out by Wayne O. Evans: The user is member of a group having *USE authority to the production programs through an authorization list - the program adopt the owner's user profile who has - again through an authorization list - the necessary authority to access production data. - And apart from this "mix of concepts" it works very fine! I'll try and see if the API's you mention will allow me to circumvent the problem once we get V4R5 loaded. Thanks for shedding some light! Best regards, Carsten
Comment
-
Calling password API in CL program
Gene,> I'm trying to call QSYGETPH in a job spawned from an autostart job and I'd rather not use adopted authority. Is naming a profile with SPCAUT(*ALLOBJ) in the ADDAJE command's job description a reliable solution? <<
This does not sound particularly secure to me. Unless you swap the user profile, both the autostart job and the spawned job will have *ALLOBJ special authority for everything they do. A safer solution would be to: 1. Use a profile for the autostart job entry (and the spawned job) that does not have any special authority. 2. Set the public authority of the program that will adopt *ALLOBJ authority to call QSYGETPH to *EXCLUDE. 3. Grant private *USE authority to the program that adopts to the user profile used by the spawned job. 4. Do your best to minimize the work done by the program that adopts *ALLOBJ authority. Possibly by splitting it into two programs, one that adopts and one that does not adopt.
Comment
-
Calling password API in CL program
Chris, The QSYRLSPH API releases a profile handle so that it can't be used again. It does not restore you to your original profile. As Carsten suggested, you should save the profile handle of the original user and swap back to it when you want to resume operations as the original user. If you don't save retrieve the profile handle of the original user before you make your first swap, you may find that you are not authorised to swap back to the original user because the swapped to user is not authorised to the original users profile (it becomes clearer when you think about it). jte MC Security Editor
Comment
Comment