Skip to content
This repository has been archived by the owner on Apr 26, 2024. It is now read-only.

Return m.change_password enabled:false if local database not used for authentication #9456

Closed
xyzroller opened this issue Feb 20, 2021 · 4 comments · Fixed by #9588
Closed
Labels
S-Minor Blocks non-critical functionality, workarounds exist. T-Defect Bugs, crashes, hangs, security vulnerabilities, or other reported issues.

Comments

@xyzroller
Copy link

Description:

I have moved my users to SSO via OIDC. The user accounts previously existed on synapse and I do not want the users to be confused by any remnants of the native synapse account. I have therefore disabled local passwords in the password_config section of synapse's homeserver.yaml - enabled: false in addition to configuring the oidc_provider.

However, when a user logs in to synapse from element-web or element-desktop, they are still shown UI elements for changing their (local synapse) password. Trying to do this leads to an error.

From element-hq/element-web#16499, I learned that the clients are responding to the capabilities passed by synapse - in this case because they receive enabled: true for the parameter m.change_password in their capabilities query.

From the Synapse Admins room on matrix, I learned that enabled:true is sent whenever there is a password hash present in the database (which in my case there is, as the users previously authenticated against the local DB) - see here

The feature request is that enabled:false is sent for the capability m.change_password whenever the config option password_config.enabled is set to false in homeserver.yaml.

@clokep
Copy link
Member

clokep commented Feb 22, 2021

This seems to be confusing a few different items:

  • The m.change_password bit is unrelated to logging in (at least clients shouldn't be using that).
  • The logic for choosing which login types are supported is near here -- if you have password_config.enabled set to False than password will not be accepted. (Note that there's also a password_config.localdb_enabled flag.)
  • UIFeature.passwordReset doesn't seem to work element-hq/element-web#16499 seems to talk about password reset, not logging in. It does seem that there's a bug there though that we should swap that capability based on the config in someway.

So, I guess I'm unsure if you're asking about password resets or logins or something else -- could you provide a bit more description of what is happening?

@clokep clokep added the X-Needs-Info This issue is blocked awaiting information from the reporter label Feb 22, 2021
@xyzroller
Copy link
Author

xyzroller commented Feb 23, 2021

Sorry for the confusion. I'll try to explain a bit better.

My overall aim is that my users, who previously used credentials stored in the Synapse database but now all sign on via SSO, no longer see any UI elements that have anything to do with the password that is (still) present in the Synapse database. The credentials (still) in the Synapse database are no longer used since I set password_config.enabled to false in homeserver.yaml (to "force" the users to log in via SSO).

In Element-web config., there are a couple of configuration settings in Element's config.json which I have used to switch off related UI elements:

  • "UIFeature.passwordReset": false - which suppresses the "Forgot Password" link on the sign-in page and accompanying dialogs
  • "UIFeature.deactivate": false - which suppresses the "Deactivate Account" button in Element-web settings after logging in

These work as expected. All good.

An additional UI feature in Element-web / desktop which I would like to eliminate is the "Set a new account password" area in the settings, after logging in, found under All Settings -> General. Since password_config.enabled is set to false in homeserver.yaml this fails, as expected, and an error is displayed. However, I think that this UI element should not be shown at all when password_config.enabled is set to false in homeserver.yaml, as it is bound to generate an error.

There is no "UIFeatures" setting in Element to control this, apparently. Instead, this is shown by the client whenever the client receives m.change_password.enabled set to true via the Capabilities API. m.change_password.enabled is set to true via the Capabilities API whenever a password hash is present in Synapse database - independently of the setting for password_config.enabled in homeserver.yaml. For my case, the "old" passwords used pre-SSO are still present, but no longer used.

If I manually remove the old password hashes from the database, then I can I achieve what I want - the "Set a new account password" area in the Element-web settings is gone for a user with no password hash. However, given that there is a password_config.enabled setting in homeserver.yaml, I don't think that admins should need to manually change the database to achieve this.

The feature request is that m.change_password.enabled should be set to false in the Capabilities API when password_config.enabled is set to false in homeserver.yaml. Otherwise, as in my situation, the UI feature to "Set a new account password" in the client is present but will always fail if there is a password hash in the database.

Hope that's more understandable.

@clokep
Copy link
Member

clokep commented Feb 24, 2021

The feature request is that m.change_password.enabled should be set to false in the Capabilities API when password_config.enabled is set to false in homeserver.yaml. Otherwise, as in my situation, the UI feature to "Set a new account password" in the client is present but will always fail if there is a password hash in the database.

This sounds reasonable, yes. 👍

@clokep clokep added S-Minor Blocks non-critical functionality, workarounds exist. T-Defect Bugs, crashes, hangs, security vulnerabilities, or other reported issues. and removed X-Needs-Info This issue is blocked awaiting information from the reporter labels Feb 24, 2021
@xyzroller
Copy link
Author

Excellent! Thank you for fixing this.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
S-Minor Blocks non-critical functionality, workarounds exist. T-Defect Bugs, crashes, hangs, security vulnerabilities, or other reported issues.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants