search

okta / okta-signin-widget

HTML/CSS/JS widget that provides out-of-the-box authentication UX for your organization's apps
Other
376 stars 319 forks source link

CustomFactor Enrollment Option Shouldn't Display on Factors Enrollment Screen #1064

Closed chudel closed 4 years ago

chudel commented 4 years ago

: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

  1. Setup a custom enrollment factor.
  2. Login as a user with no MFA tokens. The system will present a list of available tokens for enrollment.
  3. Select the "Setup" button for the custom factor.
  4. Observe that you are simply told: "Contact your administrator to continue enrollment." and go Back to the factor list.

Your environment

swiftone commented 4 years ago

Internal-ref: OKTA-280972

chudel commented 4 years ago

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

magizh-okta commented 4 years ago

@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.

chudel commented 4 years ago

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.

magizh-okta commented 4 years ago

@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.