Creating user with SSO also asks registation token

[olmari]

Describe the bug
We have enabled both password login with registation token and SSO, current MAS version asks registation token when using SSO which it should not.

To Reproduce
Steps to reproduce the behavior:

1. Have MAS config as listed below
2. Try to create user (login) with SSO
3. In the last step MAS asks for registration token

Expected behavior
When using SSO, no registation token is expected.

Screenshots
Fine up to this point:

After clicking the "Create user" -button, this happens when should not:

Using MAS 1.8.0

Additional context
MAS config snippet for relevant part:

passwords:
  enabled: true
  schemes:
  - version: 1
    algorithm: bcrypt
  - version: 2
    algorithm: argon2id
  minimum_complexity: 3
matrix:
  kind: synapse
  homeserver: hacklab.fi
  secret: <redacted>
  endpoint: "http://localhost:8008"
upstream_oauth2:
  providers:
    - id: "<redacted>"
      issuer: "https://sso.hacklab.fi/realms/hacklabfi"
      human_name: "Hacklab Finland SSO"
      brand_name: "Hacklab.fi"
      token_endpoint_auth_method: client_secret_basic
      client_id: "matrix-authentication-service"
      client_secret: "<redacted>"
      scope: "openid profile email"
      claims_imports:
        localpart:
          action: ignore
          template: "{{ user.preferred_username }}"
        displayname:
          action: suggest
          template: "{{ user.name }}"
        email:
          action: suggest
          template: "{{ user.email }}"
          set_email_verification: always
account:
  registration_token_required: true
  password_registration_enabled: true

[olmari]

Apparently on some recent MAS version the behavior of registration_token_required: true was changed so that it is global setting in sense it also affects SSO logins (meant for mostly social login scope).

We do not want that and we need registration_token_required value to only affect password registrations or to be settable "per provider" instead global switch. We trust our own SSO where available and we don't want to have registration tokens required there, but we also can't use solely SSO, so we still need password registration to exist, wherein we do want to have registration tokens enabled.

I suppose this ticket is now changed more towards "feature enhancement" but for us this is more of an bug as this used to work just correctly for us :)

[sandhose]

This indeed changed in #5281

I don't particularly have time to implement this right now, but if anyone wants to take a shot at this, one would need to:

• introduce a config flag on each provider here:

  matrix-authentication-service/crates/config/src/sections/upstream_oauth2.rs

  Line 516 in fa14db3

  pub struct Provider {

• add it to the upstream provider data model here:

  matrix-authentication-service/crates/data-model/src/upstream_oauth2/provider.rs

  Line 262 in fa14db3

  pub struct UpstreamOAuthProvider {

• make sure it's getting read from/written to the database around here:

  matrix-authentication-service/crates/storage-pg/src/upstream_oauth2/provider.rs

  Line 255 in fa14db3

  impl UpstreamOAuthProviderRepository for PgUpstreamOAuthProviderRepository<'_> {

• especially when the provider gets synced from the config to the database:

  matrix-authentication-service/crates/cli/src/sync.rs

  Line 313 in fa14db3

  repo.upstream_oauth_provider()

• then distinguish the password vs. upstream oauth2 registration around here:

  matrix-authentication-service/crates/handlers/src/views/register/steps/finish.rs

  Line 124 in fa14db3

  let registration_token = if site_config.registration_token_required {

• to determine whether this is a password-based registration or an upstream OAuth-based one, you'd look at the password and upstream_oauth_authorization_session_id fields in the registration:

  matrix-authentication-service/crates/data-model/src/users.rs

  Lines 280 to 281 in fa14db3

  	pub password: Option<UserRegistrationPassword>,
  	pub upstream_oauth_authorization_session_id: Option<Ulid>,

• make also sure to introduce one a specific config flag passwords or rename the existing one, and to surface those config options in the admin API (both /site-config and /upstream-oauth-providers)