Compatibility with Matrix Auth

[erlend-sh]

Following from this:

Keycloak was a rough inspiration in certain places and if something is working with Keycloak, it does with rauthy too (again, so far).

I wonder if rauthy might be interested in aiming for some baseline compatibility with https://github.com/matrix-org/matrix-authentication-service

https://matrix.org/blog/2023/09/better-auth/

The Matrix Authentication Service (MAS) lists Keycloak as a supported upstream Identity Provider (IdP). Since rauthy is ‘Keycloak conformant’ to some extent, maybe the path to interop with MAS is fairly clear-cut? Would be cool to have a pure Rust stack for that whole setup!

[sebadob]

That's actually a cool idea.
I just started using Matrix and really like it so far. I am using Rauthy already for SSO into my self-deployed synapse server which I use for testing purposes.

I will for sure have a look at this and see what I might need to do to make it work. Thanks a lot!

[sebadob]

I had a first look at MAS. I don't really get (yet) what this is needed for, when it only works with Synapse, which can use OIDC directly already, but I wanted to give it a try.
My Synapse is running "prod ready" with a private CA and everything, but I got stuck in the whole process at a point now, where it cannot talk to the MAS test instance correctly. I guess this testing will require quite a bit more time and debugging, or maybe do a full new setup with everything in dev mode on localhost.

Since MAS supports OIDC upstream providers, I don't see any reason why it should not work with Rauthy. The only thing is, that Rauthy is really strict on the security settings, which means that if you have for instance enabled an S256 PKCE flow, it will enforce it, no matter what. If the client does not support it, you need to actively disable it in the Admin UI.

When I have a bit more time, I will try to debug the Synapse - MAS connection issue I currently got going on further and have a second look.

[sebadob]

Just fyi, to use Rauthy together with Synapse OIDC, you need the following config:

Synapse homeserver.yaml config:

oidc_providers:
  - idp_id: rauthy
    idp_name: "Rauthy SSO"
    issuer: "https://rauthy.example.com/auth/v1"
    client_id: "synapse"
    client_secret: "<client secret from Rauthy's Admin UI -> client -> secret>"
    scopes: ["openid", "profile", "email", "groups"]
    user_mapping_provider:
      config:
        localpart_template: "{{ user.sub }}"
        email_template: "{{ user.email }}"
        display_name_template: "{{ user.given_name }}"
    # this will only allow users assigned to the custom group 'matrix' (on the Rauthy side) to log in 
    attribute_requirements:
      - attribute: groups
        value: "matrix"
sso:
  client_whitelist:
    - "https://rauthy.example.com/auth/v1"

Inside the Rauthy Admin UI, create client with id synapse and then configure:

• enabled
• confidential
• authorization_code flow
• (optionally) force mfa
• allowed scopes: email, openid, profile, groups
• redirect uri: https://synapse.example.com/_synapse/client/oidc/callback
• access and id algorithm: EdDSA
• PKCE: S256

Then copy the secret from clients -> synapse -> secret into the homeserver.yaml -> oidc_providers.client_secret

Then go to groups -> add new group -> group name: matrix

Go to your users tab and assign those users that should be allowed to log in to Matrix via Rauthy to the matrix group: users -> my@user.com -> groups -> add matrix

[erlend-sh]

For anyone coming here to check on Matrix-compatibility, it’s worth noting that v0.19 added an important interop feature:

EVENT_MATRIX_ERROR_NO_PANIC

This new config variable solves a possible chicken and egg problem, if you use a self-hosted Matrix server and Rauthy as its OIDC provider at the same time. If both services are offline, for instance because of a server reboot, you would not be able to start them.

• The Matrix Server would panic because it cannot connect to and verify Rauthy
• Rauthy would panic because it cannot connect to Matrix

Setting this variable to true solves this issue and Rauthy would only log an error in that case instead of panicking. The panic is the preferred behavior though, because this makes 100% sure that Rauthy will actually be able to send out notification to configured endpoints.

[erlend-sh]

There’s a doc for upstream providers now: https://matrix-org.github.io/matrix-authentication-service/setup/sso.html

Probably post-v1 would be the time for a PR to add Rauthy in there.

[sebadob]

From what I can see in the docs, it is just a default OIDC provider config. Rauthy will work with this for sure. It does work with Synapse directly already for a long time for me.

edit:

The config itself kind of looks like the one from Synapse, which does exist already.

[sebadob]

If anyone looking at this issue does have a MAS environment set up, it would be nice do to a quick test with Rauthy, since I do not have the time currently. It should work right away actually.

[Freyert]

Is this a duplicate of https://github.com/sebadob/rauthy/issues/166

Specifically, this seems like a request to implement OIDC Connect Discovery?

[sebadob]

No it's not a duplicate.

This issue is most probably solved already. I just cannot confirm this at this moment, because I don't have a dev / test environment set up with a Homeserver + MAS. A proper test would involve TLS connections, which means a lot of setup.

Rauthy works with every client I tested it so far, so I don't see a reason why it would not with MAS.

[sebadob]

The help wanted label on this issue is not about implementing something for Rauthy. It is about just verifying, that everything works in a properly set up environment with MAS. The provider lookup between the services and so on expects valid TLS certificates. At my time of testing, there was no option to accept invalid certificates on the MAS side for local dev and testing and it is just a bit of work to do all of this setup.

[polarathene]

You can setup valid certs for local testing quite easily with Smallstep's step CLI.

# Local testing CA cert of your own:
step certificate create "Smallstep Root CA" ca-cert.ecdsa.pem ca-key.ecdsa.pem \
  --no-password --insecure \
  --profile root-ca \
  --not-before "2021-01-01T00:00:00+00:00" \
  --not-after "2031-01-01T00:00:00+00:00" \
  --kty EC --crv P-256

# Provision a local testing cert signed by that CA:
step certificate create "Smallstep Leaf" cert.ecdsa.pem key.ecdsa.pem \
  --no-password --insecure \
  --profile leaf \
  --ca ca-cert.ecdsa.pem \
  --ca-key ca-key.ecdsa.pem \
  --not-before "2021-01-01T00:00:00+00:00" \
  --not-after "2031-01-01T00:00:00+00:00" \
  --san "example.test" \
  --kty EC --crv P-256

You can then just provide the leaf cert/key PEM files to software that needs it, and a client can reference the ca-cert PEM file for verifying trust (browsers can add them via GUI, curl can use -ca-cert, openssl has similar etc), or you can have Smallstep add it into your systems local trust stores with step certificate install.

At least for me that greatly simplifies valid TLS certs for testing locally. I use .test TLD since it's a reserved TLD for that purpose and public DNS resolvers won't process that. Most DNS needs are met with Docker containers and it's embedded DNS where you can just set a hostname and it'll map that to the IP it assigns locally to the container. Alternatively if any DNS records are needed CoreDNS is quick and simple to setup for that too.

[sebadob]

Don't get me wrong, it's not hard to do this by any means. I even have my own CA project Nioca with simplifies this even more than smallstep and it is running anyway already.

The thing is, that all this setup just takes time, and I have a lot of other things on the TODO for Rauthy that have a way higher priority for me than validating this right now. As I said, I assume that everything is working anyway already. It would be way faster if someone with everything set up and actually using MAS would just do a quick test.
Right now, MAS is so early in its development, that it simply does not make sense to use it imho, at least when I took a look at this the last time. It only worked with Synapse, which can use Rauthy directly, and then even only with an experimental feature. Afaik, there is no other Matrix server out there, that even supports MAS.

Another problem I had, when I took a first look at this, is that I could not specify a custom root CA for MAS. Maybe that has changed by now. But that meant, that I would either modify the OS trust store just for testing, or do a "real" deployment with let's encrypt certificates.

[polarathene]

But that meant, that I would either modify the OS trust store just for testing

You can just use a containerized environment, I do that and it's easy to throwaway after. Much less hassle than a VM which I used to do.

Not really any different with LetsEncrypt, if you need an ACME server smallstep offers that too instead of the CLI commands I referenced. Nioca seems to be similar in that functionality, so I'm not sure what it is simplifying more from glancing through the README, cool project though!

The thing is, that all this setup just takes time, and I have a lot of other things on the TODO for Rauthy that have a way higher priority for me than validating this right now.

I absolutely understand this btw 👍 I maintain other projects and can relate so no worries :)

---

I don't use Matrix, I was more interested in rauthy for testing OIDC/OAuth with, and despite really wanting to I recall there was some friction. Specifically I wanted to configure/provision a user/session without any GUI interaction for a test suite to be provided an access token for it's login tests (Dovecot via XOAUTH2 / OAUTHBEARER) against an auth provider.

I recall it being problematic, got reasonably far with ORY Kratos / Hydra but the browser was necessary and I was trying to only use curl. Auth server needed to respond with the users email claim/attribute when the endpoint was provided the access token. I ended up just mocking the introspection endpoint with Caddy.

[sebadob]

... so I'm not sure what it is simplifying more ...

You can create the full chain with everything you need in just a single command. Or, if you have the server itself running already in your dev env, you can use the client to get pre configured certificates with for instance just something like nioca-client x509 once everything it set up.
The project is not yet in a state though were the documentation is really good. I just don't have enough time for everything I want to do.

Specifically I wanted to configure/provision a user/session without any GUI interaction ...

You can do this easily with Rauthy. I don't know when you tried to do this, but since Rauthy introduced the API Keys, this should be pretty straight forward. What you could do as well, is to create a Test / Dev SQLite once (with GUI or whatever) and then just re-use that DB, either by copying the file itself or use the MIGRATE_DB_FROM config var. This way you would always have access with your API Key and depending on the access rights, you can do almost anything without a GUI or browser at all.

If you want to do a full "real" code login flow, you can do this too. I actually have integrations tests that do exactly that, without any browser.

[polarathene]

You can do this easily with Rauthy. I don't know when you tried to do this, but since Rauthy introduced the API Keys, this should be pretty straight forward.

Great to hear, I'll try find time to look into that and raise an issue if I hit any blockers again 👍

As this is off-topic to the issue, I'm going to avoid responding to the rest of the comment but I appreciate the helpful response ❤️