[Request] Handle SSO/OAuth/OIDC proxies/middlewares (like Authelia and Vouch)

[NyaomiDEV]

As of right now, if PufferPanel is behind a proxy that authenticates users, it will ignore that authentication and provide its own login screen; this results in two-step login which is often times inconvenient.

This can be simply avoided by looking at two things:

• The Remote-User Header in the request, which should match one and only one of the usernames, and if no user is matched then there's no authentication to be done;
• The IP of the request, since the Header can be only safely be checked and used if we are sure that it is the proxy talking with PufferPanel, and no other IPs.

There is an implementation of this mechanism in another Go project, that I will link for reference: navidrome/navidrome#1152

I hope this sparks some interest.

[LexFuturorum]

I see no benefits outside of a commercial environment, so please elaborate.

[NyaomiDEV]

I see no benefits outside of a commercial environment, so please elaborate.

@LexFuturorum It is true that we see SSO solutions in commercial software 99% of the time, however it is also true that this kind of logins is also used on non-commercial environments; just to name a few, there are:

• non-profit communities hosting multiple services (of which PufferPanel might be one);
• groups of friends sharing multiple services between them but referring to a centralized system for authentication;
• last but not least, private usage (which is my case; handling authentication once for all the stuff I have self hosted is way more convenient than having multiple accounts on my own computer; also, SSO often comes with baked in 2FA and YubiKey support, which is nice).

Also, this would be a nice support to have in every web based project IMHO.

[nepcore]

I see a far bigger issue than use case in the fact that PufferPanel needs to know more than if the user has entered vaild credentials on a login page as it provides a permission system for which it needs to know not only who the current user is, but for management purposes also which users exist

On top of that, SSO via OAuth/OpenID providers like Google etc tend to be a lot more sought for than reverse proxy based approaches, both of these approaches seem to work in wildly different way, additionally handling just multiple OAuth providers already tends to run into loads of differences between providers and OAuth is supposed to be a standard

Seeing all of that it seems to me that each external auth provider is a major effort to implement and doesn't contribute much to implementing further ones which makes this not worth it at the moment imo as there are a lot of other things we want to improve that are significantly less effort to implement and affect a much broader range of users

Note that this doesn't mean it won't ever happen, nor that a pull request would be rejected, just that i doubt that any team member will work on it in the near future

[LexFuturorum]

luckly for you you cando it on your own https://docs.pufferpanel.com/en/2.x/guides/contributing.html

[NyaomiDEV]

@nepcore

I see a far bigger issue than use case in the fact that PufferPanel needs to know more than if the user has entered vaild credentials on a login page as it provides a permission system for which it needs to know not only who the current user is, but for management purposes also which users exist

Sysadmins could create an user with the matching username as the one specified in Remote-User, so that PufferPanel has a match internally to handle permissions. The other project I linked does just that, it matches internal accounts with usernames provided by the auth middleware.

On top of that, SSO via OAuth/OpenID providers like Google etc tend to be a lot more sought for than reverse proxy based approaches, both of these approaches seem to work in wildly different way, additionally handling just multiple OAuth providers already tends to run into loads of differences between providers and OAuth is supposed to be a standard

SSO via Google or other providers that have the "Login with..." button of course would have to be supported separately and they are frankly outside of this feature request scope, as I am solely referring to proxies which are definitely more doable than Google and friends (even with small to medium effort); plus, you can be sure that the Remote-User header only contains usernames.

Of course it is duty of the system administrator, then, to provide the proxied panel with the correct data it is expecting, so it is not like you'd have to support each and every SSO middleware out there.

---

luckly for you you cando it on your own https://docs.pufferpanel.com/en/2.x/guides/contributing.html

@LexFuturorum I wouldn't know how to do it, since I am really not an expert in Go. That is the whole point of my feature request; had I known Go you'd bet I would've done it myself.

[dougmaitelli]

I will +1 this. I've been wanting this for quite some time. On my homelab I have a bunch of services, all behind a reverse proxy that handles authentication, PufferPanel is just one of the few that don't support this and makes me have to login twice.

[sideeffectdk]

I'll +1 this as well. SSO is super useful. My pufferpanel is running on a VPS where I have YUNOHOST in front of the pufferpanel instance, right now with a simple redirect. That is one of those services, @AryToNeX describes here:

• non-profit communities hosting multiple services (of which PufferPanel might be one);

Yunohost has information on which user is logged in and uses SSOwat, an nginx based SSO utility. With some kind of SSO implemented, i would be tempted to write a yunohost app template for pufferpanel, so yunohost uses can install pufferpanel with a single click.

[corelgott]

I know that this discussion is fairly old, but I think things have changed lately due to passwordless authentication with Passkey. Thus there are several advantages to header authentication support.

1. Enhanced Security with Passkeys: Integrating passkey (passwordless) authentication significantly boosts security. Passkeys, which are based on the WebAuthn standard, eliminate the need for passwords and use cryptographic keys stored on users’ devices. This approach mitigates risks associated with password theft, phishing, and brute-force attacks, providing a more secure authentication method.

2. Streamlined User Management: By using header-based authentication combined with passkeys, administrators can simplify user management. Users authenticate once through a secure method, and their session is managed across all services via headers. This reduces the need for managing individual credentials and enhances security policies’ consistency.

3. Improved User Experience: Users benefit from a seamless and convenient login experience. With passkeys, they can authenticate using biometric data (like fingerprints or facial recognition) or hardware tokens, making the process faster and more user-friendly. This is particularly advantageous for users who manage or access multiple Minecraft servers.

4. Centralized Authentication Control: Header-based authentication allows for centralized control over user access. By leveraging an identity provider that supports passkeys, administrators can enforce uniform security policies and streamline access management across all services, including PufferPanel.

5. Better Interoperability: Many modern authentication systems and identity providers support passkey authentication. By enabling header-based authentication in PufferPanel, it can easily integrate with existing infrastructures that utilize these advanced authentication methods, enhancing interoperability and simplifying deployment.

6. Future-Proof Security: Passkeys represent the future of secure authentication. By adopting this technology, PufferPanel ensures it remains aligned with the latest security standards, providing users and administrators with a robust, scalable, and future-proof authentication solution.

Incorporating header-based authentication with support for passkey authentication into PufferPanel would greatly benefit administrators and users. It would provide a secure, scalable, and user-friendly authentication method that enhances both security and usability, particularly for those managing multiple Minecraft servers or providing hosting services to others.

And since its no fun to implement passkey auth flow by hand, header auth would offload this to some auth provider. I personally use authentik witihin my home infrastructure to auth for serveral services (fileserver, owncloud, custom webpages, services for friends, octoprint etc.)