Where to Put a Security Check in the z/OS CICS TCP/IP Listeners (SS and MS)
Article ID: 91818
Updated On:
Products
Gen
Gen - Workstation Toolset
Gen - Host Encyclopedia
Gen - Run Time Distributed
Issue/Introduction
What are the various types of security points available when using CA Gen’s TCP/IP Direct Connect for CICS implementation?
Environment
Release:
Component: CGHE
Component: CGHE
Resolution
There are various types of security points available when using CA Gen’s TCP/IP Direct Connect for CICS implementation. Some are part of TCPIP, some are part of CICS and then some are part of Gen. Security features are the same for both SS and MS Listener implementations.
Here is information on the application flow:
Client sends a request, the client side middleware starts a connection request (using ipaddr and port) to the server side. When the transport is TCPIP, the server side TCPIP stack receives the connection request and (1) accepts/rejects it (includes checking that the Listener accepts the connection).
1. Once the connection is accepted, the client side sends the CFB (Common Format Buffer data) which is passed to the Socket returned by the listener connection. The listener receives the CFB data and extracts certain information from it – Server transaction, Security data, Codepage etc. It passes this info to the listener user exit TIRSLEXT, where a number of things are done: translation (ascii to ebcdic), (2) security verification (if selected), If TIRSLEXT returns all ok, the listener (3) starts the server. The listener monitors to see the server has taken the socket and if so removes the socket from the list of sockets it monitors and continues.
2. If the connection is rejected, this is done at TCPIP level and a Socket errno of Connection Reset/Rejected is returned. (Note that at this point the listener does not have the CFB data to be able to format an error message so none is returned or logged in CICS)
3. If the connection is accepted but the listener cannot receive the CFB data, the listener reports the problem in the CICS Joblog and terminates the socket which in turn tells TCPIP to send a socket errno back to the client. (Note that at this point the listener does not have the CFB data to be able to format an error message so none is returned).
4. If the connection is accepted, the CFB data is received and a problem is encountered by the listener or the TIRSLEXT user exit, the listener tries to format an error message that is sent back to the client. This may be something either than security (ie Server transaction not defined in CICS) or may be that the security check failed (ie userid unknown). Assuming all is well and the server starts, it receives the CFB data and processes it. Server checks (4) application security (Decryption/TIRSECVZ exit) and if ok continues to unbundle CFB data into views to execute the Pstep/AB code. Once the request is processed, the server creates a response CFB which may be good or a failure (for instance a DB2 error). The response CFB can be (5) Encrypted before it is sent to the client. If the server starts but cannot receive the CFB, then it reports the problem in the CICS Joblog and terminates the socket which in turn tells TCPIP to send a socket errno back to the client. (Note that at this point the server does not have the CFB data to be able to format an error message so none is returned) There are exits on the client side to Decrypt the returned CFB and handle error conditions. I do not believe there are as many security validation points on the response CFB because by then the Client was already authenticated.
Here is information on the application flow:
Client sends a request, the client side middleware starts a connection request (using ipaddr and port) to the server side. When the transport is TCPIP, the server side TCPIP stack receives the connection request and (1) accepts/rejects it (includes checking that the Listener accepts the connection).
1. Once the connection is accepted, the client side sends the CFB (Common Format Buffer data) which is passed to the Socket returned by the listener connection. The listener receives the CFB data and extracts certain information from it – Server transaction, Security data, Codepage etc. It passes this info to the listener user exit TIRSLEXT, where a number of things are done: translation (ascii to ebcdic), (2) security verification (if selected), If TIRSLEXT returns all ok, the listener (3) starts the server. The listener monitors to see the server has taken the socket and if so removes the socket from the list of sockets it monitors and continues.
2. If the connection is rejected, this is done at TCPIP level and a Socket errno of Connection Reset/Rejected is returned. (Note that at this point the listener does not have the CFB data to be able to format an error message so none is returned or logged in CICS)
3. If the connection is accepted but the listener cannot receive the CFB data, the listener reports the problem in the CICS Joblog and terminates the socket which in turn tells TCPIP to send a socket errno back to the client. (Note that at this point the listener does not have the CFB data to be able to format an error message so none is returned).
4. If the connection is accepted, the CFB data is received and a problem is encountered by the listener or the TIRSLEXT user exit, the listener tries to format an error message that is sent back to the client. This may be something either than security (ie Server transaction not defined in CICS) or may be that the security check failed (ie userid unknown). Assuming all is well and the server starts, it receives the CFB data and processes it. Server checks (4) application security (Decryption/TIRSECVZ exit) and if ok continues to unbundle CFB data into views to execute the Pstep/AB code. Once the request is processed, the server creates a response CFB which may be good or a failure (for instance a DB2 error). The response CFB can be (5) Encrypted before it is sent to the client. If the server starts but cannot receive the CFB, then it reports the problem in the CICS Joblog and terminates the socket which in turn tells TCPIP to send a socket errno back to the client. (Note that at this point the server does not have the CFB data to be able to format an error message so none is returned) There are exits on the client side to Decrypt the returned CFB and handle error conditions. I do not believe there are as many security validation points on the response CFB because by then the Client was already authenticated.
Feedback
Yes
No
Powered by
