I just tried an experiment based on a suggestion here. Remove the USERID= and PASSWORD= from the JCL JOB statement.
Lo and behold. The job runs and a message in its log shows “job assigned to user xxx” (the user authenticated at ftp login time. Perfect 👌 Problem solved, no user exit needed, no extra hoops to jump through. On Fri, Oct 31, 2025 at 11:27 Tony Harminc <[email protected]> wrote: > 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 > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
