View Full Version : Calling password API in CL program
01-01-1995, 02:00 AM
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.
01-04-2001, 10:25 AM
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/html/as400/v4r5/ic2924/info/apis/QSYGETPH.htm , and http://publib.boulder.ibm.com/pubs/html/as400/v4r5/ic2924/info/apis/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
01-04-2001, 10:33 AM
Wade - You might look into the CHKPWD command if you are writing CL and only want to verify that the correct password was entered. I would be very careful with the security of the program itself, though. HTH, Steve
01-08-2001, 09:45 AM
Check out the January Security Patrol column in MC. There is a program there that uses the QSYGETPH and QWTSETP API's to do what you want to do. jte
02-06-2001, 09:15 AM
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
02-07-2001, 12:13 AM
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-bin/bookmgr/BOOKS/QB3APD03/A.22 Best regards, Carsten Flensburg
02-07-2001, 05:22 AM
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
02-07-2001, 08:30 AM
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.
02-08-2001, 03:07 AM
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
02-08-2001, 07:57 AM
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.
02-08-2001, 08:15 AM
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
02-12-2001, 09:13 AM
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?
02-12-2001, 10:12 AM
Gene, <blockquote><tt>> 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? << </tt></blockquote> 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.
02-12-2001, 11:06 AM
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
Powered by vBulletin® Version 4.1.5 Copyright © 2013 vBulletin Solutions, Inc. All rights reserved.