On Fri, 31 Oct 2025 at 13:27, Donald Russell < [email protected]> wrote:
> Hi Tony, > > Here's a sample workflow. Originating on a zLinux system web page, a user > fills in a form and two of the fields are for their z/OS userid and > password. > The user creates an OTP with a yubikey or phone app. > So the user is already authenticated (by some means not relevant here) to the web page? To be able to run the workflow that does the FTP. > The web server code builds JCL, inserts the specified userid and (now) OTP > in the JOB USERID= PASSWORD= fields. > The web server uses those credentials to start an FTP session to JES... > then it uses 'site filetype=jes' and 'put's the jcl file. > > The problem is the one-time password is consumed by the ftp login. Ah... > The process worked fine when passwords/phrases were used because the ftp > login > was successful, then the JCL job file was submitted and it uses the same > credentials. > > Now that user authentication is done by one-time password, that no > longer works... I need a TTP (two-time password) :-) > Well the concept of a TTP (or more generally an nTP) is not completely unrealistic. But I think the trick is to in some sense capture the fact that the the user has been authenticated (via OTP) and that that authenticated state should be passed on to the next stage. And that's just what a PassTicket is good for, but in this picture it would have to be generated by the FTP server once it's validated the OTP. You suggested a user exit right in your initial post, and that would be the logical place to do the PassTicket stuff. I don't know the FTP server and whether there even are user exits, but given that that server and the batch job are running on the same box (or maybe a sysplex member, but no matter) then having RACF do all the PassTicket work would make the exit code pretty easy. But not "no code at all". Well I just had a quick glance at the available exits in the FTP server. There is one called FTCHKJES that gets passed the job card and can accept or reject it. What isn't clear is if it can modify it. The IBM-supplied sample just rejects if some magic value is not present on the job card. So I dunno... Tony H. On Fri, Oct 31, 2025 at 9:49 AM Tony Harminc <[email protected]> wrote: > > > On Fri, 31 Oct 2025 at 12:10, Donald Russell < > > [email protected]> wrote: > > > > > We have systems external to z/OS that submit jobs to JES over encrypted > > ftp > > > sessions. We “site filetype=jes” then “put” a jcl file. > > > > > > Unfortunately the JCL JOB statement uses the same USERID= and PASSWORD= > > > values as were used to authenticate for the ftp connection. That all > > > worked perfectly until password/phrases were replaced with OTP. > One-Time > > > Password. > > > > > > > So I'm clear, this authentication of the OTP is done in the external (non > > z/OS) system? > > > > > > > > Well, the one time use gets into ftp, now the submitted job fails > because > > > the password check fails. > > > > > > > What credentials does the remote FTP use to connect to the z/OS FTP > server? > > The same as what's on the JOB card? > > > > I’m not on the z/OS side of things, but I want to help them by providing > a > > > possible solution. I’m thinking a user exit could vet the JCL > submitted > > > through site filetype=jes to skip the password check when the job is > > > submitted that way. The exit should either (en)force the JOB USERID= > > value > > > to match the ftp id, or perhaps recognize a special userid id of FTPJES > > > that the user exit would change to the ftp user logged in and accept > the > > > job without further password checks. > > > > > > > I'm not clear on how this would keep unauthorized FTPers from submitting > > the job. > > > > Could the submitting end generate a RACF PassTicket to be used instead > of a > > static password? This is discussed in the RACF Security Admin Guide > > https://www.ibm.com/docs/en/zos/3.1.0?topic=guide-using-passtickets . > The > > gory details of generating your own PassTicket off z/OS are at > > > > > https://www.ibm.com/docs/en/zos/3.1.0?topic=passticket-generating-evaluating > > . > > > > Tony H. > > > > ---------------------------------------------------------------------- > > 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 > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
