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.
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).
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)
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…
API ML Intro
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
Step 1: Create a Profile
Create a profile (the same as always although for the “apiml” type) but without user credentials,
zowe profiles create apiml:
Step 2: Login
zowe apiml auth login:
Step 3: Use Commands
Now, use commands as you normally would:
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:
login, the token type and token value will be stored in the users profile instead of username and password:
Expiration of Tokens
Ultimately, expired tokens will be detected by the Zowe CLI in order to instruct the CLI user to
- Tokens have limited use — authentication to some service — usernames and passwords may have broader access (to many services and systems)
- 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.
- 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:
Traditional Login with MFA
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:
- pin (optional)
- RSA token
This login experience is acceptable in a traditional login, but in the Zowe CLI case, providing a RSA token on every command is impractical.
CLI Login with MFA
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:
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.
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!