Option to disable authentication

[tpansino]

Have you read the documentation?

• Yes, but it does not include related information regarding my question.
• Yes, but the steps described in the documentation do not work on my machine.
• Yes, but I am having difficulty understanding it and wants clarification.

You are setting up gotify in

• Docker
• Linux native platform
• Windows native platform

Describe your problem
Related to #203, #20.

I've noticed that authentication seems to be a hot topic for self-hostable services, like this one. There are many different standards people want supported (OIDC, SAML, AD, LDAP), all of which can be difficult to implement correctly and support. Libraries similar to passport.js can help, but generally have a learning curve to integrating them.

Looking through the Issues, another mode I have not seen suggested yet is to simply allow disabling of Authentication entirely. This has the benefits of:

• No additional libraries or knowledge necessary for the developer to implement
• Users can bring their own auth, typically in the form of a proxy like Oauth2-Proxy, or Traefik's ForwardAuth feature paired with an external Identity Provider like KeyCloak or Authelia
• Users can choose to have no auth and only secure their systems behind a firewall instead (great for experimentation and local development)

Given the reluctance on #20. and the ongoing discussion about an Auth plugin system, this seemed worth mentioning. I've seen projects avoid Auth plugins and ONLY offer built-in Auth or none, I've also seen projects that offer support for every method under the sun. Just depends on what the devs feel comfortable supporting.

I think most folks would like to see support for an SSO strategy, whatever that is. I personally use OIDC, but mostly via Auth proxies since not a lot of projects have native OIDC support, which I think is fair.

[jmattheis]

Hey, just disabling auth isn't enough because gotify needs to know which user should be used. Sure, it should be possible to add a setting like preauthenticed_user to the config, which auto logs on an existing user, but this feels a little hacky.

Generally I'm open to natively support another auth system, but as you say it's hard to choose (:.

[tpansino]

Ok, I've spent slightly more than 2 minutes playing around with Gotify now. 😅 When I wrote the above I didn't realize there were multiple users, that does complicate things.

Proxies that do authentication will usually set a Header like X-Auth-Request-User, X-Auth-Request-Email, X-Auth-Request-Preferred-Username, X-Forwarded-User, or X-Remote-User to indicate which authenticated user the request is associated with. The upstream server (Gotify) then just usually has a config setting to indicate which header it should trust to find the username.

The security of this depends heavily on (1) the proxy overwriting any incoming values on the request for the Header being used to store the user, to prevent spoofing, and (2) that the communication between proxy and app server is secure, either via HTTPS or a private network. In a Docker environment with a good modern reverse proxy like Caddy, Traefik, HAProxy, etc, this is the case.

This can be a really easy way to support the bring-your-own-auth model @jmattheis , if that's what you're looking for, to keep Gotify simple. People will no doubt still ask for native OIDC, LDAP, SAML support though, so it really comes down to philosophically whether you think that complexity should be added natively, or not.

I don't expect a solution here anytime soon, so I'll consider this issue resolved and stick with the native auth for now, live without SSO. Feel free to close this if you see fit.

[barrelltitor]

Any plans to implement this? Would be very useful