Not CESL..... On Mon, May 4, 2020 at 6:40 PM Wayne Bickerdike <[email protected]> wrote:
> 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 > > -- Wayne V. Bickerdike ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
