Allow multiple values for SSO attributes

[villepeh]

Description:

I'm currently running Synapse that's closed for registration and I'm using SSO for authentication. Other login methods have been disabled.

Since we can't disable registration with homeserver config file, I followed the advice given here #11968 which is using attribute_requirements to restrict who can login or register using SSO.

oidc_providers:
  - idp_id: google
    idp_name: Google
    idp_brand: "google"  # optional: styling hint for clients
    issuer: "https://accounts.google.com/"
    client_id: "xxx" # TO BE FILLED
    client_secret: "xxxx" # TO BE FILLED
    scopes: ["openid", "profile", "email"]
    attribute_requirements:
     - attribute: email
       value: "my@email.tld"

This worked perfecly to restrict SSO only to my email. The issue came up when I tried adding more email addresses to "the whitelist" above

    attribute_requirements:
     - attribute: email
       value: "my@email.tld"
       value: "other@email.tld"

or

    attribute_requirements:
     - attribute: email
       value: "my@email.tld"
     - attribute: email
       value: "other@email.tld"

With this setup, Synapse ignores all values except the last line (other@email.tld) and the SSO handler no longer matches to my@email.tld. I suppose this is intended behavior, since even the config file clearly states "All of the listed attributes must match for the login to be permitted". However, this makes it really difficult to enable single sign-on and only allow logins from "friends only".

The only way I could figure out how to really get it to work was to hack /synapse/handlers/sso.py and hardcode email addresses there.

Would it be possible to allow matching several different values on required attributes? (In this case, allowing multiple email addresses.)

[DMRobertson]

Would it be possible to allow matching several different values on required attributes?

I don't think this is possible today. We'd need code changes to support this.

(In this case, allowing multiple email addresses.)

If I understand correctly, you want an explicit allowlist of users who can login/register, and you want them to be able to do so via SSO.

Might you be able to use registration tokens instead? I'm not 100% sure if this works in combination with SSO, but assuming it does, you could generate a new token for each user you want to invite to the server. See https://matrix-org.github.io/synapse/latest/usage/configuration/config_documentation.html#registration_requires_token

[DMRobertson]

I'm not 100% sure if this works in combination with SSO

Apparently it does not. :( #11067

[clokep]

I swear we had an exact issue with this title already, but I can't find it. #9356 and #12238 are somewhat related though.

[villepeh]

I swear we had an exact issue with this title already, but I can't find it. #9356 and #12238 are somewhat related though.

Yeah, I tried to search for the one to avoid posting a duplicate but couldn't find this exact issue.

If I understand correctly, you want an explicit allowlist of users who can login/register, and you want them to be able to do so via SSO.

Yes, this is correct. I initially ended up with Google SSO because I wanted to add some extra security and Synapse doesn't support 2FA yet: MSC1998. Google OIDC not only provides 2FA but also makes it super easy to login with an existing Google account. If you can get attribute_requirements to match, it also works smooth as butter :) Big thanks for that!

Current implementation of SSO assumes you want to open up registration to everyone, whereas username/password gives you a choice to disable registration and add an account for your friends using register_new_matrix_user.

As a temporary solution, I added the following stuff to handlers/sso.py at def _check_attribute_requirement:

    if 'blah@gmail.com' in values or 'bleh@gmail.com' in values:
       return True

(Yes, I know it matches to all attributes and not just email, but it works). If my Python skills were even slightly better, I could try creating a module or even a pull request for more permanent-kind-of solution.