Jitsi should have option to lock conferences only to room participants

[ara4n]

Filing here because we don't have anywhere better - but a recurring theme since publishing https://matrix.org/blog/2020/04/06/running-your-own-secure-communication-service-with-matrix-and-jitsi has been (quite reasonably): "hang on, doesn't this mean anyone on the internet can use your jitsi and consume your bandwidth"?

Suggestions welcome for how we can configure things to lock down so that only people in an associated Matrix room can join and start confs.

[dbkr]

Thought about this briefly and I think the simplest way would be if jitsi had a mode where you needed to be authed to create rooms but anyone could join existing rooms (or possibly set room passwords and share them in the jitsi state event).

This would also need us to provide the creds in the increasingly many places we allow the custom jitsi domain to be specified from.

[t3chguy]

This would also need us to provide the creds in the increasingly many places we allow the custom jitsi domain to be specified from.

how would this work with custom Jitsi's anyhow without them modifying them to also have this mode

[dbkr]

Yeah, it would need this adding to jitsi if this isn't something it can do already.

[awesome-michael]

I think the Jitsi instance could be configured with secure domain, such that only registered users can create conferences. These users can be authenticated via JWT tokens that can be passed to the Jitsi instance via the API (https://github.com/jitsi/jitsi-meet/blob/master/doc/api.md). You would have to configure the token though (maybe in the config.json?). Would that solve the issue?

[RezaBabapour]

Is there a way only matrix users cat use jitsi? and only through matrix? As @awesome-michael said there is a authentication method via JWT in jitsi api. but can't find any way to config riot-web for using this method. problem: At this point my conferences are secured but any one who knows my jitsi url can use jitsi.

[cnvandijk]

Jitsi already supports authentication such that only registered users can use it. Currently it supports internal, LDAP and JWT authentication. The point of this issue is to pass authentication from Riot to Jitsi; at the moment the Matrix user accounts and the Jitsi user accounts are separate things.

[nE0sIghT]

For what I see we need to implement JWT token authentication [1].

1. There should be JWT token generator service working in infrastructure.
2. Riot configuration can be extended with URL of JWT token generator service and with boolean for using Jitsi JWT token authentication.
3. Jitsi should be configured for JWT token authentication against generator service [2].
4. Before opening Jitsi conference Riot will connect to JWT generator service and obtain JWT token. Then Riot will pass JWT token to Jitsi.

Question: does Riot have persistent access to user's Matrix password? If so, login/password authentication could be done against JWT generator service

[1] https://github.com/jitsi/jitsi-meet/blob/master/doc/api.md [2] https://github.com/jitsi/lib-jitsi-meet/blob/master/doc/tokens.md

[t3chguy]

Question: does Riot have persistent access to user's Matrix password? If so, login/password authentication could be done against JWT generator service

Nope, it exchanges it for a Matrix Access Token during login and never stores it.

[turt2live]

does Riot have persistent access to user's Matrix password?

No, and highly unlikely to do so.

[aleixq]

I think that this suggestion can be merged with what is exposed in PR vector-im/element-web#13986 .

[aleixq]

After the simple approach of adding jwt in an input form is closed, I end up with a different approach... let me tell... It's a fact that jitsi needs a configuration to use it with matrix, so on if someone is thinking about using a self-hosted it needs some adjustments. Setting it with existing prosody modules is a little bit harder and the way jitsi offers to authenticate users in a flexible way is using JWT.

So I end up creating an authenticating module that tries to authenticate with a jwt token as jitsi suggests and if it fails it will fallback to matrix authenticating via client-api.

It is done in the module mod_auth_token_matrix_fallback in https://gitlab.com/communia/matrix_prosody_modules . The way it is doing is explained in depth in README.md, the teaser is:

Element IM needs to provide a special JWT where:

{
  "alg": "HS256",
  "typ": "JWT"
}
{
   iss: issuer,
   sub: homeserverUrl,
   matrix_id: userId,
   matrix_room: roomId,
   matrix_token: accessToken,
   matrix_url: homeserverUrl
}
HMACSHA256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  'riot-not-secret'
)

With these properties mod_auth_token_matrix_fallback module will first try to authenticate with standard mod_auth_token token(the one jitsi suggests in https://github.com/jitsi/lib-jitsi-meet/blob/master/doc/tokens.md ) and if it fails to authenticate then will try to login to matrix_url with the credentials matrix_id(userId):matrix_token(accessToken) (without saving any user or token anywhere), and will carry on with some matrix checks:

• Check if matrix_url is in matrix_accepted_servers list in /etc/prosody/conf.avail/yourjitsi.org.cfg.lua.
• Check if matrix_id(userId) is in matrix_room.
• Check if matrix_room(roomId) has a jitsi widget with the current jitsi room id.
• Check if matrix_id(userId) can kick other users in matrix_room.

If all is ok then the user in matrix will be allowed to create the jitsi room and will be an administrator of this room. Take care that (only for the matrix fallback case) secret must be the already configured jitsi token in /etc/prosody/conf.avail/yourjitsi.org.cfg.lua or the matrix_secret configured in /etc/prosody/conf.avail/yourjitsi.org.cfg.lua, for the matrix_secret it is hardcoded in Element IM side as riot-not-secret(hardcoded because the browser webcrypto api cannot accept a blank secret to sign a token, while other api/libs do).

Others joined with the same method will also be jitsi room admins. Others joined with suggested jitsi tokens as in https://github.com/jitsi/lib-jitsi-meet/blob/master/doc/tokens.md will act as admins also. Others joined without any of the previous methods will be denied, unless the room exists previously, then they can access as guests.

The critical thing is adding the accesstoken to be able to check things in matrix as the interested user... It's not stored but I don't know if it's safe enough.

Patches of matrix-react-sdk and riot-web are in https://gitlab.com/communia/matrix_prosody_modules/-/tree/master/element%20patches .

If you think is ok, I can provide it as PR.

[jaywink]

Element Web since 1.7.6 now has support for a custom auth module for Prosody that uses an OpenID token given by a Matrix server to verify a user and a separate verification service to verify room memberships (currently Synapse only). This is not really a full solution to this issue but posting here for interested parties, please see https://github.com/matrix-org/prosody-mod-auth-matrix-user-verification for the flow.