Remove unnecessary UX steps when Synapse is configured only to allow SSO login.

[lampholder]

Problem:

• The welcome page and the login page represent additional steps with no value for installations using SSO as the only login mechanism.

Potential Solution:

• By detection or client configuration, understand that the user needs to log in using SSO and bounce them via their SSO portal as soon as possible, getting them into their account as quickly as possible.

[lampholder]

Related: #12551

[t3chguy]

This is a very edge case things as users are often allowed to switch the server they connect to so automatically bouncing them would prevent that.

The welcome page can be tweaked to skip half of the steps as done by Mozilla; https://chat.mozilla.org/#/welcome
Equally the user can be directed to /#/start_sso to be flung directly into the flow.

[lampholder]

This is a very edge case things as users are often allowed to switch the server they connect to so automatically bouncing them would prevent that.

This is true for app.element.io etc. - it's not true for company-deployed instances which almost always have a very hard requirement of being as simple as possible for getting their employees into the chat.

It feels suboptimal to force people to bookmark https://chat.acme.horse/#/start_sso - I guess what I'd like to see is a config option that sees all Acme employees navigate to https://chat.acme.horse and be redirected to SSO without any flashes or glitches as Element shuffles them around between pages.

[lampholder]

Maybe this needs combining with an option that says that "this is a single-homeserver deployment of Element" (I think we already have something like this?)

[t3chguy]

On a technical level it is easy, if you're happy to define the edge cases like what happens if such a configured Element is pointed at a Synapse which later gains either multiple SSO options or also username+password

[lampholder]

I think people hosting an Element instance break into two categories:

1. People who want to make an instance of a general-purpose client available to the world (which can connect to any homeserver)
2. People who want to provide their employees/community/family with a branded/managed experience (which might choose to restrict the homeservers in order to simplify engagement)

The more I think about it, the more I think that when people deploy a vanilla Element Web instance themselves (i.e. without making any changes), by far the most common reason is to brand it, and branded instances will almost always be primarily for connecting to the brand's homeserver instance.

So I think it's okay to say that category 2 people would be expected to manage their Element experience in lockstep with their Synapse config.

[t3chguy]

That doesn't answer the question of what if Element says SSO-only but Synapse says no-SSO or SSO+Username&Password

[lampholder]

Sorry - I was trying to answer that question 😄

If the Element instance and the homeserver are mismatched, then the category 2 admin has done a bad job. If the experience were the same as navigating to https://app.element.io/#/start_sso (i.e. some json complaining at you) then I think that would be fine.

[lampholder]

I think the tension here arises from two components:

1. the question of whether the second category of Element-hosting - attaching a given Eleweb instance firmly to a given homeserver - is a supported, first-class use case
2. the question of how much the client UX should be driven by the client config and how much by server config

I had more words written here, but it was taking too long to hammer them into shape :)

[hmenke]

On my instance of Element I can't even get the #/start_sso endpoint to work. When I visit https://chat.example.com/#/start_sso I just get redirected back to https://chat.example.com/#/welcome, but when I click "Sign In" => "Sign in with single sign-on" then I am correctly redirected to my SSO provider. It would be nice to get at least #/start_sso working, but there seems to be absolutely no documentation.

[t3chguy]

start_sso is an internal route, and could change at any time, hence no documentation

[hmenke]

Thanks, I see, but why does it not work correctly?

[t3chguy]

Can't tell you based on chat.example.com - https://chat.mozilla.org/#/start_sso works just fine

[hmenke]

I found the issue. Guest access has to enabled, i.e. I need to have

"disable_guests": false

in Element's config.json and also

allow_guest_access: true

in Synapse's homeserver.yaml.

Is this a bug? Should I open a new ticket?

[t3chguy]

Travis added a thing for this: sso_immediate_redirect https://github.com/vector-im/element-web/blob/develop/docs/config.md