Looking to run a proof of concept to increase security.
Is it possible to pass a userid greater than 8 characters from Gen Java Proxy client to Gen z/OS server?
If so, can you parse it so that the first part of the userid lets the transaction run under that context and the 2nd part of the userid can be used to populate the userid field in GLOBDATA?
The middleware being used is TCP/IP Direct Connect for CICS (TISRVMSL listener).
Release : 8.6
Components: Java Proxy client and TCP/IP Direct Connect for CICS (TISRVMSL listener)
1. To pass a userid greater than 8 characters requires using Enhanced Security. This enables the client_user_id variable to be populated with a client side userid that is up to 64 characters.
Java Proxies have support for Enhanced security in security user exit CFBDynamicMessageSecurityExit located in directory "%Gen86%\Gen\classes\com\ca\gen\exits\msgobj\cfb" : Distributed Processing > Working With Proxies > Java Proxy (Classic Style) > Preparing for Execution of Java Proxy (Classic Style) Application.
There is more detail of the content of CFBDynamicMessageSecurityExit.java visible under Web Generation user exits page CFBDynamicMessageSecurityExit - Web Generation CFB Dynamic Message Security Exit.
2. CICS servers also have support for Enhanced security. The TIRSECVX user exit needs to be coded to deal with ENHANCED-SECURITY-FLAG and allow the server to continue processing. Referring to:
"If so, can you parse it so that the first part of the userid lets the transaction run under that context and the 2nd part of the userid can be used to populate the userid field in GLOBDATA?"
All security validation (EXEC CICS VERIFY PASSWORD... ) should be done in TIRSECVX. As long as a valid userid is used for the Security calls (CICS and RACF/TSS/ACF2 ) the security validation should work fine. Any other required steps can be be done with the security data provided in the exit.
To populate GLOBDATA's userid, use the CLIENT-USERID field in GLOBDATA, which is passed to and returned from TIRSECVX. It is 64 characters.
There is a note in TIRSECVX that explains that since there are 2 CLIENT-USERID fields defined in the program they need to be used as 'CLIENT-USERID IN GLOBDATA' or/and 'CLIENT-USERID IN TIRSECVX-CMCB' .
NOTE: GLOBDATA field PSMGR-USER-ID can also be populated with any 8 bytes out of CLIENT-USERID (IN TIRSECVX-CMCB) in the customisation of TIRSECVX and its value is then returned back to the Server Manager. However the only place where the runtimes appear to pass PSMGR-USER-ID is to the TIRTERMA user exit and that is only used in Block Mode applications and not Servers. On the other hand, CLIENT-USERID (in TIRSECVX-CMCB and in GURB ) is used in Servers in both Client to Server and Server to Server applications.
3. Note that the server transaction context is set when the server is started - in this case by TISRVMSL.
TISRVMSL does not get visibility to the Enhanced Security data. Instead the client runtime extracts the first 8 characters of the CLIENT_USER_ID used by Enhanced Security and places that in the part of the request that is available to TISRVMSL. TISRVMSL also has access to flags that indicate Enhanced Security and/or Encryption is used. TISRVMSL passes the 8 character userid and the security flags to TIRSLEXT user exit where it can be decided how to process such requests. The TIRSLEXT contains information on the various security options and is covered in the User Exits documentation.
TISRVMSL uses this 8 character userid to start the server so that is the context the server runs under.
4. A few other things to consider:
a. Gen does have SSL support for Java Clients using TCP/IP so that is an additional/different security option.
b. Gen 8.6 introduced support for Password Phrase (Passphrase) for clients using Client Manager and TCP/IP. To support this changes to TIRSLEXT and TIRSECVX user exits were delivered. It was ensured that any changes for this feature will not cause regression issues when not using Passphrase but if/when z/OS PTFs LU06644 LU06645 and LU06986 PTFs are installed then changes/comments will be seen for that.
Customer used this custom code in TIRSECVX:
SET SECURITY-USED TO TRUE.
display 'start of TIRSECVX'
display 'g-client-userid:' CLIENT-USERID IN GLOBDATA.
display 'cfb-client-userid:' CLIENT-USERID IN TIRSECV-CMCB.
display 'g-PSMGR-USER-ID:' PSMGR-USER-ID OF GLOBDATA.
MOVE CLIENT-USERID IN TIRSECV-CMCB TO WS-CLIENT-USERID
if WS-CLIENT-USERID-DELIM = WS-DELIMITER THEN
display 'delimiter set'
MOVE WS-CLIENT-USERID-CCFUSER TO
CLIENT-USERID IN TIRSECV-CMCB
MOVE WS-CLIENT-USERID-CCFUSER TO
PSMGR-USER-ID IN GLOBDATA
MOVE WS-CLIENT-USERID-CCFUSER TO
CLIENT-USERID IN GLOBDATA
They found that GLOBDATA variable CLIENT_USER_ID has its populated data visible downstream but GLOBDATA variable PSMGR-USER-ID does not have its populated data visible downstream i.e. remains blank.
Gen Engineering advised code is not inaccurate and provided further subsequent advice around those variables:
The CLIENT-USER-ID is the field intended to be used by Servers for USERID.
The PSMGR-USER-ID is more for Block Mode applications.
Here is more information on PSMGR-USER-ID:
By default PSMGR-USER-ID is not set so it would come into TIRSECVX as blank.
From the generated Server Manager code, PSMGR-USER-ID is populated in B3300-EXEC-PSTEP in statement "MOVE W-UA-USER-ID TO PSMGR-USER-ID."
W-UA-USER-ID is populated in B0000-IETCNTL in statement "MOVE IET-USER-ID TO W-UA-USER-ID"
IET-USER-ID is part of TIRUSERID-PARM and it is passed to the call to user exit TIRUSRID.
Notice 2 things - The relevant paragraph is named P2000-PROF-SETUP and TIRUSRID-PARM is cleared before the user exit TIRUSRID is called.
P2000-PROF-SETUP is setting up variables to call TIRPROF, and IET-USER-ID is one of the variables used for the RPROF Key.
Following the flow in the Server Manager, it does not actually call TIRPROF even though the generated code contains the call, but Block Mode applications do call TIRPROF.
Looking at CEHBSAMP member TIRCUSRX, which is the source for the TIRUSRID exit TIRUSRIX, it can have 2 possible solutions. The default will populate IET-USER-ID with the CICS TaskID while the other (for Servers that use TCP/IP or MQ and do not have a Terminal facility) the IET-USER-ID is populated with the USERID the application is running under.
So, if populate the PSMGR-USER-ID with anything besides the userid the server is running under, it will be overridden by IET-USER-ID set in TIRCUSRX.
PSMGR-USER-ID itself is only used in TIRTERMA.