[question] Centrifugo customization

[ghstahl]

I am in need to custom JWT validation and I was looking at this jwt_token project.

But what I really want is full blown centrifugo with all its configurations but with my custom jwt validation.

Any direction would be appreciated as to attack this.
We can also think about a PR into centrifugo with a generic token validation engine.

Usecase.
This is for service to service tokens.
I need to be able to publish to any channel in a namespace.
{{namespace}}:*

Ultimately, I would also like to subscribe to any channel in a namespace.

We currently have a centrifugo server running that uses the stock jwt validation, so our jwt's have the channel.

so an explicit channel in the jwt would be honored, but then what to do with wild cards.
Usually I have looked at 2 claims.

A well known service-2-service claim.
i.e. GOD MODE

And then a regex on another claims. channel_regex.

[FZambia]

Hello @ghstahl

This looks similar to what Centrifugo PRO offers: check out Channel capabilities

[ghstahl]

What am I doing wrong here?
My JWT has no mention of the connector_private namespace, but I was able to publish to it.

my jwt

docker_compose

  centrifugo:
    container_name: centrifugo-pro
    image: centrifugo/centrifugo-pro:v5
    volumes:
      - ./configs/centrifugo/config-pro.json:/centrifugo/config.json
    command: centrifugo -c config.json
    ports:
      - 8079:8000
    ulimits:
      nofile:
        soft: 65535
        hard: 65535

my centrifugo config

{
  "token_jwks_public_endpoint": "http://mock-oauth2:50053/.well-known/jwks",
  "admin_password": "password",
  "admin_secret": "secret",
  "admin": true,
  "allowed_origins": ["http://localhost:3000"],
  "allow_subscribe_for_client": true,
  "namespaces": [
    {
      "name": "connector",
      "presence": true,
      "join_leave": true,
      "history_size": 200,
      "history_ttl": "300h",
      "force_positioning": true,
      "force_recovery": true,
      "allow_history_for_subscriber": true,
      "allow_publish_for_client": true,
      "allow_subscribe_for_client": true
    },
    {
      "name": "connector_private",
      "presence": true,
      "join_leave": true,
      "history_size": 200,
      "history_ttl": "300h",
      "force_positioning": true,
      "force_recovery": true,
      "allow_history_for_subscriber": true,
      "allow_publish_for_client": true,
      "allow_subscribe_for_client": true
    }
  ]
}

[FZambia]

Hello @ghstahl, because you have all permissions in the configuration enabled for both namespaces I suppose:

"allow_history_for_subscriber": true,
"allow_publish_for_client": true,
"allow_subscribe_for_client": true

[ghstahl]

The main goal is to have a jwt that can publish and sub using a wildcard to the connector namespace.

now its permission denied for everything.

{
  "token_jwks_public_endpoint": "http://mock-oauth2:50053/.well-known/jwks",
  "admin_password": "password",
  "admin_secret": "secret",
  "admin": true,
  "allowed_origins": ["http://localhost:3000"],
  "allow_subscribe_for_client": true,
  "namespaces": [
    {
      "name": "connector",
      "presence": true,
      "join_leave": true,
      "history_size": 200,
      "history_ttl": "300h",
      "force_positioning": true,
      "force_recovery": true
    },
    {
      "name": "connector_private",
      "presence": true,
      "join_leave": true,
      "history_size": 200,
      "history_ttl": "300h",
      "force_positioning": true,
      "force_recovery": true
    }
  ]
}

centrifugo-pro    | {"level":"info","client":"d63e42e4-f740-49ca-a2b8-cf1960ef63ce","code":103,"command":"id:2 publish:{channel:\"connector_private:foobar\" data:\"{\\\"a\\\":\\\"b\\\"}\"}","error":"permission denied","reply":"id:2 error:{code:103 message:\"permission denied\"}","user":"client1","time":"2024-04-20T23:46:13Z","message":"client command error"}
centrifugo-pro    | {"level":"info","channel":"connector:foobar","client":"ac52692d-ce31-4e42-b1e3-8ed6b006b54c","user":"client1","time":"2024-04-20T23:46:21Z","message":"attempt to publish without sufficient permission"}
centrifugo-pro    | {"level":"info","client":"ac52692d-ce31-4e42-b1e3-8ed6b006b54c","code":103,"command":"id:2 publish:{channel:\"connector:foobar\" data:\"{\\\"a\\\":\\\"b\\\"}\"}","error":"permission denied","reply":"id:2 error:{code:103 message:\"permission denied\"}","user":"client1","time":"2024-04-20T23:46:21Z","message":"client command error"}

[FZambia]

Seems like a bug – Centrifugo PRO does not take capabilities from the connection token into account, will be fixed in the next version.

@ghstahl please note, we only provide Centrifugo PRO licenses to companies (corporate businesses) at this point (see actual info in docs), so make sure it makes sense for you to integrate in such way. If you represent an organization – probably contact over the email listed in the documentation of PRO version first to understand whether conditions are acceptable.

[ghstahl]

Will do.

The requirements are.

• A jwt that is locked to a given channel (probably not pro).
  I think that this is just a jwt with a channel claim. However, this would be better if the channel claim could also be an array so that I can mint a token that gives an endpoint access to multiple {{namespace}}:{{channel}}

A jwt of this type could have the following channel claim.

{
  "channel":"connector:foobar"
}

or A single JWT can subscribe to multiple explicit channels

{
  "channel": [
          "connector:foobar_1",
          "connector:foobar_2"
   ]
}

It looks to me the Pro caps claim is all I would be doing because I can fulfill all my requirements with it.
No need for the explicit channel claim above.

I think we are already looking at the pro plan but will let you know.
Btw: When do you expect the next version to be out?

[FZambia]

Yep, I think Channel Capabilities cover this all. I still worrying a lot when someone wants to publish from client side over WebSocket connection. This means that message just goes through Centrifugo while in idiomatic use case publications go through the backend first, validated, probably saved to the database – and only after that published to Centrifugo server using server API (or at least using publish proxy feature). Of course sometimes it may have sense, but usually Centrifugo is the end system which faces application frontend users - this is what it was invented for, not a general PUB/SUB system for backend-to-backend communication.

Btw: When do you expect the next version to be out?

Aiming to release till the end of this week.

[ghstahl]

Well, you made a hell of a service that can be used many ways. Having it as a backend only pub sub in our particular use case fits perfectly.

As we say in my home state of Montana. When you let the horse out of the pen you have no control over who is going to ride it!

Thank you

[FZambia]

Seems like a bug – Centrifugo PRO does not take capabilities from the connection token into account, will be fixed in the next version.

Centrifugo PRO v5.3.2 contains the fix.

[ghstahl]

Ok that works using this jwt

Can I subscribe to all channels in a namespace using that same jwt?
i.e. connector:*, or a regex

The ask is that I subscribe up front to connector:* and get the messages on anything published after that without knowing the channels up front.

i.e. connect:blah,connect:blah2,connect:blah3, where these where created for the first time after I subscribed.

[FZambia]

The ask is that I subscribe up front to connector:* and get the messages on anything published after that without knowing the channels up front.

No, with Centrifugo it's only possible to subscribe to individual concrete channels, wildcard subscription to a range of channels is not available. JWT caps can only help with permission checks when subscribing to individual channels.

I think wildcard channel subscriptions won't be added to Centrifugo in the observable future due to scalability, sharding and history/recovery concerns.

There is a clear path for this for at most once delivery (though still has some performance concerns to think about, ex. PSUBSCRIBE is slow O(N) command in Redis - https://redis.io/docs/latest/commands/psubscribe/ and it performed poor with many different channel patterns in my benchmarks, I guess it still may be done using in-mem mapping and using a single channel in Broker - has its own cons too though).

But for at least once I do not see a clear way at all - need to understand message loss somehow, handle it properly, and current Centrifugo protocol, design and used brokers do not allow implementing such thing.

[ghstahl]

Ok,
Looks like I can use the following api to get the channels currently known to the system.

Would it be in scope to have something I could subscribe to that would give me events about any channel lifecycle in a given namespace.

Drifting into webhooks type stuff here.

1. New channel created
2. Channel deleted (Is there a concept for this?) What causes a channel to go away.
3. etc.

[FZambia]

Channels are ephemeral. Channel is automatically created by Centrifugo as soon as the first client subscribes to it. Similarly, when the last subscriber leaves, channel is automatically cleaned up. History for channel if configured is kept in stream in-memory data structure for configured retention period.

Generally, there are already some related features:

1. Connection events proxy
2. Clickhouse analytics
3. Channel state events