Zowe API Security — securing the open mainframe

Whether you are sysprog responsible for making sure the mainframe remains secure when opening up mainframe REST APIs or an enterprise architect eager to consume secure system-oriented mainframe REST APIs to drive mainframe modernization and cross-enterprise DevOps use cases, this article is for you!

This Zowe API security discussion will be framed by first taking a brief look at the mainframe stack and its surrounding culture where security is paramount. We’ll then quickly examine the pressures that are driving mainframe modernization. REST API enablement of the z/OS mainframe platform underpins a range of modernization scenarios, and we’ll see how the Zowe API Mediation Layer (APIML) provides a z/OS API layer that is quite secure and yet easy to use to drive those modernization efforts.

The mainframe stack and its surrounding culture

The mainframe is often cited as being among the most securable computing platforms. A quick look at key pieces of the mainframe stack provides some insight into why that claim is justifiable.

Each layer of the stack contributes to delivering on this securability promise : the hardware layer enables data encryption — at rest or in-flight, your data can be protected from hackers; the virtualization layer (PR/SM) ensures that LPARs are truly isolated one from the other so information does not leak across LPAR boundaries and their respective operating system environments — in a multi-tenant world, different customers might occupy different LPARs (think Global Service Provider, e.g.); the stack’s operating system, z/OS, has been designed with system security and integrity concerns being a central consideration; and the security management layers (SAF + an external security manager — e.g., ACF2, Top Secret or RACF) provide the facilities to secure the platform through robust authentication and fine-grained authorization controls.

From top to bottom, the mainframe can be quite secure and resistant to attack. The platform itself (if defined, configured and operated correctly) provides the capabilities and facilities to be resistant to intrusion. And the mainframe culture has such security outcomes top of mind. In effect, the capabilities and facilities are present at each layer of the platform to enable a secure, hardened computing environment, and the culture puts the proper emphasis on such concerns.

Pressure to modernize

Against such a backdrop where security is of prime importance, an important mainframe modernization trend is afoot and indeed is well on its way. A few reasons for this well-established modernization trend are:

• The aging mainframe workforce needs to be replaced, and it is hard to attract young engineers/operations folks to work on “legacy” systems like the mainframe using siloed, outmoded (by modern, cloud-native standards) user experiences, tools and modes of interaction. These millennial engineers and operations folks want to use modern tool chains they can use on any platform to develop, operate and automate the mainframe
• DevOps is being applied to the mainframe to drive automation, efficiencies and waste elimination into the processes used to develop and operationalize mainframe applications, solutions and systems. Net result : better quality products brought to market on much shorter timelines
• Hybrid cloud (hybrid IT infrastructure) is expected to dominate the cloud landscape as we move into the 2020s. Hybrid cloud is a cloud model where an enterprise integrates its traditional IT resources (i.e., mainframe) with both private (on-premise) and public (off-premise) clouds. Such a Hybrid IT approach enables an enterprise to continue to leverage traditional IT assets in a controlled, secure setting while modernizing their solutions and customer user experiences in an incremental, less risky way as compared to a wholesale move to a public or private cloud implementation.

While these scenarios might seem a bit different and divergent on the surface, underneath them all lies an essential commonality — secure, mainframe REST APIs.

The Zowe API Mediation Layer (the APIML), a keystone of the Zowe open source project, provides a scalable, highly-available single access point for clients to find and consume system-oriented REST APIs in a controlled, secure, and easy-to-use way. We’ll take a brief high-level look at the APIML, and then take a closer look at how this controlled mainframe access point and Zowe REST APIs accessed through it are secured.

The APIML landscape

What comprises the APIML?

The APIML is comprised of a gateway that acts as a reverse proxy for z/OS services, together with a catalog of available REST APIs, a dynamic discovery capability, and authentication/authorization services.

Here is a diagram to illustrate these constituents and how they are related. All depicted components — with the exception of the User and API Client — reside on z/OS. The User and API Client typically interact with a z/OS resident API Gateway remotely over the network.

As illustrated, the Zowe APIML provides a single point of access for API clients to browse for REST APIs of interest via the API Catalog, or to consume REST APIs of Zowe services located behind the gateway. This single point of access is via the API Gateway Service.

Note that the “Authentication & Authorization Service” depicted above is an API Gateway Service that is broken out here for illustrative clarity.

The API Gateway Pattern — why this architectural pattern?

The Zowe APIML is an embodiment of the API Gateway Pattern. This pattern defines that access to a service is only possible via a single access point on a Gateway (the API Gateway component in our illustration above). In effect, the Zowe API Gateway provides a layer of insulation between API clients and the Zowe services they want to access. Why bother doing this? Why not just let API clients access Zowe REST services directly?

While there are a number of compelling reasons for adopting this pattern to expose Zowe REST API services on the mainframe, key security related aspects are listed here :

• One secured endpoint of the API Gateway component enables off-platform API clients / users to access any number of Zowe REST API services behind the gateway.
• The attack surface on the mainframe is thus constrained and limited in that only one port / endpoint is opened up and is secured to enable access to all Zowe REST APIs behind the gateway.
• From another perspective, adoption of this pattern completely eliminates the need for API clients / users to configure and secure point-to-point connections for each and every Zowe REST API service of interest on the mainframe
• Again, this greatly reduces the attack surface on z/OS since all of these individual REST API service ports / endpoints would not be opened for off-z/OS consumption by Zowe API clients / users

The architecture for the Zowe APIML is based on this pattern in part because of the strong security characteristics achievable when adopting such an approach.

Let’s now take a closer look at how Zowe APIs are secured within the context of the Zowe APIML.

Zowe API security

As depicted above, any off-platform User or API Client will interact with an API Gateway resident on z/OS in order to access any Zowe resources on z/OS. Any such interaction is done over TLS through a single, secured access point on the API Gateway. For simplicity’s sake, “user” will be used throughout the rest of this article to refer to either an actual human user or an API client such as the Zowe CLI.

The Foundation

Zowe API security rests on three foundational pillars : TLS/HTTPS assuring secure communications; the trusted mainframe platform authentication services (SAF + an External Security Manager); and the JSON Web Token (JWT), a secure and widely adopted approach to API security.

TLS / HTTPS

TLS (HTTPS) is used everywhere in the Zowe ecosystem: from user to API Gateway; between the Gateway and each Zowe REST API service behind the gateway; between each Zowe REST API service and the Discovery Service; between the API Catalog, the Gateway and the Discovery Service. In short, all communication links are encrypted and secured from each client northbound of the Gateway to each Zowe service southbound of the Gateway. This will thwart a hacker’s attempt to eavesdrop on a communications link in order to steal sensitive data.

Secure, authenticated access

To access any service in the Zowe ecosystem, a user first has to login. To do this, an HTTP POST is done to the secured API Gateway endpoint. Basic authentication credentials are conveyed over TLS/HTTPS from an API user to the Gateway. The credentials can be expressed as either an HTTP Basic Authorization header or as key/value pairs in a JSON document.

The following sequence diagram illustrates at a high level how this key sequence would work in the Zowe API ecosystem. Note that all REST interactions shown are over TLS (HTTPS).

Note that the sequence above depicts the scenario where z/OSMF returns a JWT token in response to an authentication request. Zowe plans to utilize the z/OSMF JWT token after it is made available by IBM (LTPA tokens will be supported for backward compatibility). In the meantime, the Zowe Authentication and Authorization Service (ZAAS) returns a JWT token to the caller.

A key take-away here is that any Zowe API user must first be authenticated by SAF and an ESM (External Security Manager) resident on z/OS before being able to access and use any Zowe resources standing behind the API Gateway, and that these authentication interactions flow over TLS (HTTPS) encrypted links.

JSON Web Tokens

As illustrated in the above high-level sequence diagram, a JSON Web Token (JWT) — pronounced “JOT” — will be returned upon a successful login to the Zowe ecosystem. A JWT is a JSON document that can be signed and optionally encrypted — Zowe API security is taking the approach where the JWT will be signed but not encrypted (in JWS rather than JWE format) as nothing sensitive will be contained in the token. From the Zowe API user perspective, a JWT is an opaque string.

A well-formed JWT consists of three Base64-URL encoded strings separated by dots :

• Header — metadata about token type and cryptographic algorithm used to secure it’s contents
• Payload — set of claims / verifiable security statements as to the identity of the user, time JWT was issued, expiration time of JWT, among others
• Signature — used to validate the token is trustworthy and hasn’t been tampered with

Example JWT

Here is an encoded JWT (fabricated online) for purely illustrative purposes.

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJ1c2VySUQiLCJpYXQiOjE1NTk4MzEzNDQsImV4cCI6MTU3MTk1MDQ5NCwiaXNzIjoiem93ZSJ9.LXrYf9FtBp23HNGt17X6pFLELQQjPQvfOUgjgrPz2ds

And here are decoded header and payload sections.

Header — algorithm used to sign the JWT and the token type

{

“typ”: “JWT”,

“alg”: “HS256”

}

Payload — asserted security claims

{

“sub”: “userID”, //user represented by JWT

“iat”: 1559831344, // time issued

“exp”: 1559917744, // expiration time

“iss”: “zowe” // issuer

}

Why JWT-based API security?

