User-interactive Auth doesn't support SSO flows

[richvdh]

... which means you can't delete devices on systems that use SAML (element-hq/element-web#2465)

[ara4n]

(we're working on this currently)

[richvdh]

it also means you can't add an email address to your account.

[ara4n]

not being able to delete devices is a security issue - if your device is compromised, without this you are SOL.

[richvdh]

I've drafted some notes on how I think this could be implemented at https://docs.google.com/document/d/1sA9cTKRE93TczvxuHgZ6q1A54xYtDVjmwsRu_K7vbvM.

Steps from here include:

• write up the proposal as an MSC
• make sure that UI-Auth sessions are tied to a single request (ie, the client can't change its mind about what it's asking for in the middle of a session)
• update validate_user_via_ui_auth to return m.login.sso for homeservers which use sso login
• Implement a handler for /_matrix/client/r0/auth/m.login.sso/fallback/web which shows a confirmation page, and redirects to the SAML or CAS server.
• Update the SAML/CAS return page handlers to behave differently for a UI auth flow, and:
  • update the UI Auth session
  • return the fallback completion page

Clients will need to be updated to support using the fallback mechanism. I've raised this for riot-web as element-hq/element-web#12638.

[richvdh]

fixing #6705 is going to be a prerequisite for getting this working on mozilla.org's matrix server.

[clokep]

I put this up as MSC2454: matrix-org/matrix-spec-proposals#2454. It is mostly the document from above, I tweaked a few things to clarify it (IMO).

[clokep]

make sure that UI-Auth sessions are tied to a single request (ie, the client can't change its mind about what it's asking for in the middle of a session)

To guard against this possibility I think we'll need to store some information about what the client was trying to do at the time the session information is generated. I think this can consist of:

• The action being taken.
• The item(s) that action is being taken on.

I think this can be encoded as the endpoint being queried, the HTTP method, and the item identifier(s). It might work that included these in the key to the sessions dictionary works (if any of these changes than essentially a new "session" would be formed), that could be confusing though. An alternative would be to store some of this information into the session itself and validate it. Providing the wrong information should likely result in a forbidden error.

The code around this isn't used too widely, but this is a bigger change than I initially considered.

Reasoning about this for the current case of password auth is a bit odd since it is a single stage, but @richvdh and I discussed this and came up with two things to protect against:

1. Modify an ongoing auth session
   1. Start a auth session (by doing an operation with no auth field)
   2. When providing the credentials change what is being operated on (e.g. use a different device in step 1 vs. step 2 for device deletion).
2. Auth session replay
   1. A session ID should not be able to be re-used after a successful result.

I suspect all of these changes are internal and do not require any spec modifications.

[clokep]

A couple of thoughts that I need to ponder more (and don't want to forget about):

• Is Synapse able to support multiple SSO providers at once? (If so -- what does this affect?)
• Does SAML2 being enabled imply that passwords are disabled (or is that just a common deployment scenario)?
• There's a bunch of work here designed around making fallback work for SSO. Do we need to do additional work to have non-fallback work?

[richvdh]

Is Synapse able to support multiple SSO providers at once? (If so -- what does this affect?)

currently not.

Does SAML2 being enabled imply that passwords are disabled (or is that just a common deployment scenario)?

the latter. It's possible to have a deployment where both SAML and password login are enabled. Client-side support may be patchy in this situation though.

Do we need to do additional work to have non-fallback work?

I don't think so. When I initially did the design I wasn't thinking about fallback, and was initially considering how the non-fallback case would work. But then I realised that the flows I'd come up with were identical to the fallback case and we might as well give the endpoints the same names.

Basically: I don't think we need to support non-fallback separately.

[clokep]

This is done, minus #6705, but since that's a separate issue anyway I'm going to close this.

[sideshowbarker]

This hasn’t been deployed yet, has it? Is there a timeline for when it will be deployed? Specifically, for the chat.mozilla.org instance.

[clokep]

@sideshowbarker This has not been deployed yet, no. It should be in the next release. I don't believe we have a firm timeline for getting it onto chat.mozilla.org yet, but we're working on it!

[Talanor]

Hello, is this the reason why I can't activate key backups on my deployment using SSO login through keycloak via SAML ? (used this to configure: https://edenmal.moe/post/2019/Matrix-Synapse-SAML2-Login/).
Synapse asks for my password and I get "Failed password login for user" in the logs when I input it.
Which, as far as I know is only triggered here:

synapse/synapse/handlers/auth.py

Line 844 in 5db2a59

logger.warning("Failed password login for user %s", user_id)

I went through the github issues and wonder if that is a misconfiguration on my part or if this is due to this.

[clokep]

@Talanor You probably need to disable passwords on your homeserver (see password_config.enabled). #synapse:matrix.org is the best place to ask for support though.

[ptman]

@clokep So there's no way to use SSO login for setting up key backups if password login is also enabled? Should enabling SSO automatically disable password logins, or should this be fixed so that it will work even with password logins enabled?

[clokep]

Should enabling SSO automatically disable password logins

I don't have a strong opinion on this, but my gut says no (since you might want to allow admins or someone else to login with a password instead of SSO -- this is a pretty common failure scenario).

or should this be fixed so that it will work even with password logins enabled?

I don't believe there's a bug in Synapse -- it might be a client issue that they seem to prefer passwords over SSO when offered both choices for UI Auth. Although if we don't have a password for them in Synapse, maybe we shouldn't be offering that as a choice?

Anyway, if you think there's a change to be made please file a new issue!

[ptman]

Sure, it's probably not an issue in Synapse. But Riot seems to be defaulting to password when available. We'd like to support passwords as well since many clients don't support SSO. But not all accounts have a password set in synapse.

[clokep]

@ptman I filed #7559, not 100% sure it is something we would want to fix, but wanted to track it.

[hwine]

Should enabling SSO automatically disable password logins

I don't have a strong opinion on this, but my gut says no

As an enterprise admin (not for matrix), I do want to restrict logins to SSO-only. Having SSO-only as a non default option would be fine. (In an enterprise, I want to be able to lock out the account if compromised, someone departs, etc.)

(since you might want to allow admins or someone else to login with a password instead of SSO -- this is a pretty common failure scenario).

I'm not a Matrix admin, so I don't know the context of this login. I would want a secondary login to set server/domain options, or remove defacing entries, while my SSO was offline. IMO, a "break glass" process would be sufficient.

This is a common challenge with SSO eco systems, but no standard way to resolve it has yet emerged.

[clokep]

I'm going to lock this issue since it is getting very off topic. Please file separate issues if there can be improvements to the SSO configuration of Synapse.