Draft agenda for our weekly meeting: Home - The Online Meeting Cooperative
3pm CEST at the main meetcoop room MEET.COOP MAIN MEETING ROOM
Please RSVP
2 Likes
Missed this one unfortunately…
Just to drop some notes from my sniffing around…
Check whether there’s an issue on the BBB github and open one for this feature. This might unblock many of the things we’d want to do.
This seems to have been discussed a bit but without any concrete direction. The link dump is Redirecting to Google Groups, Redirecting to Google Groups and Redirecting to Google Groups.
The ticket we need is (I think!) Generate multiple shared (salt) keys · Issue #9865 · bigbluebutton/bigbluebutton · GitHub but it is left comment-less. We could intervene there to bring about a discussion (one for the next day for me!)
A number of comments suggest that this sort of access control should be pushed out to the load balancer. There is some promising hints in Scalelite with different frontends · Issue #243 · blindsidenetworks/scalelite · GitHub and https://github.com/blindsidenetworks/scalelite/pull/115.
However, ultimately, the comment in https://github.com/blindsidenetworks/scalelite/issues/196 seems to show that core devs are not interested (yet?) in such access control directly in BBB…
… The same way a BigBlueButton server doesn’t have (access) “realms”, I don’t think Scalelite should either. Each front-end is responsible for showing its own meetings and recordings
We agree that we need to seek funds for account management software.
That seems to be the solution that the BBB dev team want to see at least. Each front-end does the job of access control. However this doesn’t mitigate against the situation where one clients front-end secret key is compromised and that cracks open the entire BBB back-end recordings and room access.
Anyway, hope this is useful to inform on the technical challenge, I will try to push my thoughts into the upstream BBB github/mailing list domain (after they solve https://github.com/bigbluebutton/bigbluebutton/issues/9820) and see what pressure can be applied there.
1 Like
Probably not the right place for all these notes but anyway…
From Video conferencing with BigBlueButton [LWN.net]
While BigBlueButton handles the conferencing tasks, it does not concern itself with front-end tasks like managing “rooms” or authenticating users. There is, instead, a reasonably well-documented API that is intended to be used by the front end. Given its roots in the educational community, it is not entirely surprising that applications like Moodle use this API to integrate with BigBlueButton.
And from https://docs.bigbluebutton.org/dev/api.html:
The BigBlueButton API security model enables 3rd-party applications to make API calls (if they have the shared secret), but not allow other people (end users) to make API calls.
You should not embed the shared secret within a web page and make BigBlueButton API calls within JavaScript running within a browser. The built-in debugging tools for modern browser would make this secret easily accessibile to any user. Once someone has the shared secret for your BigBlueButton server, they could create their own API calls. The shared secret should only be accessibile to the server-side components of your application (and thus not visible to end users).
I guess we should follow this model. If the BBB team work on this assumption that things remain server-to-server and that those servers remain secure, then we could image multiple front-ends mutualising a single BBB back-end. However, greenlight doesn’t seem to be made for that purpose…
1 Like