Skip to content
This repository was archived by the owner on Apr 26, 2024. It is now read-only.
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

Closed

Description

@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)

Activity

  1. clokep commented on May 22, 2020

    @clokep
    MemberAuthor
  2. clokep commented on May 22, 2020

    @clokep
    MemberAuthor

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

  3. ptman commented on May 22, 2020

    @ptman
    Contributor

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

  4. added
    z-p2(Deprecated Label)
    z-bug(Deprecated Label)
    and removed
    z-p2(Deprecated Label)
    on Jun 4, 2020
  5. clokep commented on Jun 4, 2020

    @clokep
    MemberAuthor

    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?

  6. clokep commented on Jun 4, 2020

    @clokep
    MemberAuthor

    Closing this as a client issue.

  7. clokep commented on Jun 4, 2020

    @clokep
    MemberAuthor

    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.

  8. reopened this on Jun 4, 2020
  9. added
    z-p3(Deprecated Label)
    A-SSOSingle Sign-On (maybe OIDC)
    on Aug 12, 2020
  10. 2 remaining items

  11. ananace commented on Sep 9, 2020

    @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.

  12. richvdh commented on Nov 12, 2020

    @richvdh
    Member

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

  13. self-assigned this
    on Nov 16, 2020
  14. clokep commented on Nov 16, 2020

    @clokep
    MemberAuthor

    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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

A-SSOSingle Sign-On (maybe OIDC)z-bug(Deprecated Label)z-p3(Deprecated Label)

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions