Disable passwords for UI Auth if unable to use password login

[clokep]

Synapse providers a password option for UI Auth even if the user doesn't have a password available, this causes Riot to ask for a password during UI auth instead of asking for SSO.

A workaround for this when deploying SSO is to disable passwords in the configuration.

Originally conversation near #5667 (comment)

[clokep]

CC @Talanor and @ptman.

[clokep]

Per @erikjohnston we should be careful with this that sometimes people's passwords are removed in order to force a password reset.

[ptman]

element-hq/element-web#3544 - "misconfiguration"

[clokep]

We talked a bit about this today and we think this might be a client issue, it seems the flows might be prioritized differently between login and UI Auth?

[clokep]

Closing this as a client issue.

[clokep]

I talked to the Riot Web team about this a bit and the situation is a bit more confusing then I realized, it seems that if SSO is enabled the only provided login methods from Synapse are m.login.sso and m.login.token, but for UI Auth we still provide the password one. So this might be an inconsistency in Synapse.

[ananace]

Started running into this issue as well, though with the caveat that it also needs to support bot logins with non-SSO accounts, which means just turning off password auth entirely wasn't possible anymore.
I wasn't quite sure if the UI auth was necessary for said bots, so I'm currently just rearranging the auth types to put SSO on the top, which seems to behave for both Element and bot use-cases.

--- a/synapse/handlers/auth.py
+++ b/synapse/handlers/auth.py
@@ -102,10 +102,10 @@ class AuthHandler(BaseHandler):
         # Login types and UI Auth types have a heavy overlap, but are not
         # necessarily identical. Login types have SSO (and other login types)
         # added in the rest layer, see synapse.rest.client.v1.login.LoginRestServerlet.on_GET.
-        ui_auth_types = login_types.copy()
+        ui_auth_types = []
         if self._sso_enabled:
             ui_auth_types.append(LoginType.SSO)
-        self._supported_ui_auth_types = ui_auth_types
+        self._supported_ui_auth_types = ui_auth_types + login_types
 
         # Ratelimiter for failed auth during UIA. Uses same ratelimit config
         # as per `rc_login.failed_attempts`.

My guess is that a proper solution would be to check if the user is SSO-linked, and only offer SSO in that case, with regular password auths offered otherwise.

[clokep]

My guess is that a proper solution would be to check if the user is SSO-linked, and only offer SSO in that case, with regular password auths offered otherwise.

Unfortunately you don't know which user is trying to login until after the auth mechanisms are offered. 😄

[ananace]

In our case, login is working perfectly fine, it's when an already logged-in user tries to perform a secure action (like removing a session) that things go badly.
So from my point of view, login could be kept as is, with the allowed auth types for any secure action that the logged in user then attempts being limited to only auth types that can actually be used to verify the user.

So then, logging in would offer all possible auth types, while any later authentication requirement for the logged in user would only offer the auth types that said user could possibly use.

[richvdh]

Yes, what @ananace suggests sounds about right to me. I think this should be pretty easy.

[clokep]

So then, logging in would offer all possible auth types, while any later authentication requirement for the logged in user would only offer the auth types that said user could possibly use.

This sounds reasonable, but defining what those are might be a bit tricky. I suppose we can check if the user has a password before showing that as an option. Knowing whether a user can login via SSO could be done by user_external_ids (although this wouldn't work for CAS, so we would need to do some work there).