You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Apr 26, 2024. It is now read-only.
Repository navigation
This repository was archived by the owner on Apr 26, 2024. It is now read-only.
Disable passwords for UI Auth if unable to use password login #7559
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.
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?
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.
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.
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).
Activity
clokep commentedon May 22, 2020
CC @Talanor and @ptman.
clokep commentedon May 22, 2020
Per @erikjohnston we should be careful with this that sometimes people's passwords are removed in order to force a password reset.
ptman commentedon May 22, 2020
element-hq/element-web#3544 - "misconfiguration"
clokep commentedon Jun 4, 2020
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 commentedon Jun 4, 2020
Closing this as a client issue.
clokep commentedon Jun 4, 2020
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.ssoandm.login.token, but for UI Auth we still provide the password one. So this might be an inconsistency in Synapse.2 remaining items
ananace commentedon Sep 9, 2020
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 commentedon Nov 12, 2020
Yes, what @ananace suggests sounds about right to me. I think this should be pretty easy.
clokep commentedon Nov 16, 2020
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).