Following on from the overview of the Performance improvements in the CICS TS V5.3 open beta. This post looks in detail at the specific performance improvements provided in the CICS TS V5.3 open beta for both CICS web services and web-aware applications,
Background of CICS web support
CICS web support is a collection of CICS services that enable a CICS region to act both as an HTTP server and as an HTTP client. When CICS is an HTTP server, a web client can send an HTTP request to CICS and receive a response. The response can be a static response created by CICS from a document template or static file, or an application-generated response created by a web-aware application program, or a SOAP response from a CICS web service.
Since CICS web support was introduced, it has become one of the most popular methods of interacting with CICS applications. The CICS TS V5.3 open beta offering delivers a number of significant optimizations in this area to help reduce the costs associated with serving HTTP requests:
- Removing the need for the web attach task
- Reducing TCB switching for CICS-provided SSL support
- Support for AT-TLS aware
Removing the need for the web attach task
Prior to the CICS TS V5.3 open beta, a web attach task (CWXN transaction) is started in CICS, to process each HTTP request requiring a dynamically generated response, before passing the request to the user transaction such as CPIH for a web service or CWBA for a web application, which may then link to an AOR to invoke the required business logic application.
The optimizations provided mean that the web attach task is no longer needed for serving HTTP requests. Instead, the HTTP request is passed directly to the appropriate user transaction, thus reducing the CPU and memory overhead. The scenarios supported for optimzsation include any web or web service based application that doesn't use SSL and doesn't use an analyzer. The TCPIPSERVICE and URIMAP resource definitions for these scenarios would be as follows:
- PROTOCOL (HTTP)
- SSL (NO|ATTLSAWARE)
- ANALYZER (NO)
- USAGE (server|pipeline|atom)
If your CICS web support configuration meets the criteria, you will get the benefit automatically by upgrading to the CICS TS V5.3 open beta.
If your configuration doesn't use a URIMAP or requires an analyser, you may want to review the configuration to take advantage of the potential optimization. If your configuration uses SSL in CICS, there have been other performance enhancements in this area but the web attach task is still required. However, it is still possible to remove the web attach task for SSL web requests by migrating from CICS SSL support to AT-TLS.
Reducing TCB switching for CICS-provided SSL support
CICS SSL support runs on S8 TCBs. In previous CICS releases, S8 TCBs were incapable of performing socket I/O. This meant that there would be multiple TCB switches to and from S8 TCBs during SSL handshakes and send and receive of encrypted data. In the CICS TS V5.3 open beta, most of the switches have been eliminated by making the S8 TCBs eligible to perform socket I/O. Therefore, scenarios using CICS SSL support also see performance improvements.
Adding support for AT-TLS aware
The optimization for removing the web attach task can be applied for inbound HTTPS requests, when SSL support is provided by the Application Transparent Transport Layer Security (AT-TLS) feature of IBM z/OS Communications Server. The CICS TS V5.3 open beta has been enhanced to exploit AT-TLS AWARE capability for inbound HTTP connections (those which connect using a TCPIPSERVICE configured with PROTOCOL(HTTP)).
AT-TLS is the component of z/OS Communications Server which can be configured to encrypt/decrypt message flows for specific ports (such as a TCPIPSERVICE port). AT-TLS defines an AT-TLS POLICY to configure properties such as KEYRING, CIPHERS, SERVER CERTIFICATE, TLS PROTOCOL(S) etc.
CICS can already be used today with AT-TLS in BASIC mode. In BASIC mode CICS is unaware that the data flowing on a socket is being encrypted and decrypted by AT-TLS and will only ever see clear text (unencrypted) data, and thus a TCPIPSERVICE will have SSL(NO) defined. A major drawback of this is that a server, such as CICS, is unaware that a client certificate may exist. This means that CICS is unable to exploit certain TCPIPSERVICE security setups when running AT-TLS in BASIC mode. For example, a TCPIPSERVICE cannot be configured with AUTHENTICATE(CERTIFICATE) when it also uses SSL(NO).
There is a second mode of AT-TLS operation called AT-TLS AWARE. In this mode, a server (such as CICS) 'discovers' that AT-TLS is active for a client connection by querying the AT-TLS state. The server retrieves state such as CIPHER used on the handshake, the client certificate (if one exists) and the certificate USERID. With this mode CICS is able to exploit TCPIPSERVICE options such as AUTHENTICATE(CERTIFICATE).
CICS is introducing a new TCPIPSERVICE SSL option :-
- SSL(NO) remains the default
SSL(ATTLSAWARE) is only supported on TCPIPSERVICE definitions which also specify PROTOCOL(HTTP).
All new client connections for the SSL(ATTLSAWARE) TCPIPSERVICE will be queried to extract the following AT-TLS attributes :-
- Connection status (AT-TLS secured/not secured)
- Client Authentication type (NONE/PASSTHRU/FULL/REQUIRED/SAFCHECK)
- Client Certificate (if present)
- Client Certificate USERID
- CIPHER negotiated on handshake
Having extracted the AT-TLS state for a connection CICS imposes certain 'rules'.
- CICS expects all client connections to an SSL(ATTLSAWARE) TCPIPSERVICE to have been secured by AT-TLS.
- Error message DFHWB0365 is sent to the CICS log if a new client connection is NOT secure.
- The non-secure client connection is sent an HTTP 403 error response.
- The first non-secure connection received for an SSL(ATTLSAWARE) TCPIPSERVICE causes a DFHSO0147 warning error to be sent to console as this could signify an AT-TLS setup error.
- If the connection is secured and AT-TLS is using the ServerWithClientAuth handshake type but the AT-TLS CLIENTAUTHTYPE is set to PassThru then CICS issues message DFHSO0149 and closes both the client connection and the TCPIPSERVICE.
Assuming an SSL(ATTLSAWARE) client connection has been secured by AT-TLS using a supported AT-TLS policy CICS does the following ...
- If a client certificate has been provided CICS retrieves the certificate from TCP/IP and saves it in the certificate repository.
- Attributes of the client certificate can be retrieved later on by applications by using EXEC CICS EXTRACT CERTIFICATE.
- Any client certificate USERID is stashed away. This can be used in conjunction with AUTHENTICATE option of the TCPIPSERVICE to establish the security context for the new web task. For example AUTHENTICATE(CERTFICATE) will require a CERTIFICATE USERID to be present to allow a web request to be processed.
- The ID of the CIPHER suite used on the handshake will be saved in the socket and will eventually appear in a performance monitoring record – in existing field SOCIPHER.
The new SSL(ATTLSAWARE) option is supported for both the CICS Explorer and the CICSPlex SM WUI.
Initial performance evaluations show that using AT-TLS to secure HTTP socket connections reduces overall CPU consumption compared with using CICS-SSL support.
If you have any questions, please feel free to reach out.
Julian Horn & Jenny He
Software Engineers, CICS TS Development