A user can break the CAS SSO integration by logging in initially with CAS, then resetting their password through a web interface (I used Element). After doing that, they are able to log in via the Element interface with both the CAS (YunoHost) password, and the newly reset password.
I'm denoting this as "broken", because user management is no longer entirely centralized with the YunoHost administrator. For example, if an administrator goes into the YunoHost admin panel deletes the user that did the reset, that user can still log in using their secondary, reset password.
Context
Hardware: Linode VPS
YunoHost version: 4.3.6
I have access to my server: Through SSH | through the webadmin
Are you in a special context or did you perform some particular tweaking on your YunoHost instance?: no
Using, or trying to install package version/branch: 1.47.1~ynh1
Steps to reproduce
Log in via an Element client using CAS or your YunoHost user credentials
Reset your password through the interface.
Expected behavior
My guess as to what's happening when the user resets their password is that an entry in a users table is being updated with the reset password. Then, when a user logs in, the server first tries using CAS, and then if that fails it falls back to the local system. If that's the case, then the SSO-breakage could be solved by disabling the fallback logic.
Ideally auth features like password reset could be turned off in the interface via communication from the server, though I don't think that's feasible at the moment.
Describe the bug
A user can break the CAS SSO integration by logging in initially with CAS, then resetting their password through a web interface (I used Element). After doing that, they are able to log in via the Element interface with both the CAS (YunoHost) password, and the newly reset password.
I'm denoting this as "broken", because user management is no longer entirely centralized with the YunoHost administrator. For example, if an administrator goes into the YunoHost admin panel deletes the user that did the reset, that user can still log in using their secondary, reset password.
Context
Steps to reproduce
Expected behavior
My guess as to what's happening when the user resets their password is that an entry in a
users
table is being updated with the reset password. Then, when a user logs in, the server first tries using CAS, and then if that fails it falls back to the local system. If that's the case, then the SSO-breakage could be solved by disabling the fallback logic.Ideally auth features like password reset could be turned off in the interface via communication from the server, though I don't think that's feasible at the moment.
Logs
N/A