Erik, Do you need to specify a password?
Could you define a RACF profile instead, and use RACF check to see if the userid has access to that profile? I dont think there is a Callable function for it, but you could write some glue code to call an assembler routine to do a RACROUTE call. You could use an existing class, such as APP. I dont think it needs to be APF authorised... but you would need to check this. Colin On Mon, 21 Feb 2022 at 12:39, Erik Janssen <[email protected]> wrote: > Hello List, > > We are creating some APIs with python flask running on z/os (some in > combination with z open automation utilities in order to drive existing > rexx / ispf edit macro logic) and that is looking very promising. In order > to properly protect those APIs I am trying to create a authorization API, > that would call a module that can verify a RACF user/password/appl > combination so that it can return a token with which - for some time - you > can then call the actual API's. I've managed to create an assembler DLL > that works with that principe, calling the neccessary RACROUTE's. But, > since this module needs APF authorisation I can only see a way to call the > module as a subprocess through an - apf authorized - c main wrapper > program. In this case it will return the SAF RC and the actual wto message > as stdout. But, specifying a password this way as a cmdline parm means that > it would show up in ps screen in SDSF for example. > Loading the assembler DLL in python through CDLL technically works, but > actually will get a S683 abend, since it lost its APF authorisation. > My idea was that the module will check if the caller is authorized to > actually check the specified user/password by some custom racf profile, so > that I can prevent it from generally being allowed to check all > user/password combinations. > Apart from the obvious risks involved in APF authorized routines, giving > this principe that I would like to create a routine that - in a controlled > way - could do password checking for unauthorized callers, what options are > there to do so? > As far as I can see, the only option would be to provide some PC routine, > with a unauthorized stub that can call the authorized running PC 'backend', > but I'm not even sure if that would be a proper way to use a PC routine > (let alone the fact if I would ever manage to - securely - create one). > > Kind regards, > Erik. > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
