screego / server

screen sharing for developers https://screego.net/
https://app.screego.net
GNU General Public License v3.0
7.76k stars 555 forks source link

Support OIDC #156

Open EvilBlood opened 1 year ago

EvilBlood commented 1 year ago

Hello, I think OICD for login would be a good extension for your tool. In many environments a service like Authentik (https://goauthentik.io) is used as OIDC provider. This would allow the tool to connect well with SSO.

csh0101 commented 1 year ago

I'm interesting in this. if you have no time or energy to support this, maybe i do this job. @jmattheis

jmattheis commented 1 year ago

Hmm, maybe this is only a documentation issue. Screego doesn't necessary need users, because you can disable the login:

https://github.com/screego/server/blob/c652513ccdb6341e6a1409119bceb6c3a849c204/screego.config.example#L66-L71

When setting the value of the auth mode to none, then a guest user has the same permissions as a logged-in user. Combining this with a reverse proxy supporting forward like described in here https://goauthentik.io/docs/providers/proxy/forward_auth you can already protect screego via SSO.

nogweii commented 1 year ago

How would someone set up authenticated TURN and Prometheus Metrics when the auth mode is set to none?

jmattheis commented 1 year ago

What do you mean with authenticated turn? Prometheus is unaffected by the SCREEGO_AUTH_MODE setting, you'd have to create a user like you'd do with SCREEGO_AUTH_MODE=turn.

nogweii commented 1 year ago

Referencing the example config: "turn: User login is required for TURN connections", but if you set up a proxy to handle OIDC authentication, how would those users authenticate to the built-in TURN server? (I'm expecting that you wouldn't suggest proxying TURN through the proxy.)

Looking into it, maybe the recommendation in that situation would be to use an external TURN server with a shared secret.

jmattheis commented 1 year ago

It basically just works out of the box and should be secure. The TURN credentials are separate from the user credentials and will be generated on demand for new connections, even if SCREEGO_AUTH_MODE=none is used. Screego will transfer these generated credentials to authenticated users via http/WebSocket. So only users that can access the http site can obtain turn credentials and SCREEGO_AUTH_MODE determines whether an additional user login is required.

So users that aren't allowed to access the http site, cannot get valid credentials to use the builtin turn server.

nogweii commented 1 year ago

will be generated on demand for new connections, even if SCREEGO_AUTH_MODE=none is used

Ah, that wasn't immediately clear to me. Thanks!


So, to restate this thread, as an alternative to natively supporting OIDC within screego, folks can do the following:

  1. Set SCREEGO_AUTH_MODE to none
  2. Put a reverse proxy in front of the server that does the OpenID Connect authentication
  3. Have screego only bind to the local network so it doesn't accidentally get exposed directly (so listening on the loopback interface, or on a UNIX socket)
  4. Bind the built-in TURN server to the external network interface, if users want to do that. Or, configure screego to use an external turn server if that is preferred.
  5. Create a user credential and put it into the configuration even though it's not being used for the primary user authentication so that Prometheus Metrics can be protected as well

All that remains then is documenting this as an example. There are too many reverse proxies and deployment options, so perhaps a docker-compose.yml file with screego & oauth2-proxy?

jmattheis commented 1 year ago

@nogweii Yes, thanks for summarizing. Point 5 is optional and only needed if you have prometheus metrics enabled.