• June 25, 2022

Using MFA with Zowe: How it Works

This article originally appeared on Medium.com

A frequent Open Mainframe Project’s Zowe question is “Can it use MFA?” and more specifically “Can it work with MY MFA setup?”. It’s no surprise; every year another website I use makes the switch to a multi-factor-based login. By now it seems like more well-known companies use it than not. To answer the questions, yes, Zowe can use MFA, and it probably can use your setup, but as Greg mentioned in a previous article there are various MFA approaches and implementations. As a follow-on to Dan’s previous article on how the Zowe CLI could soon work with MFA let’s explore how Zowe’s UI and API components work with MFA, and how your own software may as well.

Why everyone wants MFA

The short story is MFA exists because people want to prevent unauthorized access and passwords have proven insecure by themselves. Whether by social engineering, theft, spying, or brute-force guesswork, hackers will figure out the passwords to any sufficiently valuable system.

Enter MFA: By requiring two or more pieces of proof (“Factors”) that you are you, rather than just one such as a password, the likelihood that a hacker has all of that information is much lower, thereby greatly increasing security. The key to making this truly secure is to make sure that the factors are categorically unrelated. Consider the ways you can prove who you are to someone. You can show them something only you know (a password), something only you have (a card), or something from who you are (a fingerprint). Having two passwords can be considered MFA, but it isn’t very secure compared to one password and one fingerprint, since unlike a password you cannot guess a fingerprint.

So, when you think about it that way, have you noticed any MFA in your daily life? Personally, the kind I’m seeing more and more of is email or phone-based factors, where after entering my password a site will email or text me a code that will expire in a few minutes. That sort of MFA is convenient and has worked really well, since nobody’s stolen both my password and my phone yet! 😉

Handling MFA

So, if Zowe supports MFA, how does it collect the credentials? Did we add fingerprint scanning code or set up a texting service? No, not yet anyway 😁. Thus far, we leave that part of the problem to dedicated security products via what is termed “out-of-band MFA” as opposed to “in-band MFA”. Let’s examine the difference, with images based off Greg’s article on Zowe’s authentication plans.

The to-be state for SSO and MFA, according to Greg’s article

In-band MFA

In-band is when the program you are trying to access is responsible for prompting you for all of the MFA credentials, meaning that if a fingerprint was required the program would handle fingerprint scanning. Fingerprints aren’t always required, but the in-band program would need to know which type of credentials are valid for providing. These programs can provide a seamless user experience but at the cost of software complexity, and also puts that software on the hook for security upgrades if the MFA functionality needed enhancement. Another concern is that without single sign-on, in-band could make each program used responsible for interpreting factors, rather than unifying the security process.

Generic in-band MFA concept, z/OS or not

Out-of-band MFA

Out-of-band visibly shifts the responsibility of collecting credentials from the user to a different program than the one you are trying to log into. For simplicity, let’s say you’re trying to log into Zowe, and the other program is an IBM website. While in-band MFA would have Zowe consult an MFA product behind the scenes after collecting the multiple credentials, the out-of-band case has the user interacting with that IBM website prior to attempting to log into Zowe. This would mean that the user cannot just go to Zowe and log in, but first must use that website to gather MFA credentials, and then get a code from the website to paste into a Zowe password prompt. In this model, Zowe can “play dumb” by accepting a token its password field that serves as proof that MFA occurred, rather than being involved in the MFA process. This allows for password fields to play double-duty, working for both MFA and non-MFA cases, and some existing programs can even support this without any code changes. The caveat: if the login establishes a session that will eventually expire, the software the user is interacting with must handle the expiration gracefully.

Out-of-band: Note the addition of an MFA UI in between the client and server

Compatibility with Time-based Factors

Time-based factors are popular because they limit exposure, as credentials are only valid for login a short time after generation. However, some software may rely on a form of password storage and replay. Such software assumes the password you had before is still valid, and when true allows the software to work when there is no notion of a session, or the session expires and needs renewal with minimum user intervention. So, while time-based factors make it harder to guess or steal passwords due to their short period of validity, the trade-off for the extra security is that end-user software such as Zowe must both have a way to keep you logged in for more than a few seconds and to know when it’s appropriate to prompt the user for updated credentials. This is the one caveat of the convenience of out-of-band MFA: Programs involved in MFA must have a way to keep a user authenticated even if initial login credentials expire.

Luckily, Zowe has a solution: authentication tokens. In Zowe, a successful login trades your credentials for a token that is proof of your login. Such tokens usually have an expiration time of their own, and this serves the purpose of separating two security concerns: That your login credentials should be valid only briefly so that they cannot be stolen, and that you should periodically prove that you are still you in order to know that your device has not been stolen by someone.

MFA on z/OS through Passphrases

SAF is the standard API for z/OS authentication, and this simplifies MFA support. SAF relies on an ESM to validate credentials, that ESM can in turn work with MFA software for the validation.

Why is this important? Because it means that MFA can be accomplished using the same authentication APIs used without MFA. In particular, SAF allows for authentication via username and passphrase among other means, and those passphrases can be up to 100 characters. What is contained in the passphrase field is up to the ESM and MFA software to interpret, so it could have been a hand-written password but in our case, it can instead be a token proving the MFA process occurred!

So, from the user’s perspective when using Out-of-band MFA or no MFA at all the login screen to their software is identical. In one case, the passphrase field contained a passphrase the user typed, and in the MFA case the content was an MFA token. There’s no difference to the UI, because the interpretation happens further down the chain. That’s really powerful, because it limits the responsibility of most software to know whether or not MFA is taking place, so that in many cases MFA comes “for free”!

What about Zowe?

As referenced in the beginning, Dan wrote about plans to support MFA in the Zowe CLI soon. Essentially, soon-to-be-completed efforts on Single Sign On (SSO) will unify how the components of Zowe deal with MFA. Until then, I’m happy to report that in testing, we’ve validated that the login prompts and APIs of the API Mediation Layer, its Catalog, the USS/MVS/JES Explorers, ZSS, the App Server and the Desktop all support the Out-of-band passphrase method of MFA, since all of their login prompts are using username & passphrase fields which invoke SAF. In addition, some MFA products allow you to type a combination of factors directly into any passphrase field, providing a degree of In-band MFA. You can see an example of this within Greg’s article. Currently, our In-band solution is limited to those things that you can type, as the software cannot read fingerprints, cards, or take blood samples… yet 😉. But, I hope users will find either In-band or Out-of-band approach good, and we welcome your feedback!

The big picture on authentication for Zowe. In red: The backend solution that makes MFA work for Zowe. In green: The session management that we’ll use to accomplish SSO

Which MFA Products?

As an open source project, Zowe aims to remain vendor neutral and support as many MFA implementations as possible to help your organization remain secure while using Zowe. However, we have not yet been able to test or accommodate all MFA products under the sun. Therefore, you should first look to our documentation to see what products have been validated, and if you don’t see the one you use there, please reach out to us via slack, forum, mailing list and more that you can find at zowe.org, and we’ll see what we can do to gain support for other products too!

I hope this article helped you to understand MFA, and how it works in Zowe. To learn about other Zowe topics, see more Zowe blogs here.

Zowe is owned and managed by the Open Mainframe Project that is a Linux Foundation project.


Leave a Comment

Your email address will not be published.