OIDC migration

[girish]

I have published a new package (as unstable) that migrates matrix authentication from LDAP to OIDC.

You won't notice any change until you logout, since sessions are preserved. If you notice any issues, please let us know.

Given the large amount of people using Matrix, this will take some time to roll out.

[potemkin_ai]

Is there any way to avoid that and get locked in LDAP auth?

[girish]

What's the reason to get locked into LDAP auth ? At the platform level, we have decided to move all apps to OIDC whenever available. OIDC is more secure and does not expose raw password to apps. We can also implement much more security schemes with OIDC.

[potemkin_ai]

seems like many scripts automations, bots & official sdk no longer works with OIDC - I have to use token for that but I can no longer get token automatically; or I didn't find yet

here is a specific isolated use case that is braking now:

curl -XPOST -d '{"type": "m.login.password", "identifier": {"user": "monitoring.bot", "type": "m.id.user"}, "password": "<reducted>"}' "https://server.com/_matrix/client/r0/login"

[girish]

@potemkin_ai good point, let me research this a bit and get back.

[potemkin_ai]

Thank you

[girish]

Found this interesting site on Matrix OIDC support when researching this - https://areweoidcyet.com/

[potemkin_ai]

Thanks. The whole Matrix/Element is now in rebuild now, so I don't believe that would be handled soon...

[girish]

So, I have no idea why it's so hard to find out how to use matrix API. It's not obvious or clear to me. There's many documents in various states ...

Anyway, matrix supports multiple auth providers. So you have to enable the normal username/password login provider. There are some issues upstream like https://github.com/matrix-org/synapse/issues/11886 which maybe helps you figure auth with OIDC itself.

• First, you can enable the older username/password login like this in config/homeserver.yaml (synapse app):

enable_registration: true
password_config:
  enabled: true
  localdb_enabled: true
  pepper: "axcs6cnnY2SG"

• Then, I registered a new user with a password in the element app.

• Then, I disabled registration by setting enable_registration: false in homeserver.yaml.

• I can login as the bot user I registered

$ curl -X POST 'https://matrix.domain.com/_matrix/client/r0/login' -d '{"type":"m.login.password", "user": "bot", "password": "bwu2KZzzdA0V"}'
{"user_id":"@bot:domain.com","access_token":"syt_Ym90_iNnBLgIZkTrSyodNDfTJ_3Hwiy3","home_server":"domain.com","device_id":"FFIVMYIGDP","well_known":{"m.homeserver":{"base_url":"https://matrix.domain.com/"}}}

[girish]

Also, another idea might be to disable Cloudron SSO altogether and just use the non-sso mode which uses login/password.

[potemkin_ai]

Ideal case for me would be to leave LDAP as is or at least to offer some compatibility mode. I have centralized user directory in Cloudron and quite happy to keep things as is.

Messing with Synapse config might not be a good idea - I did once, ended up with losing the whole instance basically.

I'm aware that many apps require OIDC, it's a better approach, more secure, etc. But, it feels like it's breaking some very specific use case that is working right now.

[potemkin_ai]

I found out that my matrix instances has been already migrated to SSO, so I had to look for a more straight-forward approach and it seems to be the following:

pip install matrix-commander
matrix-commander --login sso
cat credentials.json

Will give token without a need to use a client, especially in a cases where client is not a preferred options - like for bots.

[potemkin_ai]

As a side note: Cloudron's SSO completely ignores whitelabeling settings.