As of today only WebSphere Liberty on z/OS and z/OS Connect EE (which is also based on WebSphere Liberty on z/OS) can only map the distributed user ID in a JWT token to a mainframe user ID in SAF/RACF. This is a problem when there is no equivalent personal user ID in SAF/RACF, which is a very common scenario (for instance often only a few bank employees today accessing 3270-based mainframe applications have a user ID in SAF/RACF). When now a distributed application should call a mainframe application or a mainframe application, which today has an application-internal security should be modernized and use standard security mechanism instead, the limited mapping capabilities can become a huge problem - especially in z/OS Connect EE and traditional mainframe backend systems accessed by WebSphere Liberty on z/OS and/or z/OS Connect EE like DB2, IMS and CICS. For such a scenario it would be helpful if WebSphere Liberty on z/OS and z/OS Connect EE could map a role in JWT token to a technical user ID in SAF/RACF, which is then being used for authorization checks in such backend systems. Since there could be multiple roles in a JWT token there may be a need to configure which role should be mapped per application in WebSphere Liberty on z/OS or per API in z/OS Connect EE. There may be also a need for a precedence of roles taken into account for a mapping per application / per API since there could be different roles for different sets of privileges within a single application / API (for instance read-only vs. update access).
One concrete sample scenario in which such a mapping capability would be very helpful:
A traditional IMS application, which today is being invoked from an old-school fat client frontend using a technical SAF/RACF user ID for the authentication with IMS as well as for authorization checks in IMS and DB2 and personal user ID sent as part of the application data for application-internal authorization checks, should be modernized with a new web-based frontend in WebSphere Liberty using z/OS Connect EE to the communication with the backend IMS application. The web-based frontend should use single sign-on and get a JWT token from an OpenID Connect provider such as ADFS or Keycloak. This JWT token should be used to authenticate with WebSphere Liberty and z/OS Connect EE, but since IMS can't handle JWT tokens the underlying WebSphere Liberty server in z/OS Connect EE should map a role in the JWT token to a technical user ID in SAF/RACF. In addition to this the IMS Service Provider of z/OS Connect should take the distributed user ID from the JWT token and set it into a header field, which IMS then would log with the request and the IMS application then can use to evaluate (this is already possible with the IMS Service Provider of z/OS Connect today). Besides the modern frontend and communication and the comfortable single sign-on the big difference compared to the previous solution from a security point of view is, that the personal user ID is not part of the application data anymore and so couldn't be manipulated as easy as before anymore. Of course it would be even better to have personal user IDs in SAF/RACF as well, but this would require to add thousands of personal users to SAF/RACF, which are not there today. It would also require to have user change their mainframe passwords or to exchange passwords automatically whenever the user changes it on a distributed platform.