As the sequence illustrates above, a Zowe API user securely exchanges credentials over TLS (HTTPS) for a JWT token. The returned token represents the authenticated user. The token has an expiry time expressed as a claim in the payload section so that it can not be used indefinitely (this time value is configurable).

What this affords the Zowe API user is the ability to make a series of API calls through the API Gateway — where the JWT token is passed in a Bearer token HTTP header — without passing a username and password on each call. The user can continue to use a given token as long as it has not expired. When it has, the user will be required to login again per the sequence shown above.

This approach has the following advantages :

• Eliminates the need for an API user to specify username/password on each and every API request through the API Gateway mitigating the risk of credential leakage
• Provides a sessionless authentication experience — that is, the API user is not “in session” with any given service behind the APIML. This is greatly beneficial when a backend service fails and another spins up to take its place, or in the case where there are multiple horizontally scaled instances of the same service — from the API user point of view, as long as the JWT token has not expired, API requests can be routed via the API Gateway to any backend service that can handle the request.
• Enables Zowe SSO / API orchestration use cases and scenarios — an API user logs in once, and can use the returned JWT token to access multiple Zowe REST services behind the gateway. This provides a much better user experience and performance characteristics over requiring that credentials be sent and authenticated on each call.

As to disadvantages associated with such a token-based approach , the most common concern is around token hijacking and malicious replay. “Malicious replay” of a token occurs when a token is appropriated and reused — in effect, someone steals a token and reuses it as if they were you. A straight-forward way to cope with that scenario is to configure expiration times to be relatively short (think minutes and not days, weeks or longer…) Strategies we may consider as additional ways to further mitigate this concern include the following items.

Note that these extensions, other possible JWT extensions, and some aspects of basic JWT support may be included in Broadcom’s CA Brightside support offering.

• A secure way to protect JWT tokens client-side across API calls
• A facility to blacklist / revoke tokens if any misuse is detected
• A way to associate a token with a client

The strategies listed are on our security roadmap for possible future consideration and evaluation.

An additional degree of security

As we’ve seen, Zowe API security makes sure that all REST API communications in the Zowe ecosystem are encrypted, and that only API users authenticated through the mainframe’s trusted authentication mechanism (SAF + an External Security Manager) can access any Zowe service resources through the API Gateway. Moreover, credential presentation is restricted to a single login exchange and isn’t required each time an API user calls a Zowe API through the API Gateway.

These elements deliver a Zowe API security foundation that is quite secure. That said, in today’s world with lurking cyber threats and an accelerating mainframe modernization trend to make the mainframe more open and accessible, one has to ask the question is it secure enough?

Mainframe customers today expect even greater assurances that anyone accessing the mainframe is unequivocally who they claim to be. Given the state of play with respect to the perennial prospect of threats and the business driven demands to modernize and open up the mainframe, an additional degree of security is warranted.

Multi-Factor Authentication — the new table stakes

Multi-Factor Authentication (MFA) is an authentication method where a user needs to present two or more pieces of evidence (factors) to the authentication system. These factors map onto: knowledge — something a user knows; possession — something a user and only that user has; or inherence — something a user and only that user is (biometric factors).

There are various MFA approaches and implementations.

The Zowe API security implementation and user experience are currently evolving to support Radius server-based MFA implementations on the mainframe. MFA will be a natural and seamless complement to the Zowe API security foundation, and adds another degree of security to an already secure base.

The following sequence diagram illustrates what this flow will look like when Zowe API / CLI security supports this MFA approach. Note that this is intended to convey the basic flow at a high-level.

Future MFA considerations

The Zowe security roadmap — a forward looking list of security related items to evaluate and consider as we move forward — identifies some MFA variations that we might consider :

• PIV/CAC-based MFA — a card / hardware based implementation
• Conversational MFA — our initial Zowe API security implementation, as described and illustrated above, will send both factors (password + one-time pin) at once across one communications channel. We will look at conversational mode MFA where we present one factor, and provide an implementation and user experience where the second factor is requested and conveyed over a separate communication channel.

Note that the basic MFA support described herein or any of the possible MFA variations enumerated directly above may be included in Broadcom’s CA Brightside support offering.

In conclusion

The mainframe stack is highly securable, offering rigorous security mechanisms at each layer of the stack, and the folks responsible for managing and operating mainframes have the highest standards and expectations related to security. Zowe API security must also set the bar high and settle for nothing short of delivering an API infrastructure and ecosystem of services that are secure and unassailable. Our API security approach and initial MFA implementation currently underway provide a stout, secure foundation. That said, we will continue to build on this foundation by exploring ways as outlined to further strengthen our JWT defenses, and by iterating on our MFA support to enhance and strengthen it over time.

Learn more about Zowe at this site; more Zowe blogs here.