First let me explain the assumptions that I made so that I could answer your question.
- I assume that an application user needs authorization from a supervisor to complete a transaction.
- You want to have some pop-up box or window be displayed so that a supervisor and enter their password, thus "approving" the transaction.
There are two ways to approach this problem -- one using OS/400 user profiles and the other, using a validation list. I recommend the validation list approach.
There is no command or API that its purpose is to validate that you have the right password for a particular user. There is an API that you can use that will accomplish the same thing, however. To have the transaction verified using the supervisor's OS/400 user ID and password, you would have to use the QSYGETPH API. This API is normally used to get the process to be running under a different profile. This is called a profile swap. To be able to swap to a different profile, you must either have sufficient authority or know the user's user ID and password. You could pass the API the supervisor's user ID and password and if you get back a profile handle, then you know that it is a valid user ID/password combination. However, you will want to release any handles that are generated because there is a limit as to how many handles you can have per job.
Using the validation list approach, is, in my opinion safer. A validation list is a method to store user identifiers (for example, a user name) and their authentication information (for example, a password.) You use the validation list APIs (documented in IBM's Information Center) to add a validation list entry. This would be the supervisor's user name and their password. This is not the same as their OS/400 user profile name. In fact, I would recommend that they be different. A validation list user is not a "real" user. If presented with a sign on screen, a validation list user cannot sign on because there is no corresponding OS/400 user profile for them. You could prompt for the supervisor's user name and password, then pass these values to the validation list API to check for validity. An indication will be returned to let you know if the combination is valid.
There are several advantages to this approach:
1. The supervisor does not need an OS/400 user profile.
2. If the supervisor does have an OS/400 user profile there's a greater chance their password could become compromised if they were constantly entering it for a transaction validation. It would be less dangerous if the validation list password was compromised.
Both solutions require that you code to APIs for the verification. The validation list approach requires a bit more coding to code for user registration as well as to code for administrators to change their validation list password.
================================== MORE INFORMATION ON THIS TOPIC ==================================
The Best Web Links: tips, tutorials and more.
Search400's targeted search engine: Get relevant information on security.
Ask your systems management questions--or help out your peers by answering them--in our live discussion forums.
Check out this Search400.com Featured Topic: Top ten security tips
This was first published in July 2003