It's simple enough to write your own CICS signon screen to allow for longer user IDs (and passwords/phrases), but I think CICS would have to add support for the EXEC CICS SIGNON command to allow for a longer user ID. Currently: " USERID(data-value) Specifies the 8-byte sign-on user ID.
The user ID supplied is converted to uppercase. " They did, of course, already add support for a "PASSPHRASE" of up to 100 characters. ________________________________ From: IBM Mainframe Discussion List <[email protected]> on behalf of Wayne Bickerdike <[email protected]> Sent: Monday, May 4, 2020 2:40 AM To: [email protected] <[email protected]> Subject: Re: IBM-MAIN Digest - 2 May 2020 to 3 May 2020 (#2020-125) There are more CICS users than TSO users. Is there a howto for the CICS signon screen to accept long IDs and Passphrases? On Mon, May 4, 2020 at 6:03 PM Timothy Sipples <[email protected]> wrote: > Bob Bridges wrote: > >So maybe - maybe, I don't know either - if I sign on to z/OS with a > >certificate, or LDAP, or anything other than the usual, the sign-on > routine > >MAKES UP an 8-byte ID and stores it in the ACEE. If so, after that > >everything works fine, I guess. > > I don't think RACF itself works that way, or at least the z/OS 2.4 > documentation doesn't suggest so. Take a look at this information, for > example: > > > https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.icha700/icha700_Certificate_mapping.htm > > Let's suppose the user is authenticating with RACF (not with the IBM > Directory Server for z/OS, a.k.a. "LDAP"), and the user transmits an X.509 > client digital certificate for that purpose. RACF has to know ahead of > time whether or not to authenticate that particular user (digital > certificate). So the digital certificate has to be known to RACF ahead of > time. Since the digital certificate has to be known, it's not unreasonable > to associate an up to 8 character "short" user ID with that certificate. > And that's how it works, as I understand it. The user doesn't present the > short user ID -- well, not really, I'll get to this in a moment -- but > RACF can check the certificate and create an ACEE with a mapped short user > ID. > > There are three basic choices here as I understand it: > > 1. A one-to-one mapping (one certificate to short ID ABCD1234). The > documentation does a little bit of handwaving here along the lines of > "this might be difficult to administer," but I'd argue that's somewhat > dated advice now that so many organizations use identity management tools. > > 2. A many-to-one mapping (multiple certificates to ABCD1234). > > 3. Either mapping, but with the certificate itself holding an embedded > short name ("hostIdMapping"). Certificate issuers don't typically support > this extension, or at least they hide it well, but the z/OS PKI Services > do. (Is this technique "cheating"? Not really....) > > In all these cases the user need not be aware there's a short name that > RACF uses "under the covers." The user just supplies a valid, unexpired > client certificate -- from a PIN-protected smart card perhaps. From RACF's > perspective the X.509 digital certificate is really just another alias, a > verbose one. > > z/OS LDAP also supports broadly similar RACF ID mapping (supply a long CN, > which the directory maps to a short name), but it's optional. You can > certainly authenticate with LDAP as a standalone matter if you wish. > > It's an interesting idea to have a fourth option for digital certificate > authentication with RACF, which would be like choice #1 but without > telling RACF what the short user ID is ahead of time -- to let RACF create > one "on the fly," probably with caching and templating. For example, allow > me to register a bunch of digital certificates in RACF as valid users, but > I'm not going to tell you (RACF) what their short user IDs are ahead of > time. The first time you encounter a particular certificate, just create a > short user ID of C$------ (where the dashes are RACF's randomized or > sequential choice, of any length -- randomized as default, but sequential > as an option), store it, and use that on-the-fly short ID to build the > ACEE. For example. I'd have to ponder that one a bit more, but if you > think you've got a good use case, ask (RFE). > > Of course it'd be "nice" to have more than a maximum 8 character ID (with > the current maximum of 39 different characters per position) internally in > RACF, but I imagine that'd be a big plumbing problem and potentially break > a lot of important stuff if not done carefully. Fortunately, you're not > required to limit users' experiences to maximum 8 character user IDs: use > LDAP CNs, use digital certificates, or use something else. > > By the way, if someone is looking for an interesting project, I'd be > pretty neat to have a sample TSO/E signon screen that accepts a LDAP CN > and passphrase that's then checked against the IBM Directory Server for > z/OS for authentication (and thus also with the SAF security provider, > indirectly). This part of the z/OS documentation starts to explain how to > do that: > > > https://www.ibm.com/support/knowledgecenter/SSLTBW_2.4.0/com.ibm.zos.v2r4.ikjb400/logpan.htm > > - - - - - - - - - - > Timothy Sipples > I.T. Architect Executive > Digital Asset & Other Industry Solutions > IBM Z & LinuxONE > - - - - - - - - - - > E-Mail: [email protected] > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > -- Wayne V. Bickerdike ---------------------------------------------------------------------- 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
