JWT authentication + anonymous guest domain, bugged or working as intended?

Instead of polling Prosody for conferences, you could use the event_sync module to notify your backend when rooms are created/destroyed/joined/left. That way, you have all the info your backend to implement a complete joining workflow:

  1. Users authenticate with your own app using whatever mechanism you want, and you decide what room they can join and what rights they have.
    • You can then generate them the appropriate JWT token and redirect them to the jitsi room
  2. For guests:
    • if room not yet created, it means admin not yet joined. You can implement your own “waiting for host” page for this use case
    • you could even notify the admin via email/slack/whatever that someone is waiting to join
    • the moment room-created event comes in (i.e. when admin joins room) you can admit them directly without waiting for some poll interval
  3. When sharing links for guest access, you don’t even have to include actual Jitsi room name. You app can handle mapping between between arbitrary ids/names and actual room names (which could be random UUIDs).
  4. Bonus feature: your backend has info about who is currently in room, and list of guests waiting, so you could potentially show admins that info before they join

If you couple this with the reservations plugin you can further lock down your Jitsi deployment by insisting that prosody validates with your backend before a room is created. Otherwise, once a guest has a JWT token that is still within the valid timeframe, they could bypass your app and go directly to your Jitsi server. Reservations also opens up the door for other features like time limits on rooms and max occupancy limits.

Just a thought :person_shrugging:

4 Likes

So many good points!

Exactly. At the moment we have an application up and running which translates LDAP(S) and Radius authentications into Jitsi Compatible JWT tokens. The great thing about this system is the flexibility. In our case it’s Python based so the authentication is only really limited to the capabilities of Python and its various connector libraries.

Great idea.

Also a great point, better to be event based than polling.

Also a great idea. The information could be used to create a simple admin web-UI for Jitsi. I have not explored much of it yet, but I reckon this is akin to what the Jitsi-admin project is doing.

I had this specific concern when writing my last reply so I’m happy to hear that this can be resolved as well.

All in all an awesome reply, thanks for all the ideas, will look into it!

Cheers,
Nicolas

1 Like

Correct.

1 Like

Perfect,

Appreciate the help and swift replies.

Regards,
Nicolas

Hi, I have the exact same setup running, which worked for a long time. The last update broke my setup. Now am am also getting “token_verification error Token nil not allowed to join” for anonymous guests joining.

see token_verification error after update · Issue #11967 · jitsi/jitsi-meet · GitHub

OLD LOG before update (Guest joining domain sichere-videokonferenz.de):

==> /var/log/prosody/prosody.log <==
Aug 08 09:13:53 boshcc367f28-6cb2-481f-88b9-034f63499bd7 info BOSH client disconnected: session close
Aug 08 09:14:04 mod_bosh info New BOSH session, assigned it sid ‘ec63ce20-c05d-4e7a-9fd6-828280725597’
Aug 08 09:14:04 boshec63ce20-c05d-4e7a-9fd6-828280725597 info Authenticated as f94e014b-808a-44a0-b562-97c38b264ffb@guest.sichere-videokonferenz.de

NEW LOG after update (Guest joining domain test.sichere-videokonferenz.de):

==> /var/log/prosody/prosody.log <==
Aug 08 07:15:15 bosh22c7d17f-e4a4-4abe-9326-4d4dfe40bb6b info BOSH client disconnected: session close
Aug 08 07:15:17 mod_bosh info New BOSH session, assigned it sid ‘6caf359d-1b48-4469-bc28-4be80398a2a2’
Aug 08 07:15:17 bosh6caf359d-1b48-4469-bc28-4be80398a2a2 info Authenticated as 5bea098a-f656-4973-8280-6b76ee68c2a1@guest.test.sichere-videokonferenz.io

==> /var/log/jitsi/jicofo.log <==
Jicofo 2022-08-08 07:15:47.193 INFO: [67] ConferenceIqHandler.handleConferenceIq#63: Focus request for room: scientificaccessesconsentnewly@conference.test.sichere-videokonferenz.io

==> /var/log/prosody/prosody.log <==
Aug 08 07:15:47 conference.test.sichere-videokonferenz.io:token_verification error Token nil not allowed to join: scientificaccessesconsentnewly@conference.test.sichere-videokonferenz.io/5bea098a

