Good question, that's not an answer I know off the top of my head, but I will try and get one for you.
Hope you are well
There is no simple, non-exploitable way to transmute one User ID to another. In plain language, let's talk about the same individual who has an ID on one system named FRED and an ID on the other system named JOHN. The organization may be aware that FRED and JOHN are the same human, and that they gave this human two different RACF names (identities), but RACF does not know that they are the same, nor does RACF know that on one system when FRED shows up it is supposed to know that he his JOHN. There would have to some mechanism would look up FRED and find that (on that system) that person is actually JOHN. But most importantly, that second system would have to trust that first system when it asserts that FRED is actually FRED. In other words, the second system would have to believe whatever the first system said. While the trust issue is usually dispensed with (most shops just blindly assume that if someone arrived at the second system from the first system claiming to be ALICE that the first system has already done a good job of confirming that ALICE is actually ALICE), this would mean that originating systems would have to be made and managed to be as secure as target systems. (Most questions of this type from customers cast this issue in terms of the originating system being a relatively "open," not-as-well-controlled development or test environment, while the target system is a well-controlled, tightly-locked-down production environment.) If a facility were available to transmute FRED to JOHN, there would need to be additional consideration (and controls) regarding the source of the incoming (to be transmuted) identity; that is, FRED should not be mindlessly transmuted to JOHN, but it would be OK to transmute DEVLSYS.JOHN to PRODSYS.FRED, but not TESTSYS.JOHN to PRODSYS.FRED. Where would such a facility live and who would manage it. It would have to be as secure and trusted as RACF itself.
Some customers we know of that, for whatever reason, do not have a homogeneous security identity environment among all interconnected systems use ESM exit routines to perform this user identity transformation. A typical example would be a multi-site organization created due to a merger or acquisition where completely different security environments (including ESM type) existed beforehand and the naming convention used by each conflicts with the other's, making it difficult to simply define all IDs in each environment in the other environment (even if just for the system and subsystem performance administrators). Most such sites we are aware of have simply created a third scheme for naming user IDs and all the "systems and administration" humans use that family of IDs rather than ones for the original two (or more!) schemes.
From time to time we have (mostly new) customers pop up with a situation where there is a FRED ID on one system and a FRED ID on another system and the two FREDs are not considered to be the same person. That is an issue that we have been asked to solve several times, but the solution (whatever it might be) would be just as problem-prone as automatically transmuting FRED to JOHN.
While using one or more RACF exits is possible, the simplest solution is simply to give FRED and JOHN (the same human) a single identity (BOB) that is defined in both (or all) RACF environments.
Thanks for your answer, Bill.
We are on the same page regarding the security strategy.
I got back to my client and he has implemented security for software he developped crossing various sysplexes with different userid standards.
I would like to present his implementation as a basis for discussing a possible RfE:
RALF is the sysprog and has 3 userids in 3 different productive sysplexes. And he yet has another userid in his admin sysplex X.
PLEXX = RALFX
PLEXA = RALFA
PLEXB = RALFB
PLEXC = RALFC
In the config dataset of his software, he declares the RACF CLASS and the prefix of the RACF profiles, just like in BBSEC:
RACF_CLASS = FACILITY
RACF_PROFILE = MY.PROF
Now he defines in RACF Class (FACILITY) in SYSPELX X the profile
There just 3 qualifiers: Profile, Sysplex Name, 4. Qual = Userid in this particular Sysplex
RDEF CLASS(FACILITY) MY.PROF.PLEXA.RALFA UACC(NONE) OWNER(RACFADM)
RDEF CLASS(FACILITY) MY.PROF.PLEXB.RALFB UACC(NONE) OWNER(RACFADM)
RDEF CLASS(FACILITY) MY.PROF.PLEXC.RALFC UACC(NONE) OWNER(RACFADM)
Access right rights are given to the owner of the destination userid, here it is RALFX.
PE MY.PROF.PLEXA.RALFA CLASS(FACILITY) ID(RALFX) ACCESS(ALTER)
PE MY.PROF.PLEXA.RALFB CLASS(FACILITY) ID(RALFX) ACCESS(ALTER)
PE MY.PROF.PLEXA.RALFC CLASS(FACILITY) ID(RALFX) ACCESS(ALTER)
One could also envisage group access rights or various levels (READ, UPDATE, ALTER).
RALFX starts the software and wants to have access to the remote client. The software will check in the local RACF if there is a profile, if not it will take RALFX.
The original userid and the userid of the profiles will be sent to the remote client. The remote will then change the identity to the destination userid. That’s all.
For this scenario to work, the RACF admins of all sysplexes involved need to trust each other.
When the remote client detects the identity change, it wil check in it’s local RACF using the profile, if this user has the correct access rights.
So everything is executed within the authorized and encapsulated environment the software.
Could such an implementation also work for Mainview BBI-3 security instead of the default userid?
best regards and stay safe,
To ensure we capture, understand and track this correctly, please raise an RFE with your local support centre.
5 of 5 people found this helpful
Customer environments with a non-homogeneous ID namespace are not common, but they do exist (and keep showing up for the previously stated reasons), so this issue gets raised regularly, albeit infrequently. In the past we have seen proposed, and devised ourselves, such schemes. In the context of a specific customer environment and an existing user identity namespace (i.e., User ID naming convention), it can be argued that they should work and address the problem at hand, at least as understood by that customer. The problem is that any given one of these proposed (and seemingly workable) approaches to a solution to the issue works for the customer environment for which it is proposed, but fails utterly for all other (theretofore previously-encountered) customer environments. The reason why is that all such solutions depend on some underlying feature or attribute of the User ID namespace(s) to function correctly. If we were to implement such a namespace-dependent solution it would not necessarily work for others or the next one that came along.
The specific scenario that you described (with those four User IDs, RALFA, RALFB, RALFC, RALFX, and the resource names proposed) does seem to address the problem for the specific environment for which it was devised. But in fact it does not solve the problem in general. What it does cause to happen is a User ID switch. When the request from the local system (from User ID RALFX) arrives at the remote system on, for example, PLEXB, it arrives with the instruction (or request) that the User ID there (on PLEXB) be changed from RALFX to RALFB. That request is then authorized (on PLEXB) by asking RACF (on RALFB) if User ID RALFX has access to the resource MY.PROF.PLEXx.RALFB; if so, then the user identity switch from RALFX to RALFB is made. Thus, a request from RALFX (on PLEXx) causes the User ID that will actually be used to be, in one sense, changed from RALFX to RALFB. So, yes, that scheme would work. But note that in order to determine (via RACF) if User ID RALFX has access to MY.PROF.PLEXx.RALFB on PLEXB (say), User ID RALFX MUST FIRST EXIST AND BE DEFINED ON PLEXB. If the User ID RALFX is already defined on PLEXB, then the user, RALFX, could just be used AS IS. No User ID switch is necessary.
This is not the general problem to be solved. The problem that needs to be solved is that when a request from User ID RALFX arrives at PLEXB from some other Sysplex (with a different User ID namespace, if not a completely different User ID naming convention), some piece of software at PLEXB needs to be able to authoritatively say that User ID RALFX [from whatever Sysplex it arrived from] needs to treated as if it were RALFB originally (as if RACF at the originating Sysplex had authenticated User ID RALFB originally, which it could not have done because RALFB was not defined on the originating Sysplex). In other words, software at a destination or target (or "remote" in your explanation) needs to be able to determine that an incoming connection request from RALFX (or some other User ID) needs to be treated as if it were a request from RALFB (not RALFX). Another way to think of what needs to happen is that each target Sysplex has a table in which two arguments, the source Sysplex and the source system's User ID, are used as a key to find a row in that table, which holds a local (target system's) User ID. In practice, one might think to include additional qualifiers (or arguments) in that table lookup, such as an "application" (think of that as something like MAINVIEW, TSO, IMS, CICS, JES, NJE, etc.).
Conceptually, doing such a table lookup is what needs to happen, but it needs to happen either within the authentication path (VERIFY) or with the support of (using some other, new interface) the ESM itself. The MainView Enhanced Security interface could drive such a process using some feature or capability of the ESM itself, but such a feature or capability would first need to exist. There is no such existing capability within RACF, and no simple way to implement such a table lookup-like facility using RACF. Regardless, whatever scheme would be hatched would need to work with ACF2 and TSS (Top Secret) as well, and there is even less hope there (for anything compatible). Of course, we could devise some different sort of scheme for ACF2 (likely none is possible for TSS), but they would have to work with intermixed, non-homogeneous ESM CASplexes (we have many customers who have mixed ESM environments -- and a small number who have all three). In practice, even such simple straightforward table lookup-like schemes would need additional authorization mechanisms to be put into place (one example of such is the target or "remote" Sysplex authorization that you illustrated in the sample scenario you detailed), but again a solution common to all three ESMs would be most desirable.
There is a reason IBM says that the best practice is simply that FRED is FRED is FRED. It's a hard problem. That is not to say that there is no solution. It is just the case that there is no existing simple solution. We have conceived an academically correct technical solution that involves the use of digital user certificates, such as those we now support with MainView Explorer, but (assuming we could even make that work with the existing interfaces for all three ESMs), the administrative burden and client practices that would need to be put into place would be much more onerous and awkward that the simple, straightforward, and already-understood and supported solution of defining a single user identity (User ID, LOGONID, ACID) in all security domains to be used by an individual end user.
This issue remains unaddressed because the technical problems remains unresolved. We need a general solution that works with all ESMs. We would be willing to implement separate ESM-dependent solutions, but none that are technically approachable are currently seen to exist (none that are simple and easily implemented have been demonstrated to be defensible under audit). There is not even any straightforward way to implement a table lookup-based scheme in RACF (and all approaches to that require prior knowledge of the answer sought or a previously-known or dictated User ID naming convention, if not some sort of homogeneous user identity namespace -- which is, after all, as aspect of the issue which is purportedly being addressed as a problem in the first place).
Do not let this discourage you. We welcome any proposal. But remember that it needs either a general, ESM-independent solution, or three separate ones that will interoperate -- somehow.
Thanks a million for your very elaborate answer.
I will forward it to my customer and get back to you.