A previous article (z/Journal, April/May 2010) discussed an architectural arrangement for CICS Transaction Server (TS) 4.1 to act as a Web service provider for SOAP/XML requests. The Web service for execution in the CICS TS environment will be (relatively) short-lived and may be accessing data and logic that already exist in the CICS environment. The term “Web server” is used to mean something that processes a Web service request; it doesn’t mean a general-purpose item that can generally process many types of requests. Figure 1 shows the suggested arrangement.
There is a Web Owning Region (WOR) that acts like a traditional Terminal Owning Region (TOR). These WORs contain the TCPIPSERVICE (listener socket) that receives the Web service request, the URIMAP used to check that it’s a known request, and the PIPELINE used in the alias transaction. The alias transaction executes in another CICS region in a user security context. It unravels the XML (using the z/OS XMLSS parser), producing a set of CONTAINERs containing the XML data and a flattened, unraveled version of the contents. The alias transaction’s processing of the request occurs via a routed application program (defined in the PIPELINE) that accesses the unraveled XML request and uses this information to access existing CICS application programs.
This article uses this architectural design to discuss how attacks on CICS as a Web service provider are foiled. Critical to the defense is the use of these three CICS regions. All the normal z/OS workload balancing and CICS performance mechanisms play a part in countering attacks, as do the standard CICS transaction properties.
Foiling DoS Attacks
The region most vulnerable to attack is the one receiving the TCP/IP flows: Denial-of-Service (DoS) requests will try to force this CICS region into a stall or cause it to abend (under the impression this CICS region is the only thing involved with executing a Web service request). In the worst case, one of these WORs could fail, but because it’s isolated and doesn’t contain any existing logic or data, this failure would leave everything else running. So, a failure in a WOR wouldn’t affect existing logic or processing.
A TCPIPSERVICE (with PROTOCOL(HTTP)) Resource Definition Online (RDO) object controls reception of the Web service request into the CICS environment. This names the port on which the flow is to be received. The request is matched against a URIMAP (of type PIPELINE) to yield a PIPELINE definition and an alias transaction. This alias transaction, which starts once the entire flow is received, should be defined to be either statically or dynamically routed into other (at least two for availability) CICS regions.
The alias transaction turns the XML formatted SOAP request into a flattened structure/DSECT placed in various CONTAINERs. These CONTAINERs are passed to a user-supplied application program (named in the PIPELINE file) that actually runs the work to process the request. This application program should be statically or dynamically routed into further (again, at least two for availability) CICS regions.
This may seem like overkill with far too many CICS regions and excessive routing. Why is the alias transaction routed away from the CICS Region involved with receiving HTTP flows? Why is the user-supplied application program routed into yet another CICS region? It boils down to the usual z/OS factors: resilience, workload balancing, etc.
Benefits of z/OS
As discussed in the previous article, the default platform of choice for a Web server isn’t a mainframe. This may reflect performance issues (e.g., z/OS may be heavier in operating system overhead than, say, a Linux-based system) or financial issues. However, in a large-scale system, additional factors come into play that favor the mainframe: failover, workload distribution, operating system instance recoverability, workload balancing, and synergies that arise from having a single image. When CICS is being used as a Web service provider, all the usual System z hardware and z/OS management and control mechanisms apply to benefit availability, response, resiliency, efficiency, and to provide defenses against attacks.