Closed chudel closed 4 years ago
Internal-ref: OKTA-280972
I have been thinking about this more. I suppose a more open-ended design would allow the custom factor to be either optionally presented -OR- hidden. Something like
enroll.hotp.visible = false
@chudel thanks for the detailed issue. The thought process of having a enroll option and 'contact your admin' for custom factor is that, in a case where admin sets up a policy that enforces a custom totp factor to be presented but haven't enrolled the user in it yet, the signin widget wont have anything to display and would error out ( which is a bad UX).
If you don't want the user to see the enroll screen you can always configure the enrollment/sign on policies accordingly.
Thanks. Maybe I can challenge the thought process. :) There are situations - such as you might imagine when migrating users to an Okta-based CIAM solution where you have "legacy" OTP factors that you've migrated but which are not available for new enrollments for any customers.
In this situations, customers may forever suffer a poor CX because they are given an option which is not usable. Configuring the custom factor from enrollment/sign on policies accordingly won't work because then it will break MFA for all of the legacy / migrated accounts.
I thought about this and suggested a workaround - allowing an attribute to hide the presentation of a custom factor, such as
enroll.hotp.visible = false
Thanks for taking the time to reply - I hope I've done a better job here explaining the use case and experience pitfall.
@chudel showing up the factor is api driven and it would make sense to gate at that level rather than SIW. Considering that we have the enrollment policy to gate this even at api layer I dont think we need this extra knob. Closing this as a result.
:information_source: If you have a question, please post it on the Okta Developer Forum instead. Issues in this repository are reserved for bug reports and feature requests.
I'm submitting a
Background info
Users may have a custom factor (pre-enrolled using the API) in their profile. And they will be able to use this custom factor if the factor type is permitted in the admin console. However, it does not make sense that users would be able to enroll in the custom factor since it can only be pre-enrolled using the API.
However, the Setup Option exists anyway, and when the user selects the option, they are directed to "Contact your administrator to continue enrollment."
If you remove the custom factor as an enrollment choice however, it is also no longer allowed as part of the authentication flow.
Expected behavior
Rather than this behavior, the Custom Factor should not be presented to the user as a choice at all. It's just a defeating customer experience otherwise.
What went wrong?
Contact your administrator to continue enrollment.
Steps to reproduce
Your environment