Moderator rights for organizers only?

We run our own Jitsi server as a school. Conference creators need to register as organizers (LDAP).
All, teachers and students, have access data for the system. Unfortunately, if e.g. a student or colleague was already logged in to the system as an organizer before, they also get moderator rights.

However, for various reasons, it would be important to us that only the organizer receives moderator rights at first (and can then distribute them to the other participants if desired).

Is it possible to set this up?

Also, is it possible to invalidate the login after a certain time, so that users would have to register again as organizers to open a conference?

For moderator rights try @emrah’s token-affiliation module.

Any progress on that topic, because I am facing a similar problem. I am running a self-hosed Jitsi installation. I followed the guide on setting up a secure domain but skipped the part for anonymously joining a conference room.

My requirements are as follows:

  1. I have to groups of users, let’s call them “teachers” and “students”.
  2. Teachers are allowed to create new conference rooms and to be moderators
  3. Students must not create new conference rooms nor become moderator; they must only be allowed to join existing rooms
  4. Every user needs to be authenticated, even students

The work-around to a) only allow authenticated users to create new rooms, b) create only accounts for teachers and c) let students join conference rooms anonymously, is not a valid solution, because of requirement 4.

@metadata wrote

For moderator rights try @emrah’s token-affiliation module.

Is there any good how-to or tutorial how to use that module to achieve the requirements above? I believe this would be helpful for a lot of people.

The instructions are in the scripts:


we had the same problem, that we wanted to manage meeetings in advance and secure the server with JWT, so only internal member can create rooms but external can join the meeting like the big enterprise solutions. With the normal Jitsi configuration we only had the opportunitis which are written above to send a calendar entry with the link.
To make Jitsi enterprise ready and connect it with an LDAP Server we develop the Jitsi Admin, which is Open Source and would cover all your Needs. We publish it on Github and we have an Instance running wich can be used for free.
Github: GitHub - H2-invent/jitsi-admin: Der Jitsi Admin ist eine Administration und Management Plattform fĂĽr Jitsi Meet Server
If you have any questions, I would be very glad to help you.

Unfortunately, this is not what I would call a how-to or a good tutorial. Especially, those both plugins built upon the Prodody plugin JWT token authentication Prosody plugin which must be installed first. Moreover, the instruction describe how a JWT token has to look like and refer to RFC 7519 for a specification of those tokens, but of course this does not explain where these tokens come from, i.e. some kind of “authenticator” or token provider.

The documentation is fine for developers who already know how to setup all components and want to contribute, but the documentation is not a how-to or tutorial for administrators who want deploy such a setup. My apologies, but this is like pointing someone to RFC 2616 if one asks how to setup an Apache web server.

To my understanding the architecture/whole picture consists of the following components:

  • Prosody with the plugin mod_token_auth, token_affiliation and token_owner_party,
  • a backend which stores user accounts and privileges (LDAP, SQL database, etc.), and
  • some kind of “authenticator” aka “token provider” which receives authentication requests from Prosody, queries the backend, generates tokens and serve those tokens as a respond to Prodody.

So the first question is: What application can be used as “authenticator”/“token provider”? Is there any de-facto standard application already packed in typical linux distributions (like Apache and nginx for web server, postfix for smtp server, etc.)?

IMHO, a good tutorial/howt-o would start from a standard installation of Jitsi as a baseline and cover the following topics:

  1. Installation of the Prosody plugins (OK, that’s mostly in the readme)
  2. Installation of the backend (LDAP or similar)
  3. Installation of the “authentication service”/“token provider”
  4. Configuration of all these three components such that they interact with each other, especially configuration of the shared secrets such that these components can speak with each other
  5. Basic testing/debugging to check if the components actually do speak with each other or if something went wrong

Don’t get me wrong: You guys do a great job in developing Jitsi for free. That’s fantastic and unfortunately I don’t have the time to contribute which is a shame. Also, I perfectly know that nobody likes to write documentation, especially if it is unpaid. Coding is just so much more fun. But, if there is no good documentation/howto, then state so frankly and honestly. Nobody will be hurt by that. However, pointing administrators to some more or less internal developer documentation is somewhat strange.

1 Like

That sounds promising. I had a quick look on the Github page. Two questions which came to my mind from that:

  1. You write about LDAP as a backend in your post, but the Github ReadMe says MySQL. I assume the backend is changeable and more or less a configuration option?
  2. My requirements are that everybody needs to be authenticated, even those users that are only allowed to join a conference. Your post sounds as this is possible. The Github ReadMe says that authenticated users can create conference rooms and that guests can join without having a user account. I assume that both variants are possible? Because I require the first solution, I would only spend time for looking more closely on Jitsi Admin, if you could confirm that this is possible.

Tanks in advance


