Security and performance across tiers

When a request crosses from a phone through cloud services into CICS, the mainframe still needs to know who the real user is, the data must be protected on every hop, and each call costs time and processor. This lesson covers TLS, identity propagation, and how to design for latency and MIPS cost.

The request path

A typical hybrid request path

Mobile appUser signs in

API gatewayOAuth token checked

z/OS ConnectMaps JSON to program

CICS / IMS / DB2Runs under a RACF identity

Every arrow is a trust boundary and a network hop. Security architecture decides how each hop is protected and how identity is carried. Performance architecture decides how many hops there are and what each costs.

Protecting data in transit

All hops should use TLS. On z/OS, TLS can be done by the application or server itself, or transparently by AT-TLS, where policy in the TCP/IP stack encrypts connections for programs that do not handle TLS. Mutual TLS, where both sides present certificates, is common between gateways and z/OS servers. Certificates and keys are kept in a key ring managed by RACF or an equivalent security product (ACF2 and Top Secret have their own mechanisms).

Identity propagation

A frequent weak design runs every request from a channel under one shared functional userid. The mainframe then cannot tell which person made a change, and access control by user is lost. Identity propagation carries the real user's identity through the tiers so z/OS can act on it.

Approach	How it works	Trade-off
Shared service ID	All requests run under one RACF userid	Simple, but weak audit and coarse access control
Mapped user ID	Token identity (for example from a JWT) mapped to a RACF userid	Per-user access control; needs user provisioning on z/OS
Distributed identity mapping	RACF maps a distributed user name and registry to a userid, and the original name can be recorded for audit	Keeps the real identity in audit; depends on product and configuration support

z/OS Connect and CICS can validate tokens and map identities, and RACF supports distributed identity filters for mapping external names. What is possible depends on product versions and site configuration, so confirm with security engineers. Whatever the approach, apply least privilege: a gateway's service ID should be able to call only the APIs it fronts.

Latency

Mainframe transactions often run in a few milliseconds. In a hybrid call, most of the elapsed time is usually elsewhere: network round trips between sites or clouds, TLS handshakes, gateway processing, and JSON transformation. Practical rules:

Keep connections persistent so TLS handshakes are not repeated for every call.
Place gateways and calling services close to the mainframe network where possible.
Make APIs coarse-grained: one call that returns what a screen needs, not ten small calls.
Set timeouts at each tier so the outer timeout is longer than the inner ones; otherwise callers retry while the mainframe is still working.

Processor cost

Integration work consumes mainframe capacity, and software charges on many sites are linked to that consumption. JSON conversion, TLS encryption and the API layer all add to the cost of each transaction. Some of this work is eligible to run on zIIP processors, which are typically not counted toward most IBM software charges; how much is eligible depends on the product, version and configuration. Measure with SMF and RMF data before and after.

Cost per call worked example (illustrative numbers)

Calls per day                 2,000,000
General CP time per call      0.4 ms
Daily general CP time         800 seconds
After caching 60% of reads    800,000 calls reach z/OS
Daily general CP time         320 seconds

Troubleshooting across tiers

When a hybrid call fails, carry a correlation ID from the first tier through to the mainframe, logging it at each hop. Without it, matching a cloud error to a CICS transaction or SMF record is guesswork.