@Aaron_K_van_Meerten what is the recommended approach for multi tenant deployment of Jitsi? E.g. we are going to share one Jitsi instance for multiple tenants, and also we would like to restrict users from tenantA to join meetings of tenantB.
Just to follow up on this topic from the Jitsi Call today — it would be really helpful to have more clarity on the multi-tenancy strategy that is currently being used by Jitsi in Production. More specifically, understanding the specifics on additional prosody modules or logic, as well as nginx config and config.js details to support separation between tenants, supporting a /tenant/meetingId URL structure, tenant/subdomain sequestering in JWT tokens/claims, and whatever “dynamic tenant MUC” setup that was mentioned on the call today.
Thanks a lot for all your help with this!
@Aaron_K_van_Meerten could you please take a look?
Hi, I’ll be working on this over the next week or so. The process will be to move the prosody modules into the open source, and develop documentation around this setup. This isn’t my main work priority this week so I may not have anything to show until probably late next week. If you haven’t heard anything by the next community call feel free to ask about it again and we’ll have an update.
@Aaron_K_van_Meerten here is what I have found related to multi tenancy.
- Official Jitsi Meet page generates
muchostname based on url.
E.g. if you visit URL https://meet.jit.si/orange/mymeeting, then
config.hosts.mucwill be set to
conference.orange.meet.jit.si. Subdomain here is
orange. So, is it correct, that putting subdomain names to
mucwe can achieve multi tenant setup? What else config should be set for Prosody?
- Now I am aware about only two config options:
enable_domain_verifiationshould be set to
muc_mapper_domain_baseshould be set to
The question is: is it enough or something else should be done?
Thanks a lot for all your help with this!!!
@Aaron_K_van_Meerten I’m curious about the multi-tenancy approach. Is this understanding correct?
Jitsi-Meet (JS) would use firstname.lastname@example.orgA.app.com
A prosody plugin similar to mod_filter_iq_rayo rewrites that jid to
and “conference.app.com” is configured in the prosody cfg as a muc.
Is that correct?
Is just that prosody plugin missing from jitsi-meet/tree/master/resources/prosody-plugins ?
That’s basically correct. We call the
syntax the “internal” representation as this module rewrites all IQs which reference this value in incoming and outgoing hooks. This way the client only has to know about the “external” representation below, and we don’t have to pre-provision tenants in the prosody configuration
However certain pieces such as prosody modules end up parsing the internal representation as well.
@ivanr you are correct. The final step would be to enable the mod_muc_domain_mapper module which we haven’t yet release but I hope to get time for mid-next week.
@Aaron_K_van_Meerten good news, thanks a lot!