1.The authentication for the Jitsi Admin is with a keycloak Server. By this way a keycloak Server can be connected with a LDAP. We use this to use SSO with all our applications and make user authentication completly independend from the rest of the application.
The MySQL database is used for the meeting organisation.
2. It is possible that registered Users which are authenticated with the keycloak can create Meeting. The Participants which are then informed via Email can Join the Meeting with a link which is attached to the email. But the Link is unique for every participant and goas via the jitsi-admin server where a valid JWT is created. So every participant is authenticated against the jitsi-admin server with his email, and all moderators/organizers are authenticated via the keycloak and the jitsi-admin server.

This sounds to me as if security relies on the link. Participants obtain a JWT from the jitsi-admin server on the fly, if they connect to jitsi-admin using the correct, individual link. Hence, authentication only happens between jitsi-admin and jitsi, because they share a mutual secret to authenticate JWTs. But the participant does not need to enter his/her username and password. In other words, authentication of a valid participant only depends on the participant’s knowledge of the correct link. Right? Hence, any individual who knows the link can impersonate as a this participant.

Is there also an option that participants must provide a username and password?


we just build the possibility, that you can set it globaly for your own Jitsi Admin that all Users have to be registered. :slight_smile: You only need to set in your
Then every particiant needs to be authenticated via keycloak. If the user was never seen before, then he needs to register with the same email where the link was sent. Then the room is connected to his email and he can enter the konference.

@nagmat84 I don’t really understand what @emrah extensions do? Are the tokens are created by the plugin itself? Or do I need other services to achieve the desired result (only organizers are moderators and not other registered users. But organizers can select other moderators). We’re already using LDAP.


I am very interested in being able to use ldap2 in 2 groups.

  1. Group A (teachers) should be allowed to create rooms and get moderator rights.

  2. Group B (students) should only be allowed to log in, but not get moderator rights.

In “/usr/lib/prosody/modules/ldap.lib.lua” I found this:

local config_params = {
    hostname = 'string',
    user = {
        basedn = 'string',
        namefield = 'string',
        filter = 'string',
        usernamefield = 'string',
    groups = {
        basedn = 'string',
        namefield = 'string',
        memberfield = 'string',

        _member = {
          name = 'string',
          admin = 'boolean?
    admin = {
        _optional = true,
        basedn = 'string',
        namefield = 'string',
        filter = 'string',

Unfortunately, when I transfer this to ldap.cfg.lua, group B always has moderator rights.
Is it possible to implement this with ldap2 authentication @damencho ?


No, the plugin does not create the token. It only checks the affiliation (moderator or standart participant) which is in token and set the participant privileges according to the affiliation value.

Some advantages:

  • All participants may be registered users but it’s possible to set different privileges for each. For example some registered users have the moderator privileges for some rooms and some registered users not…

  • The moderator does not loss the moderator privileges when reconnecting

  • The meeting room will be terminated automaticly after all moderators leave it.

  • The registered users who have no moderator right for a room, cannot create it.

  • It’s possible to refine some privileges for each user. For example it’s possible to allow to screen-sharing for some moderator but not for some others…

Thanks for the info! What could I use to create and manage the tokens? Are there perhaps already instructions for this?

There is a sample PHP code which generates the token in this post but I don’t know a ready-to-use application for this.

I mostly use a custom middleware which integrates a user database or an already running system with the tokenized Jitsi server

I agree, the documentation could be improved a lot. I had similar problems understanding how everything works together, see this post and the two answers below.

No, the plugin does not create the tokens, it only validates the tokens and authorizes (not authenticates) users according to the tokens’ content. On top, you need a so-called identity provider (IP for short) and a repository which holds your user accounts (e.g. LDAP or a rational database). The IP authenticates the users and creates the tokens which are fed into Jitsi.

  • The IP and Jitsi have a mutual trust relationship based on a shared secret such that Jitsi can confirm that the token are generated by the valid IP.
  • The IP uses the repository to check the user credentials.

There are some full-fledged, heavy-weight IP solutions like Keycloak and alike. IMHO, they are ways too heavy for a simple, medium-sized setup with a handful of users. Especially, if the user accounts are self-hosted and you don’t plan to integrate 3rd party identity providers like Google, Facebook, etc.

I am going to start implementing a simple, light-weight solution this weekend which only consists of a handful of PHP scripts and replace the default welcome page of Jitsi. After I will have done so, I plan to write a Wiki article about it. At the moment, I envision a Wiki article which simply shows how everything acts to together. As I confirmed above: IMHO, the current state of documentation is missing a lot.

I prepared an installer to simplify installing a tokenized Jitsi with affiliation control.


1 Like

@nagmat84, would it be helpfull when we extend the rooms, that you can select if a room can only be entered by a registered participants? so that it is not globaly set, but every room can be choosen to be only entered when registerd at the keycloak, because then you can use the already installed version directly at platform and dont need to host jitsi-admin by yourself and set the options globaly.

@Emanuel_H That would be helpful. But I have to host Jitsi by myself anyway due to privacy and legal concerns.

@nagmat84 Thats the purpose of the jitsi-admin. you setup your own Server and only set jitsi-admin as a guard in front of your own jitsi server. it only manages the users and the meetings. Not your server.

Here we write how to setup a meeting and connect it to your server.