Open jplopezy opened 3 years ago
As an additional use case for this feature having a web interface to the totp interface will enable the ability to use it to provide 2fa support when used as a shared password store for non technical users (who are unable to use the api) to access shared accounts.
It would also be useful if users could reset their OTP creds with a write to totp/keys/foo generate=true
(if their policy allows it) and display the QR code, within the web UI.
But I agree: primary use case is to generate and display the TOTP tokens themselves.
👍 on this feature request that will help users to get their TOTP generated token available on the webui without using the API.
As an additional use case for this feature having a web interface to the totp interface will enable the ability to use it to provide 2fa support when used as a shared password store for non technical users (who are unable to use the api) to access shared accounts.
@Tyler-Ward , I'm just sandboxing vault and realized it is disabled to read topt codes from UI interface, however, i used to solve the problem you raise using the topt-tool-set, it works on client side and we host it in a s3 bucket, (it is not as secure as vault, since we need to keep the seed topt in a kind of excel spreedsheet, but works better exactly for those whom are not technician)
We're trying to centralize on vault, and get away from random deployments of KeePass, etc. As part of this, we're trying to rely on the Vault web UI for our less technical users who still need access to secrets like corporate-owned vendor accounts. Enabling TOTP on these accounts when available is best practice.
Having the TOTP at least readable in the UI could significantly help us with broader adoption and use of Vault.
Would sure like to see that enhancement and wondering if it's somewhere on the roadmap
We implemented a poor man's workaround by adding the vault TOTP path for a given set of credentials to the corresponding kv entry. On the same screen, the vault web UI has a minimal shell where you can take that path and run commands like vault read path/to/totp/code
without having to use the vault cli binary.
It would be ideal if it were easier for the user, but it's at least something.
@rjhornsby Thanks for the info. Sounds like a good workaround until they hopefully have a UI in place.
If not adding UI functionality, it would be great to at least be able to run a vault list totp/keys
, similar to the API call, in the vault cli UI
One option we've found, but this only works if you've enabled TOTP but haven't enforced it yet.
Create and assign a policy that grants users the capability to "update" to the path sys/mfa/method/totp (identity/mfa/method/totp for open source).
Once the user is logged in, they can click on their user menu (upper right) and click Multi-factor authentication. After entering the method_id for TOTP and clicking verify, they are presented with a QR code to scan for enrolling their TOTP smartphone app.
Also requesting for this feature. Would simplify usage greatly.
We run a cluster with a few thousand staff. I don't understand why there isn't an easy one-click /ui/ for totp engines yet. It would save having to write our own web ui wrapper around vault
for staff to access their totp codes with CORS and we wouldn't have to expose people to the vault cli either.
Is your feature request related to a problem? Please describe.
The user who was associated with a custom totp (example: external MFA) can only read the token value by command line (vault read) or by API.
Describe the solution you'd like
The user when entering the Web UI should be able to "generate a token" (vault read totp/code/testuser)
Describe alternatives you've considered
I would like to have a custom secret engine that allows taking the output of the "vault read $path" command as a variable.
Explain any additional use-cases
The totp is a quick and easy way to implement a secret. It would be interesting if it is easy to consume through the Web UI
vault read totp/code/testuser = to click and generate
Additional context
None