Zowe CLI: Token Authentication, MFA, and SSO
Command Syntax Update - July, 14 2020
The implementation for this is complete. To get started using tokens:
npm install -g @zowe/clizowe auth login apiml- Respond to the prompts:
The remainder of the article shows the command syntax as it existed in the prototype.
Background
{Core} 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…
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 login command.
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
Login via zowe apiml auth login:
Step 3: Use Commands
Now, use commands as you normally would:
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:
After 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 login again:
Token Benefits
- 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:
- username
- 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.
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!
