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
