Jitsi Meet: Authentication not working - anyone can access

I have installed Jitsi Meet, and it is working. When creating a room I wish to have authentication against a simple, dedicated user database. I have followed the Arch Linux instructions in the Jitsi Meet ArchWiki entry. In particular, I have, in /etc/prosody/prosody.cfg.lua

VirtualHost "meet.example.org"
    authentication = "internal_plain" 
    ssl = {
        key = "/var/lib/prosody/meet.example.org.key";
        certificate = "/var/lib/prosody/meet.example.org.crt";
    }
    modules_enabled = {
        "bosh";
        "pubsub";
        "websocket";
        "saslauth";  -- needed? just trying things here...
    }
    c2s_require_encryption = true
    consider_bosh_secure = true

VirtualHost "guest.meet.example.org"
    authentication = "anonymous"
    ssl = {
        key = "/var/lib/prosody/guest.meet.example.org.key";
        certificate = "/var/lib/prosody/guest.meet.example.org.crt";
    }
    modules_enabled = {
        "bosh";
        "pubsub";
        "websocket";
    }
    c2s_require_encryption = false
    consider_bosh_secure = true

VirtualHost "auth.meet.example.org"
    ssl = {
        key = "/var/lib/prosody/auth.meet.example.org.key";
        certificate = "/var/lib/prosody/auth.meet.example.org.crt";
    }
    authentication = "internal_plain"
    admins = { "focus@auth.meet.example.org" }
    c2s_require_encryption = false
    consider_bosh_secure = true

I have also created users using prosodyctl register ... - however, I have never beed asked to log in, everyone can still create a room.

How can I force a password dialogue when creating a room?

Hello!
Did you follow these instructions (section " Secure domain")?

Dear Marqqs,

Thanks for the reply. I followed the Arch instructions but they are just a small variation of those. I have checked the official docs again now and I was missing org.jitsi.jigasi.xmpp.acc.ANONYMOUS_AUTH=false which, however, apparently makes no difference whatsoever.

My jitsi-meet/config.js has

var domainroot = 'meet.example.org'

var config = {
    // Connection
    //

    hosts: {
        // XMPP domain.
        domain: domainroot,

        // When using authentication, domain for guest users.
        anonymousdomain: 'guest.' + domainroot,

        // Domain for authenticated users. Defaults to <domain>.
        authdomain: 'auth.' + domainroot,

        // Jirecon recording component domain.
        // jirecon: 'jirecon.meet.example.org',

        // Call control component (Jigasi).
        // call_control: 'callcontrol.meet.example.org',

	// Bridge
	bridge: 'jitsi-videobridge.' + domainroot,

        // Focus component domain. Defaults to focus.<domain>.
        focus: 'focus.' + domainroot,

        // XMPP MUC domain. FIXME: use XEP-0030 to discover it.
        muc: 'conference.' + domainroot
    },

    // BOSH URL. FIXME: use XEP-0156 to discover it.
    bosh: '//' + domainroot + '/http-bind',

    // Websocket URL
    // websocket: 'wss://meet.example.org/xmpp-websocket',

    // The name of client node advertised in XEP-0115 'c' stanza
//     clientNode: 'https://' + domainroot + '/',  // jitsi.org/jitsimeet',
    clientNode: 'http://jitsi.org/jitsimeet',

    // The real JID of focus participant - can be overridden here
    // focusUserJid: 'focus@auth.meet.example.org',

I wasn’t sure here about clientNode and focusUserJid or websocket - do I need these? Are they correct in my config?

Sorry Nox,

I am no expert in this. :frowning:
I just followed “Secure domain” blindly and it did what I wanted.

I did not notice that you want to authenticate the users via your own database and not via Prosody database. Sorry.

Dear Marqss,

Thanks. I have no objections whatsoever against the Prosody database. That is a simple, dedicated database. I wrote that to make it clear I do not need LDAP, PAM or anything exotic.

Let’s hope someone else knows something!

I am sure. :slight_smile: There are a few developers writing in the forum.

Here is a video that helped me to understand the “secure domain” thing:

Thanks. That video didn’t help much either. I am ending up with 200 unclear options in 7 config files and I suppose one of them is responsible - but which one? Sadly all installation instructions do not show a single working set of config files but only which 4-5 lines to add to something that doesn’t look like mine. So, the result will be different, too.

@nox

This Virtual Host with “guest.example.org” is the one Prosody uses by default to determine if the user is to be authenticated. This one must therefore be changed to “internal_plain” otherwise no authentication will occur. Also this means that the authentication would take place against the flat files stored in Prosody servers. This would mean importing the names from your database to create the accounts within Prosody server.

Hope that helped. I hope I understood the issue you were having.

Seems you are missing jicofo, check that part out.

Thank you. When I change

VirtualHost “guest.meet.example.org” authentication = “anonymous”

to

VirtualHost “guest.meet.example.org” authentication = “internal_plain”

I am indeed asked for a password - the password authentication hangs, however, with an error message client-side (from FireFox developer console):

2020-05-09T10:45:59.913Z [modules/xmpp/strophe.util.js] <t.a/r.Strophe.log>:  Strophe: Server did not yet offer a supported authentication mechanism. Sending a blank poll request.

Jicofo is running on the server.

I have a new error, now, though (client-side):

XML Parsing Error: mismatched tag. Expected: </hr>.
Location: https://meet.example.org/http-bind?room=test
Line Number 6, Column 3:

In fact, that document now reads

It works! Now point your BOSH client to this URL to connect to Prosody.

which suggests non-configuration - but I have configured it. The server did work before I tried authenticating.

Anyway, my understanding of authenticating moderators only (when creating rooms) was to have an anonymous-open guest.meet.example.org and a meet.example.org with authentication? So one would need to tell Prosody to authenticate against the non-guest domain iff a new room is created?!