Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FEATURE REQUEST: Make "needs bootstrap flow" explicit. #130

Open
jvantuyl opened this issue Sep 24, 2021 · 2 comments
Open

FEATURE REQUEST: Make "needs bootstrap flow" explicit. #130

jvantuyl opened this issue Sep 24, 2021 · 2 comments

Comments

@jvantuyl
Copy link

I've run into a few use-cases where it would be handy to be able to trigger the bootstrap workflow without deleting the current keys or where it would be handy to inhibit the bootstrap workflow but still have the user configured with no keys.

Would it be possible to do something like?

  • Add a boolean to the user DB indicating whether bootstrap was needed.
  • Default that to true or false based on some config value.
  • Have a button in the UI to flip the status.
  • Trigger the bootstrap flow based on that flag instead of "no keys".
@cviecco
Copy link
Contributor

cviecco commented Sep 24, 2021

Can you elaborate on your use case? The design goal of the bootstrap case was to allow self-enrollment of MFA for first time users.
We want this process to be noisy so that is non trivial to bypass the MFA after it has being enabled. And easiest way for a user to notice that something is wrong is if they cannot login.

@jvantuyl
Copy link
Author

jvantuyl commented Jul 2, 2022

Well, right now you need sort of a perfect storm to get the MFA sign-up logic to kick in. Sometimes they have an old key registered. Sometimes you just want to add another one temporarily while they're offsite or something. Sometimes you don't know what they're doing and you don't want to have to munge things to get everything right just to get them signed up for a new MFA key.

If the user does one thing wrong, you need to reset it on the server and hope that the user isn't wildly clicking buttons on their end. And you're guaranteed to lose any other potentially working keys that might have been useful later on in the process. This basically makes getting a confused user access with a fresh key a slightly destructive and fairly disruptive act. It would be much easier to tell Keymaster (through a single toggle) that we're expecting to do this and then let it run with that.

This also allows decoupling the creating of the user from the actual sign-up of the MFA. This is very useful for pre-provisioning users and for working with them over asynchronous means--especially if they're remote. In particular, it's nice to be able to enumerate the users and get people who haven't logged in yet. It makes using Keymaster the "system of record" for users much more functional.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants