Written by Elliot Jalley, Senior Principal Product Manager at Broadcom Mainframe Software and Open Mainframe Project Ambassador
The Open Mainframe Project’s Zowe API Mediation Layer recently introduced enhancements which promise to further streamline access to REST APIs on the mainframe. You can now access mainframe services using your Okta or Microsoft Entra identity, eliminating the need for an additional login. Once authenticated in this way, the API Mediation Layer uses your federated identity to enable access to services across sysplexes and security domains.
In this first of two blogs on these new capabilities, I will provide some insight on the context behind these changes and what they mean to the user experience.
Authentication and Authorization on the Mainframe
The mainframe has a long-established authentication and authorization procedure. Basic authentication into the platform is often supplemented with passphrases and multi-factor authentication in order to be compliant with enterprise security policies. When it comes to authorization, a System Authorization Facility (SAF) controls access to mainframe resources. External Security Managers (RACF, TSS and ACF2) provide additional capabilities for handling authorization requests. This ensures that an unauthorized program is unable to bypass security controls and access sensitive data.
Single Sign-On already exists for the platform
In a sense, the mainframe has always had single sign-on (SSO). Once authenticated through TSO, a user has access to all the z/OS system resources, such as transaction managers like CICS, IMS, databases like DB2, IMS, Datacom, IDMS and applications, to which they are already authorized within their organization, usually according to their role. In the mainframe world, different roles have different levels of access to resources thereby preventing a scenario where any one user can gain uncontrolled access to the system. And so, a System Programmer will have certain defined privileges that will differ from say, an Operator or a System Administrator.
However, the gradual introduction of APIs to the platform has challenged this SSO paradigm by adding other resources for which authentication is required. Enter the Zowe API Mediation Layer, which eases this pain point by managing authentication into multiple REST services. But what about SSO from your network to the mainframe? Imagine a scenario where your first sign in of the day, after opening your laptop, also gives you access to your mainframe applications and data.
SSO via Identity Providers
Today, most Fortune 500 organizations use an Identity Provider such as Okta or Microsoft Entra to provide password free access to the majority of the applications used by their employees for their daily work. But the mainframe isn’t generally included. Meaning that mainframe engineers need to additionally authenticate into the mainframe and are missing out on the benefits of SSO. This makes them a kind of second class citizen, required to re-authenticate and leaving them prone to all of the poor experience and security risks associated with manual password entry such as getting locked out of your mainframe account or unsafe password storage habits. All of which reinforces the mainframe as a silo amongst existing and new-to-the-platform engineer cohorts.
Mainframe like any other hybrid cloud platform
SSO has brought productivity and security gains to modern distributed environments. Why should the mainframe be any different? As a Mainframe user, I want to log in just once to my corporate Identity Provider like Okta or Entra and still be recognized by the Mainframe security under my Mainframe identity (to which my Mainframe access rights are bound). As a Mainframe user, I want to be able to access all the Mainframe services protected by SAF and to which I’m entitled, using only my network identity.
Furthermore, not only should I enjoy seamless authentication and authorization but I want my identity to be securely federated across my entire mainframe environment. For some mainframe engineers this means enabling authentication across Sysplexes and security domains without interrupting their workflow. They want to access the data for which they are entitled across multiple tenants, without the need to re-enter their credentials on multiple occasions.
A Zowe API Mediation Layer solution
This is where Zowe comes in. As mentioned earlier the Zowe API Mediation Layer already enables simplified and secure access to z/OS system resources via REST services. However, that core capability has been further enhanced with two new exciting features that address the needs I describe above:
> Introduced OIDC to Zowe API Mediation Layer allowing for authentication into Zowe mediated REST services via any identity provider that supports the protocol
> Introduced multi-tenancy support to make it possible to properly route and authenticate users across different sysplexes and security domains
The Zowe mission has always been to enable mainframe engineers to interact with z/OS in a similar way to how engineers experience cloud platforms today. The introduction of support for the OIDC protocol means no more need for an additional mainframe login to access Zowe-conformant REST services. An API Mediation Layer client application can verify the identity of a user by utilizing the existing authentication session from the identity provider such as Okta. The API Mediation Layer Squad recognized that this identity had to be portable across sysplexes given that Zowe can be operated in a multiple sysplex environment. Multi-tenancy support in Zowe makes it possible to properly route and authenticate users across different sysplexes.
Ashton and Jane work the case
To better illustrate these enhancements let’s consider the case of Ashton, a mainframe Operator. An event is recorded by his monitoring solution and immediately picked up by Ashton. On this occasion, he needs a subject matter expert, Jane, to investigate further and shares the event details with her as part of a newly opened case ticket. Jane clicks on the event link in the case to see the details and begins troubleshooting. She has an active Okta session so she is taken directly to the event in the monitoring solution without needing to authenticate. Jane’s troubleshooting requires her to access multiple sysplexes in their cross-sysplex environment. She has the necessary privileges and is able to seamlessly access the data without having to authenticate at each sysplex boundary. Jane quickly finds the issue and updates the case with the necessary data for Ashton to resolve the event.
The above scenario is made possible by Zowe and the API Mediation Layer. Look out for our next blog post on OIDC and multi-tenancy support, where Jakub Balhar will go deeper on how to take advantage of these capabilities in your Zowe instance.
This blog originally ran on the Zowe community Medium blog. If you enjoyed this blog checkout more Zowe blogs here. Or, ask a question and join the conversation on the Open Mainframe Project Slack Channel #Zowe-help, #Zowe-announcements or #Zowe-onboarding. If this is your first time using the Open Mainframe slack channel register here.
