CICS Transaction Gateway V5 The WebSphere ... - IBM Redbooks

Once the request had successfully executed in CICS we checked the CICS
MSGUSR log which shows useful information about the link user ID used.
Example 10-6 CICS log MSGUSR
DFHSN1400 07/10/2002 19:14:11 SCSCPJA4 Session signon for session WC1 by user
CBASRU2 is complete.
DFHSN1500 07/10/2002 19:14:11 SCSCPJA4 Session signoff for session WC1 is
complete. 1 transactions entered with 0 errors.
The link user ID is an additional level of security used for MRO and ISC requests.
For EXCI or MRO requests, the link user ID defaults to the user ID under which
the connected region runs. In our case, CBASRU2 is the user ID under which the
J2EE Server started task runs. This user ID must have access to all the same
resources as the flowed user ID (CICSRS2). To disable link security, it is possible
to make the systems equivalent by setting the USERID parameter in the EXCI
SESSIONS definition. For more details, refer to “Link security” on page 107.
Note: Our tests showed that in WebSphere V4 the client user ID is no longer
automatically propagated through to CICS when using the ECIRequest class
from a servlet, as is the case with servlets that run in the WebSphere V3.5
plugin. This is because in the WebSphere V4 J2EE Server the RACF ACEE of
the thread is not switched to the user ID of the client. This behavior is not
affected by modifying the ThreadID parameter in the EJB deployment
descriptor (see “Security settings” on page 280) since this parameter affects
only the EJB container and not the Web container, which is where servlets are
executed.
Thus if you require propagation of the user ID, we suggest you either use
J2EE applications or modify your servlet code to extract the user ID from the
HTTP basic authentication header, and copy it into the strUserid parameter in
the ECIRequest object. Sample code to do this is provided in our
CTGTesterECI application.
Results with J2EE application
To install our J2EE application, CTGTesterCCI, we first started a new
conversation using the WebSphere for z/OS Administration application and
defined a new CICS ECI resource adapter for our secure CICS region
SCSCPJA4 (for further details refer to “Installation of the CICS ECI resource
adapter” on page 252). We then deployed our J2EE application in order for it to
use this new resource adapter. This process is explained in detail in “Installing
the J2EE application” on page 261.
Chapter 10. CICS TG and WebSphere Application Server for z/OS 277