Security of non-secure domains

Greetings!
My task was to implement protection of our Jitsi instanse from everyone’s access from Internet and i did it with some additional URL tokens and lua-scripting at nginx level, so now i happy to see that it works.
Every meeting’s name is being checked with white list, users don’t have access to main page and getting 403 on any attempt to create meeting url “on fly”. Https://jitsi.my.org/RandomMeetingName won’t work.

But actually because almost everything in our instalation is opened by default, i’m still worrying about our privacy and security. May i ask from Jitsi devs here any advice or hint, which of Jitsi components should be protected to prohibit any unauthorized using of our server in case, when all components are configured by default during installation process?

Thank you!

It’s somewhat hard to answer. What exactly do you mean by protect here? Do you just want that people can’t have meetings unless they are authorized? In that case I’d suggest enabling secure domain: Secure Domain setup | Jitsi Meet

Hi, Saul!
Thank you for your reply. I forgot to mention that absense of any password entering was key requirment from our team to our solution , that’s why classic, obvious and reliable secure domain was not set.
May be that caused my question to look a bit weird :slight_smile: Now we have SSO-protected interface for users to manage white list and this solution make our users happy.
Technicaly our Jitsi’s prosody is still open:

authentication = "jitsi-anonymous"

I’ m curious if such configuration is vurnerable for any abuse (unauthorized access for example) from Internet when Jitsi web interface access is protected by Nginx+Lua?

If you have SSO you can serve meet from there using the iframeAPI and close access to it by always requiring a token, which you will provide to users after they are logged in.
So you just risk people using your deployment and wasting your bandwidth, if that is a cloud VM normally that is paid.

Hi, damencho!
By SSO I meant AD-authorized custom form that our users use to manage white list. They do not need to enter their creds to use form itself.
IFrame API looks interesting as possible solution for future challenges though.

Generally speaking such scenarios are covered using a JWT token. Once authenticated your system would generate a JWT valid for that user and then redirect them.

Alternatively you may want to research Prosody’s LDAP authentication support.