catalyst / moodle-local_login

Login splash page to help point users at correct login process.
Other
5 stars 4 forks source link

Email based filtering of login methods aka 2 step login #26

Open brendanheywood opened 5 months ago

brendanheywood commented 5 months ago

This is broadly the same as this tracker but done here as a stop gap as it's not clear if its desirable to land in core

https://tracker.moodle.org/browse/MDL-57835

The idea is that:

1) in the config it detects there are N idp's 2) it presents an optional text area for each login method 3) each text area accepts a partial email or domain on each line 4) on the login page, if any idp has anything optional config then an email box is shown at the top 5) if an idp has config then it is not shown by default 6) as the user finishes typing their email address a webservice checks and if it matches any idp's then they are shown 7) if only one matches then it instantly redirects 8) if all login methods have config then only the email input is shown 9) there would be some fallback method so if no idp matches, then for example manual logins are shown 10) in the case of any auth plugin which uses a password instead of an idp then a second password field is shown, including the login token and they continue to login normally 11) when doing the web service check it also matches usernames, looks up the email, and applies the same logic as if the email was entered (maybe behind a setting?)

danmarsden commented 5 months ago

Personally I dislike the UX requiring an email address to be entered before allowing the user to select an IDP -but no objections to having this within the plugin - I suspect in some cases this will mean the users have to enter it twice - once on the intial form, and then again on the idp login itself if they are not already logged in.

brendanheywood commented 5 months ago

It's not for everyone, but for many large institutions its a privacy thing. They must not show user A from domain A that domain B is also a client in the same system. It can still be enumerated but it's much better than showing up front.

In an ideal world we could figure out how to pass the email through into the idp's login form but that's gonna be different for each idp and out of scope here.

With the poor UX of double email entry, this plugin could also implement a simple IdP discovery mechanism where if you have previously logged in via one idp then stash a cookie and don't prompt the second time.

danmarsden commented 5 months ago

ah - privacy driver makes a bit more sense - I've seen client initiated requests where a special link is stored within a corporate portal that initiates the idp login and redirects back to the LMS but that requires the user to always use the portal link rather than hitting the lms directly.