==> /var/log/prosody/prosody.err <==
Aug 08 07:15:47 conference.test.sichere-videokonferenz.io:token_verification error Token nil not allowed to join: scientificaccessesconsentnewly@conference.test.sichere-videokonferenz.io/5bea098a

How does the jicofo config look like?

Hello, i have a similar issue as mentioned above.
workaround i found that helped: disable domain validation in util.lib.lua

self.enableDomainVerification = module:get_option_boolean('enable_domain_verification', false);

more details on my issue / setup:

  • issue happens for jitsi 7577 and later.
  • I want rooms to be created on an authenticated basis, centrally via keycloak. as such i use jitsi-keycloak for that.
    jicofo config:
jicofo {
    authentication {
      enabled = ${JICOFO_AUTH}
      type = ${JICOFO_AUTH_TYPE}
      login-url = meet.jitsi
    }
    bridge {
      brewery-jid = "JvbBrewery@internal-muc.meet.jitsi"
    }
    health {
      enabled = true
    }
    codec {
      video {
      }
    }
    conference {
      enable-auto-owner = true
      initial-timeout = "15 seconds"
      single-participant-timeout = "20 seconds"
    }
    octo {
      id = 1
    }
    xmpp {
      client {
        enabled = true
        hostname = "xmpp.meet.jitsi"
        domain = "auth.meet.jitsi"
        client-proxy = "focus.meet.jitsi"
        username = "focus"
        password = ${JICOFO_AUTH_PASSWORD}
        conference-muc-jid = "muc.meet.jitsi"
        disable-certificate-verification = true
      }
    }
}

Can you paste one of your tokens?

there you are:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJjb250ZXh0Ijp7InVzZXIiOnsibmFtZSI6IiAiLCJlbWFpbCI6InRvYjEyM0B0ZXN0Lm5vdyJ9fSwiYXVkIjoiaml0c2kiLCJpc3MiOiJqaXRzaSIsInN1YiI6Im1lZXQuaml0c2kiLCJyb29tIjoiKiIsImlhdCI6MTY2MDY4MDUxMH0.dlO6LP8B_Uqu0qtfuFQqUGiA3wsKmXXsA80j-HEJMqw

seems to parse ok @jwt.io
also. this token works fine on all versions to create the meeting. it is just that with this token guest access breaks on 7577 and later.

i also tested now with docker-jitsi-meet, same result.

sorry… one more comment / forgot to add relevant config part in .env as part of the docker-jitsi-meet:

ENABLE_AUTH=1
ENABLE_GUESTS=1
AUTH_TYPE=jwt
JWT_APP_ID=jitsi
JWT_APP_SECRET=<my secret>
TOKEN_AUTH_URL=https://<jitsi-keycloak-domain>/{room}

@saghul this should be the same as Jibri cannot record if the token authentication is enabled · Issue #11999 · jitsi/jitsi-meet · GitHub
I will try to look at it these days.

1 Like

I am having a similar problem. We have Jitsi working in conjunction with Rocket Chat, when you log in from RocketChat to Jitsi, a token is generated and a room is created. If the room is created, then you can follow the link anonymously. But after updating to 2.0.7577, it became impossible to invite a telephone participant through Jigasi.
If you disable token_verification, then everything works as I expect: it is impossible to create a room without a token, you can follow the link to an existing room, you can connect a participant via jigasi.

Just set enable_domain_verification = false in prosody config.

1 Like

hello damenco. thanks for sharing the prosody configuration setting.
earlier ( before 7577) this was already set.
out of curiosity though: domain verification seems like a good idea (from a security perspective). can you share what the domain verification is intended for (what domain is validated ?)

The one from the jwt token.

This solved the issue token_verification error after update · Issue #11967 · jitsi/jitsi-meet · GitHub. Thanks so much!

thanks damencho, saghul for fixing this. the prosody variable works for me to. one more question though. in case i do want domain validation: how can i arrange this ?
not sure if the following is important: i run with docker. internal domain = meet.jitsi, external domain = <my.public.domain> and an external reverse proxy that handles tls decryption.

What is your usecase, jibri? Jigasi? Transcriber?

Hi, my usecase is to allow authentication to take place to setup meetings. jibri, jigasi or transcriber are not part of the setup. For authentication I use keycloak as the place to create users. and i use jitsi-keycloak ( GitHub - d3473r/jitsi-keycloak: Login to jitsi with keycloak https://hub.docker.com/r/d3473r/jitsi-keycloak) to deliver jwt tokens.