Repository navigation
Replies: 2 comments 2 replies
|
Another option, which came up to mind is to totally shift the logic away from the various 2fa required actions (otp, webauthn, ...) to the recovery codes action itself. Any thoughts to that? |
|
@ahus1 / @keycloak/core-clients Any thoughts? I would go with my second/last option... |
|
I'm not familiar with the code, but as an admin I would like to have the option to enforce some authentication / 2FA options, with different levels of requirements (functionally auto-assigning required actions to users). Currently, as mentioned in #31934, you have to create a pretty unintuitive authentication flow to enforce having at least TOTP as an authentication factor, and it still lacks the some control, as you cannot prevent users deleting their TOTP once they have configured a WebAuthn token. If some code changes are required with the addition of recovery codes, I would like to propose also adding the option to enforce configuring other authentication factors. In this case, the authentication flow could look like this: Somewhere else in the administration interface (perhaps in the Required actions tab, as things are currently for the most part), admins could then configure the MFA options as follows: The flags above have the following meanings (when the authentication flow sets them up as alternative, as that is the only requirement level that can "transparently" fail):
The authentication would be able to continue if none of the executions in the L.E.: If this functionality is incompatible with the changes you've mentioned before, or too outside of scope, I can open a different issue to not distract too much from the conversation. |
|
Closing this issue, as there seems not to be any interest |
Uh oh!
There was an error while loading. Please reload this page.
This is a follow-up issue of issue #41836 based on the comment #41849 (comment) by @ahus1
With PR #41849 we have added the option to automatically execute the recovery codes required action after a user has configured an OTP. This was implemented directly into the code of the
UpdateTOTPrequired action class.As there might be other mfa required actions (like e.g. the WebAuthn action), which will also benefit from this option, it might be worth to generalize this code somehow. I wanted to discuss possible solutions first in a discussion, before creating an issue for it.
Like @ahus1 and me already discussed in-person, the first approach could be to provide another intermediate interface, which implements this logic as default methods. This would then look like this:
RequiredActionInterface -> NewIntermediateInterface -> ConcreteActionImplementationThis turns out, that it is basically feasible, but yields in having two (2!) intermediate interfaces. One for the
ProviderFactoryand one for theProvider. The implemented code is split across both classes, as the configuration thing is done in the factory and the runtime logic in the provider class.This wasn't obvious at first, as the
UpdateTOTPclass implements both interfaces, the factory AND the provider. But for other actions, like e.g. the already mentioned WebAuthn credential action, it's not possible to only one (combined) class and thus it would be required to have two interfaces.Does this make sense to introduce two intermediate interfaces for the automatic recovery code issuance for mfa?
@ahus1 WDYT? Is it worth to give it PR?
All reactions