"moderator" = false attribut in JWT not being read

Install & Config
1

Want the ability to disable moderator features via the moderator flag in the jwt. Authentication works and the user becomes moderator. Unfortunately the user becomes moderator even if “moderator” = false is set in the JWT

Are we missing something?

{
“context”: {
“user”: {
“name”: “User Name”,
“moderator”: “false”
}

},
“aud”: “jitsi”,
“iss”: “issID”,
“sub”: “meet.jitsi”,
“room”: “*”
}

2

Did you install additional prosody plugins to control moderator role using JWT?

In a default Jitsi install, the context in JWT token does not control user role so you cannot just add a field to promote or demote users to moderators. This is instead controlled by Jicofo which will promote the first user in the meeting to moderator.

You can change this behaviour by disabling that feature in Jicofo and adding custom prosody plugins to implement the behaviour you want.

If you elaborate further on what you are trying to achieve, someone might be able to point you to the right direction.

3

If you enable the externel authentication in jicofo config file, everybody becomes moderator if she has a valid token.

1 Like
4

@emrah This could be of interest for certain use cases for us. Which settings is this? Does it have a docker yaml value?

@Shawn No additional plugins enabled for this, which ones should be go for? Our end goal is:

Usergroup A - if "moderator" = true in jwt then they become moderator. Maybe in combination with the jicofo config emrah mentions

Usergroup B - if "moderator" = false in jwt then they join as guests

5

jicofo.authentication.enabled

No idea what is the Docker equivalent.

1 Like
6

In a non-docker setup, I would set both jicofo.authentication.enabled and jicofo.conference.enable-auto-owner to false so jicofo does not promote anyone to moderator.

I would then use something like this to promote users based on a value in their JWT:

That plugins looks at context.user.affiliation field to determine if a user should be moderator, but it should be relatively trivial to change that to context.user.moderator.

For docker, there is the ENABLE_AUTO_OWNER to disable Jicofo owner, but looks like jicofo.authentication.enabled is hardcoded to true if you enable auth.

I’m afraid I don’t use docker so I have no idea how best to deal with this. My guess is you either customise the config further to disable auth in Jicofo, or you leave it be and extend the plugin further to block Jicofo from promoting or actively demote users that do not have the correct flag.

1 Like
7

Thanks! Looking at mod_token_affiliation.lua it appears to be accepting both “moderator” and “teacher” == owner

Set affiliation in token. The value may be owner or member

Is ‘member’ equivalent to a guest/non-moderator?

8

Yup. An “owner” affiliation means moderator, and “member” is non-moderator.

1 Like
9

@shawn we fail to get both mod_token_affiliation.lua and mod_frozen_nick.lua to work in our environment with the Jitsi 7648 release. The modules are loading but we do not get the expected outcome.

Are they compatible with prosody 0.12.x?

10

Yes they are.

How are they not working? Do you see errors in prosody logs?

11

So this was also solved by updating the Jitsi images. However we noticed something strange

Moderator get their name set via jwt and they are allowed to change their displayname in the gui. The display name is changed for the moderator but it remains the jwt display name for guest in the meeting

  1. Moderator → “JWT name” → Change name manually → “New name”
  2. Guest → sets its own displayname → sees the “JWT name” of moderator

One solution could be to disable the ability to set displayname, but that would not be wanted behavior as we want guests to be able to set their displayname

Suggestions?

12

This is expected. At present, there is nothing stopping JWT users from updating their display name.

If you want to enforce that, see this module – prosody-plugins/frozen_nick at main · jitsi-contrib/prosody-plugins · GitHub.

It’s not perfect, since when a JWT user updates their name in the UI they will still see the name change locally, but others will still see the original name. Which is why we use it in conjunction with readOnlyName config option, but this is only viable if all users use JWT.

That really should not happen. No idea why that’s happening in your case :person_shrugging:

13

@shawn you are a champ

Sorry for being unclear, what I meant was that guest sees the JWT displayname of the moderator, not the name moderator wrote manually after logging in. Reading from above explains this behavior

Display name of the guest account works OK