Feature request: please add an option to the admin panel to disable the built in basic authentification

[stepfister]

Hi,

the goal:

protect the access to the streaming site with a password, enable private streaming for a limited group of user

the problem:

• if you want to integrate owncast on your server with your own basic authentification you have to deal with the built in basic authentifcation of the owncast admin panel
• the built in administrator has always the username "admin" and the password of the stream key
• you have to make a real difficult configuration with reverse proxy and have to double the admin account in your own setup with apache, nginx, caddy etc.
• if you change the streaming key, you have to change the doubled admin account in your server setup too

possible solution:

• allow the user to disable the builtin basic authentification as an option for expert users
• then you can configure your own authentification with different users for streaming.site and streaming.site/admin
• you don't have to deal with the built in basic authentification if you don't want to
• the normal simple user can use the built in basic authentification, nobody has to do it per default

another suggestion:

• implement a better way to authenticate the user as an option for private streams, which is much easier then to fiddle around with proxy server and co

There are multiple use cases. Private stream for friends or for students in a virtual classroom. Just some ideas.

[gabek]

Many people have put their streams behind different styles of proxies in order to use types of authentication in front of their Owncast server in the past, and it didn't require removing Owncast's built-in authentication. This has never been something anybody has ever asked for before, and I'm not sure why they would.

I'm sorry your particular configuration of your proxy is not working with Owncast, but that sounds like a proxy configuration issue. If Owncast works without the proxy but doesn't work with it then changing how Owncast works doesn't sound like the answer.

If your goal is to limit access to your Owncast instance then removing built in auth isn't the solution. Besides, if you can't access the admin because of the proxy, then how would you even access such a setting?

[4censord]

I have been testing this for the last hour, it took me surprisingly long to make it work.

Using caddy as reverse proxy, this can work like this.

With caddy listening on localhost:80, and owncast running on localhost:8080

What works is:

http://localhost {
	basicauth * {
		Bob $2a$14$Zkx19XLiW6VYouLHR5NmfOFU0z2GTNmpkT/5qqR7hx4IjWJPDhjvG
		admin $2y$05$pZvLdtKMwiLIFS7zy2dMZOV57YFPHSwdnjzHf3FgHeoaX19RanEeG
	}

	reverse_proxy http://localhost:8080 {
	}
}

The important thing to notice is that the admin user is the same as what owncast expects for the admin panel.
Caddy forwards that directly so normal users don't have access to admin panel.

For this example:

User | Password
Bob  | hiccup
admin| abc123

What I haven't yet figured out is how I would integrate this with some kind of single sign on.

[gabek]

In this thread there's a couple mentions of some single sign on proxies such as Vouch and oauth2 proxy. It's yet another thing you'd have to run, but these seem to be the right tool for the single sign on job.

[stepfister]

@gabek

Many people have put their streams behind different styles of proxies in order to use types of authentication in front of their Owncast server in the past, and it didn't require removing Owncast's built-in authentication. This has never been something anybody has ever asked for before, and I'm not sure why they would.

Maybe I'm wrong but owncast is using his own built in basic authentification. I'm putting another basic authentification in front of it. This is the cause of the problem, I think. Simplify the case and give freedom to the user to configure his own authentication.

But when the solution is what @4censord has found out: Simply double the admin account with your own proxy configuration aka configure with basic authentification the admin again, which is yet preconfigured in dependance of the streaming key ... If this works then I'm satisfied.

Thank you 4censord. I try it with my apache.

[stepfister]

Just in case you want to add it to the documentation ;)

Whats the use of it? With this configuration you protect the access to the streaming site "streaming.site" with basic authentification and only the "admin", preconfigured in owncast, can open "streaming.site/admin" to configure owncast. It is useful if you want to make a private stream for a closed group of users. This is also the solution for the SSL reverse proxy which maps https to http. You give the credentials to your chosen people. Nobody without your credentials can watch your stream.

Here is the working solution for my configuration for Apache. Use you own data for "email@email" and "streaming.site". These are only placeholder. The real game changer is: You have to double the admin account in your basic authentification. If you change your streaming key, then you have to change the admin account in your ".htpasswd" again. I have now a normal user in the ".htpasswd" and the admin-account of owncast.

<IfModule mod_ssl.c>
<VirtualHost *:443>
    ServerAdmin email@email
    ServerName streaming.site
    ServerAlias streaming.site
#    RequestHeader unset Authorization # it is not needed, just in case

    ErrorLog "/var/log/httpd/streaming.site-error_log"
    CustomLog "/var/log/httpd/streaming.site-access_log" common

# Proxy for owncast with password protection
        ProxyRequests       on
        ProxyPreserveHost   On
        ProxyVia on	
        AllowEncodedSlashes NoDecode

        <Proxy *>
        Order deny,allow
        Allow from all
        AuthName "Authorized personnel only."
        AuthType Basic
# the real trick is to make an entry with user "admin" and the password which is used in owncast
# do it with "htpasswd -c" if you are using it the first time it creates the passwd-file
# use command "sudo htpasswd .htpasswd admin" and type the owncast passwd in
# without "-c" option it adds the new account, with "-c" option overwrites the password file
# don't forget to make a normal user with the same command
# for instance "sudo htpasswd .htpasswd normalusername"
        AuthUserFile /etc/httpd/conf/extra/.htpasswd
# end of the trick, you see nothing of the configured users in this config
        Require valid-user
        </Proxy>

        ProxyPass        / http://localhost:8080/
        ProxyPassReverse / http://localhost:8080/

	RequestHeader    set X-Forwarded-Proto "https"
	RequestHeader    set X-Forwarded-Port "443"
        # setup the proxy to forward websocket requests properly
        # (note: this proxy automatically converts the secure websocket (wss)
        # to a normal websocket and vice versa.
        RewriteEngine On
        RewriteCond %{HTTP:UPGRADE} ^WebSocket$           [NC,OR]
        RewriteCond %{HTTP:CONNECTION} ^Upgrade$          [NC]
        RewriteRule .* ws://127.0.0.1:8080%{REQUEST_URI}  [P,QSA,L]
# proxy for owncast

SSLCertificateFile /etc/letsencrypt/live/streaming.site/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/streaming.site/privkey.pem
Include /etc/letsencrypt/options-ssl-apache.conf
</VirtualHost>
</IfModule>

Wow, thanks again to all of you. @4censord you made my day.

[stepfister]

I updated the first post to make the problem clearer.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If this was a feature request that others have shown no interest in then it's likely to not get implemented due to lack of interest. If others also want to see this feature then now is the time to say something! Thank you for your contributions.