Zowe CLI: Token Authentication, MFA, and SSO

Dan Kelosky
Dec 9, 2019 · 5 min read
MFA on z/OS!

Background

A colleague of mine, Gregory MacKinnon, wrote about Zowe API security. Following on that foundation, we’ll look at how users will soon interact with Zowe security from a Zowe client: Zowe CLI.

Upcoming Plans

In the next few months, we plan to release initial support in Zowe CLI for:

Eventually, we’ll roll this support into the Zowe Explorer which is based on the Zowe CLI libraries.

Approach

To accommodate token-based authentication, MFA, and SSO, we plan to emulate something like the firebase login command. Other CLI tools have this login concept, but firebase is the best 😉.

What this means: we’ll introduce a login command for Zowe CLI to access services.

One goal of a login command is to eliminate storing of traditional user credentials (username and password) and instead rely on user “tokens” (more on those later).

The login command can prompt for a username and password, authenticate to a service, and then obtain / store a token for subsequent use.

A second goal, is to reduce the number of “profiles”.

Zowe API Mediation Layer (API ML)

Although a login command could work when signing into a single service, it doesn’t scale if you need to access many services.

For example, you may want to use z/OSMF, CA Endevor, IMS, CICS, and other Zowe conformant REST APIs through a login command approach. To do this, you’d have to login to each service, every day (assuming 12 hours expiration time on tokens) 😞!

Alternatively, you can explore using the Zowe API Mediation Layer

The API ML consists of a:

  • security service — for authentication and authorization of services
  • gateway service — for a reverse proxy and load balancing
  • discovery service — for discoverability of APIs
  • catalog UI — for a developer “catalog” of all Open API Specification (Swagger) documented APIs accessible through the API ML

Summary: it’s intended to be the single point of access for all other Zowe conformant REST APIs on z/OS.

Login User Flow

Before getting into some behind-the-scenes technical detail, let’s look at how one would use the login command.

Create a profile (the same as always although for the “apiml” type) but without user credentials, zowe profiles create apiml:

Create a profile for interactive usage — skip username and password

Login via zowe apiml auth login:

Login and request to be prompted for missing username and password

Now, use commands as you normally would:

This command works by authenticating with a token obtained after login

Token Types

Since Zowe CLI (at its core) is a client application of REST API services (like z/OSMF), there are a few types of tokens that you might come across:

We expect to primarily be handling JSON Web Tokens (JWT) — pronounced “Jot” — in Zowe. The latter two tokens are JWT examples.

Tokens are often returned the Set-Cookie HTTP header, for example:

Example token response from Zowe API ML /login endpoint

After login, the token type and token value will be stored in the users profile instead of username and password:

Example profile with token type and value

Expiration of Tokens

Ultimately, expired tokens will be detected by the Zowe CLI in order to instruct the CLI user to login again:

When a token expires, a failure occurs. A user must login again. Using an expired token will not lock out users.

Token Benefits

  1. Tokens have limited use — authentication to some service — usernames and passwords may have broader access (to many services and systems)
  2. Tokens expire “quickly”. By default, the LTPA2 tokens used here expired after 12 hours. If compromised, they can be used only for a limited duration.
  3. Single Sign On (SSO). Long term, tokens obtained through the Zowe API ML are intended to access multiple back-end services.

Can Tokens be stored in plain text?

Many services (CLI tools) store tokens in plain text files behind the scenes. npm, for example, stores a publish token in a .npmrc file on your local machine after an npm login command.

Although maintaining tokens is “safer” than plain username and password credentials, generally, it is recommended to securely store tokens (which will be base feature of the Zowe CLI soon through a tool called keytar).

MFA Use Case

Until this point, all references to “tokens” have been about those that are returned from a web service call in the Set-Cookie header. However, another type of token comes into play with Multi-Factor Authentication (MFA): RSA tokens.

Users that have MFA setup for their mainframe access might be required to provide an RSA token when logging into a system:

RSA token required for mainframe access that changes every 60 seconds

RSA tokens change value on some interval. In the example above, the RSA token value changes every 60 seconds. When logging into a system, users must provide:

  • username
  • pin (optional)
  • RSA token
“Green screen” [red font 😃] login with MFA

This login experience is acceptable in a traditional login, but in the Zowe CLI case, providing a RSA token on every command is impractical.

Interactive Zowe CLI commands (or the Zowe VS Code extension) can be nearly unusable in an MFA environment when you’re required to provide a username, password, and an RSA token that changes every 60 seconds (like in the example above).

However, after a zowe apiml auth login, the JWT continues to allow command actions (without the need for a second factor) until the JWT expires:

It’s hard to demonstrate, but commands keep working with a stored JWT, even on an MFA enabled system

How do tokens work in CI tooling?

In AWS CLI, you may use Security Token Services to obtain a token. This token can be stored securely in a CI tool’s credential management facility and expires some time between 15 minutes and 3 days.

Firebase CLI provides similar functionality through the firebase login:ci command.

Similarly, a token from the zowe apiml auth login command can be stored in a CI tool’s secure credential storage mechanism.

Summary

Zowe CLI will soon support users with MFA enabled for their z/OS environment and will eventually support an SSO experience through the Zowe API ML.

If your use case isn’t captured here or you want to influence this design, feel free to comment here or ask questions in the github.com/zowe repos!

Zowe for Users

Zowe is the modern open source interface for the mainframe and z/OS. The Zowe blog has how-to’s, tips & tricks and other helpful insights for mainframe devops. Zowe is a project within the Linux Foundation’s Open Mainframe Project (OMP). Download @ Zowe.org.

Thanks to Petr Plavjaník

Dan Kelosky

Written by

Likes programming/automation in mainframe (assembler, C/C++), distributed (Node.js), and web development (Firebase, Angular).

Zowe for Users

Zowe is the modern open source interface for the mainframe and z/OS. The Zowe blog has how-to’s, tips & tricks and other helpful insights for mainframe devops. Zowe is a project within the Linux Foundation’s Open Mainframe Project (OMP). Download @ Zowe.org.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade