Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add authentication (via nginx) to access recordings #8505

Closed
iangilmour opened this issue Jan 17, 2020 · 13 comments
Closed

Add authentication (via nginx) to access recordings #8505

iangilmour opened this issue Jan 17, 2020 · 13 comments

Comments

@iangilmour
Copy link

iangilmour commented Jan 17, 2020

I'm using BBB 2.2.0-rc3 + Greenlight

It looks like if you know the recording URL you can access a conf room recording, without authentication, regardless of any Site settings. There is no way to restrict access to only authenticated BBB users.

So if the information inadvertently leaks because someone forwarded an email containing the recording URL by mistake there is no way to block the recipient from accessing the recording.

Ideally I'd like to specify exactly which users can access each recording. In the absence of that I'd like to restrict access to only authenticated BBB users. Is it possible to do either of these?

@ffdixon
Copy link
Member

ffdixon commented Jan 17, 2020

It looks like if you know the recording URL you can access a conf room recording, without authentication, regardless of any Site settings.

That's correct. While the recording URLs in Greenlight are only visible to the owner by default, they currently don't require authentication. (Think of them as similar to unlisted YouTube video links.)

So if the information inadvertently leaks because someone forwarded an email containing the recording URL by mistake there is no way to block the recipient from accessing the recording.

That's right.

We do have API calls to publish/unpublish a recording (which is different from Greenlight not showing the recording). An unpublished recording is still on the server, but the URL to view the recording will not work. However, what your looking for is some (authorized) people have access to the recording, while everyone else does not.

Today, what Greenlight is doing is the recording is always published (from the API point of view), but simply not visible by default to other users in the Greenlight interface. It's only visible to the owner of the room until they 'publish' it within Greenlight, which is to make the URL visible to others with the room's URL.

But it is an unathenticated URL.

Ideally I'd like to specify exactly which users can access each recording. In the absence of that I'd like to restrict access to only authenticated BBB users. Is it possible to do either of these?

That's possible for the future.

If users always access the recordings through nginx, and nginx generates a unique URL, then it's possible to first authenticate the user via Greenlight (i.e. they must have an account) and, if authenticated, nginx provides access to the recording. No authentication, no access.

In this manner, the underlying URL is not visible and nginx and could approve/deny users based on authentication.

We may not implement this as stated above, but it's a feature we want to add in a future version.

@iangilmour
Copy link
Author

iangilmour commented Jan 19, 2020

Fred - Thanks for the prompt reply.

Initially I want to fully restrict BBB access (conf rooms/ recordings/ etc.) to only authenticated users.
Longer term I might like to be support unauthenticated users being able to join conf rooms via the conf room URL - but still block them from accessing recordings, etc.

From your reply it sounds like I have a few options:

  • I could run BBB behind a VPN to restrict access.
  • I could use client certs and reconfigure nginx so only users with a valid client cert are allowed access to any part of BBB. Authenticated users would need to install the client cert in their browser.

The VPN approach won't support the long term goal of allowing unauthorised users to join conf rooms (they are unlikely to have a VPN connection). So of these 2 options I favour the client cert approach.

Has anyone done this, and identified the nginx changes required to support client certs? If so are there any docs on what nginx changes are required.

Or is there some other way of achieving the same goal with the current BBB?

@ffdixon ffdixon changed the title No authentication required to access any recording Add authentication (via nginx) to access recordings Jan 19, 2020
@ffdixon
Copy link
Member

ffdixon commented Jan 19, 2020

Another approach is to modify the getRecordings API call to generate temporary URLs to the recordings, and these URLs must go through nginx.

If nginx detects the URL is older than six hours, for example, or is unable to valid it, then do not serve the recordings.

We've changed this issue to "Add authentication (via nginx) to access recordings". We can't promise a date on when this will be implemented, but if others want to see this please add a vote here. For more information on how we prioritize our features, see http://docs.bigbluebutton.org/support/faq.html#when-will-feature-x-be-implemented

@iangilmour
Copy link
Author

iangilmour commented Jan 21, 2020

Anything that restricts unauthorized access to recordings is going to be a step in the right direction.

Given the current BBB implementation, I still like the idea of using client certs as a way of helping to protect access to conf rooms and recordings on a publicly accessible BBB. As well as preventing unauthorised recording access it would also prevent access to the entire BBB site - this would make it less susceptible to login attacks due to BBB users using poor (easy to guess) passwords.

Any docs or pointers describing how to add client side cert authentication to BBB would be useful for those that want the extra level of security they provide. If this info doesn't already exist possible it could be added to the road map too?

I accept the additional overhead and complexity of managing and distributing client certs (with a CRL, etc.), and getting users to install and use them correctly may be OTT for a lot of BBB current use cases.

@ffdixon
Copy link
Member

ffdixon commented Jan 21, 2020

Any docs or pointers describing how to add client side cert authentication to BBB would be useful for those that want the extra level of security they provide. If this info doesn't already exist possible it could be added to the road map too?

We don't have any documentation on this -- and by having an issue open to track this, you can expect that we'll implement it at some point in a future release.

For a bit more information on how we prioritize features for a release, see http://docs.bigbluebutton.org/support/faq.html#when-will-feature-x-be-implemented.

@galitus
Copy link

galitus commented Mar 23, 2020

I would like to see this feature too.
Because of corona we are switching our university/institut
to online learning and most professors don't like to see themself online.
So it would be nice to have. Even when it's a dirty hack for now.

Is there a way to configure this pretty easy on my own?:
"If users always access the recordings through nginx, and nginx generates a unique URL, then it's possible to first authenticate the user via Greenlight"

Thanks in advance and greetings

@ichdasich
Copy link

ichdasich commented Apr 25, 2020

I just stumbled onto this in my own setup, but am looking at a somewhat less problematic aspect of it (ensuring that recordings that are 'private' in greenlight are not accessible at all).

What I came up with (but have not implemented yet, as it means changing/replacing the scalelite-nginx container in my setup) would be the following:

  • add a third value to private/public in greenlight (accessible) with default to private; accessible getting the same behaviour as atm. private (accessible but not listed in GL), private see below.
  • add auth-rules to nginx to do request_auth to a small cgi on local host
    -- In the CGI, parse metadata.xml of the concerned recording to extract the gl-listed entry
    -- Only deliver the recording when it is not set to private
    -- if it is set to private, display a page explaining the three values and their implications

If an endpoint is placed on the GL host that exposes a CGI that handles auth against the greenlight DB, it would also enable authentication relatively easily (http_request_auth) via http_basic. However, the breaking issue there would be that it would only work for GL internal users.

@ichdasich
Copy link

ichdasich commented Apr 26, 2020

I implemented the above suggestion for my GL/BBB setup, see here: https://github.com/ichdasich/bbb-rec-perm

If combined with http-basic auth to request user/pass (and thereby supply it to /auth) the CGI could also check against the greenlight database to ensure only registered users/the user who created the meeting can access. This however breaks for all omniauth providers.

@DavidKi
Copy link

DavidKi commented Nov 2, 2020

  • 1 for this feature request
    I am using it for teaching at the university, some colleagues use it even for exams (confidential!). For attending students it should be possible to view the recording of a lesson. Everybody else should be blocked.

@ichdasich
Copy link

ichdasich commented Nov 2, 2020

Hello David,
take a look at rec-perm which i linked above. It can now also authenticate against Greenlight's database (if you use local accounts on GL and not LDAP/SAML).

@abockhold
Copy link

abockhold commented Mar 20, 2021

Hello everybody,
are there any plans to incorporate this in the mainline in the future?
Thanks!

@stale
Copy link

stale bot commented Dec 15, 2021

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the status: stale label Dec 15, 2021
@stale stale bot closed this as completed Mar 15, 2022
@zsubzwary
Copy link

zsubzwary commented Aug 13, 2022

Hi guys,
It has been quite some time now, has this feature been implemented or not ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants