Authentication for creating meetings

I have jitsi running on an aws t3a.large instance.
works great.

But now anyone who knows the url can create a meeting. How do I require simple authentication? Like an unencrypted password. I don’t want/need authentication to join a meeting. If they know the meeting name, they can join.

Here is a copy of the last steps of the ubuntu installation process that provides the security you require. Please adjust according to the server you are using by relating these steps to the respective processes on your server.

Step 5 — Locking Conference Creation

In this step, you will configure your Jitsi Meet server to only allow registered users to create conference rooms. The files that you will edit were generated by the installer and are configured with your domain name.

The variable your_domain will be used in place of a domain name in the following examples.

First, open sudo nano /etc/prosody/conf.avail/your_domain.cfg.lua with a text editor:

sudo nano /etc/prosody/conf.avail/your_domain.cfg.lua

Edit this line:

/etc/prosody/conf.avail/your_domain.cfg.lua

...
        authentication = "anonymous"
...

To the following:

/etc/prosody/conf.avail/your_domain.cfg.lua

...
        authentication = "internal_plain"
...

This configuration tells Jitsi Meet to force username and password authentication before allowing conference room creation by a new visitor.

Then, in the same file, add the following section to the end of the file:

/etc/prosody/conf.avail/your_domain.cfg.lua

...
VirtualHost "guest.your_domain"
    authentication = "anonymous"
    c2s_require_encryption = false

This configuration allows anonymous users to join conference rooms that were created by an authenticated user. However, the guest must have a unique address and an optional password for the room to enter it.

Here, you added guest. to the front of your domain name. For example, for jitsi.your-domain you would put guest.jitsi.your-domain . The guest. hostname is only used internally by Jitsi Meet. You will never enter it into a browser or need to create a DNS record for it.

Open another configuration file at /etc/jitsi/meet/your_domain-config.js with a text editor:

sudo nano /etc/jitsi/meet/your_domain-config.js

Edit this line:

/etc/jitsi/meet/your_domain-config.js

...
        // anonymousdomain: 'guest.example.com',
...

To the following:

/etc/jitsi/meet/your_domain-config.js

...
        anonymousdomain: 'guest.your_domain',
...

Again, by using the guest.your_domain hostname that you used earlier this configuration tells Jitsi Meet what internal hostname to use for the un-authenticated guests.

Next, open /etc/jitsi/jicofo/sip-communicator.properties :

sudo nano /etc/jitsi/jicofo/sip-communicator.properties

And add the following line to complete the configuration changes:

/etc/jitsi/jicofo/sip-communicator.properties

org.jitsi.jicofo.auth.URL=XMPP:your_domain

This configuration points one of the Jitsi Meet processes to the local server that performs the user authentication that is now required.

Your Jitsi Meet instance is now configured so that only registered users can create conference rooms. After a conference room is created, anyone can join it without needing to be a registered user. All they will need is the unique conference room address and an optional password set by the room’s creator.

Now that Jitsi Meet is configured to require authenticated users for room creation you need to register these users and their passwords. You will use the prosodyctl utility to do this.

Run the following command to add a user to your server:

sudo prosodyctl register user your_domain password

The user that you add here is not a system user. They will only be able to create a conference room and are not able to log in to your server via SSH.

Finally, restart the Jitsi Meet processes to load the new configuration:

sudo systemctl restart prosody.servicesudo systemctl restart jicofo.servicesudo systemctl restart jitsi-videobridge2.service

The Jitsi Meet instance will now request a username and password with a dialog box when a conference room is created.

Image showing the Jitsi username and password box

Your Jitsi Meet server is now set up and securely configured.

I hope this helps.
Regards,
Shaun

Thanks for the quick response. I’ve used quotes instead of brackets below since I can’t figure out how to have brackets display.

Just to be clear:

If someone tries to create a meeting, a login dialog appears, which takes as user “prosodyctl user”@“domain name” and the prosodyctl password.

Guests now have to use the url : guest.“domain name”. Then enter the meeting name, correct? For a guest, just “domain name” will not work?

Will it work if a guest uses: guest.“domain name”/“meeting name” ?

@seandarcy ,
The “guest.domain name” url must NEVER be displayed publicly. Jitsi uses this internally so that a guest(unauthenticated user) can join a conference they were invited to. All they need is the url: “HOSTING_DOMAIN_/MEETING_ROOM_NAME”, and thats it.

Once they enter that URL, if the host is there, they will automatically enter. If the host has set a password, then a dialogue box will request the password and then the guest would be allowed in.

Its beautifully simple, thats why it seems a little unbelievable as one would expect it to be more complex. Let me know if this helps.

Regards,
Shaun

Hi there,
I just followed these steps exactly, but there seems to be no impact on the behaviour of my jitsi instance.
Still anybody is able to open rooms without authentication.
What might I have missed?

Regards
Roland

@Roland_Diera Please post a copy of your /etc/prosody/conf.avail/your_domain.cfg.lua for us to see. You may anonymize your actual domain name if you you so desire. But this has worked for me in one attempt so there has to be a configuration issue in your setup that we are somehow missing.

Hello,
I just resolved this issue by updating the jitsi installation and reconfiguring prosody. Now authentication works as designed.
Thanks
(closed for me)

Awesome!! :ok_hand:t5:

That’s just got to be wrong! Way too easy, but it works .

The rooms can be re-entered without authentication even after everyone has left the room. It looks like Step 5 — Locking Conference Creation - only works when you initially create the room. Does anyone have any idea how the keep the room from being used again unless a registered user sets it up again.

@seandarcy lol. Indeed right!! Just really unbelievable that its so easy.

My problem resolved after I fixed the issue with www vs no www prefix. It was behaving differently if the www prefix was present so I added code to rewrite url to remove www in virtual server in apache2 config files.

I did exactly all the steps listed above, however, if a guest wants to login to a conference room created by a registered user he still gets a dialog box aksing for a username and password. Is there anything I can do?