SSO/OIDC: 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

[yeyeoke]

As a new user of this awesome project, This would be truly great to see implemented!

[gthbusrr]

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 vote for OIDC.

[eternal-flame-AD]

I think an auth plugin is possible although I defer to jannis for our final take on this. My recommendation is accept a PR but not priority.

SSO often goes beyond authentication and gets its hands on authorization (it is marketed as an authentication solution but in reality delivers much more than that) so everybody has different situations, can I know what kind of setup do you have?

Do you only want pure authentication (login once, get a token and end of story)? This feels doable. and my perceived benefit to you would be you can have one single login for all your services for you or your small team (?) But I still want to evaluate the feasibility of just using a proxy for this: essentially all you need is readapt a sample OIDC solution let it make a request to gotify and it would be similar result?

Do you want a more full workflow more designed for larger organizations (no client-side tokens, session management, etc), this feels like architecturally incompatible.

[barrelltitor]

For my personal usecase I'm just tired of having a million accounts for something local to my home. Would be nice to be auto logged in as a user via oidc or an oidc proxy, some trusted header from a proxy or whatnot

[ericvenneker]

I would really like to be able to use Authentik as an IDP, wether this is a full-on OIDC or SAML or just a plain proxy solution.

Running a home-server for a house hold with even a small number of applications will create a lot of user accounts. Authentik (or any IDP for that matter) will significantly decrease the number of accounts and passwords that we need to keep track of.

[jmattheis]

I'm not sure if making this pluggable is worth the effort designing and supporting the plugin interface. Gotify doesn't really need enterprise SSO stuff like SAML, as it's not really built for this anyway. I think supporting OIDC should cover nearly all use-cases and should be good enough.

We can probably ignore authorization, as the only configurable permission in gotify is creating users and this should be taken care by OIDC.

[eternal-flame-AD]

I will look at possible workflows this weekend. I never deployed OIDC on my own but I will try it out.

Related: #692

[najtin]

Thanks for looking into this. I had to build an OAuth 2.0 flow from nothing a while ago, though i'm not sure if i can be helpful. Let me know if you have a specific question.

I will look at possible workflows this weekend. I never deployed OIDC on my own but I will try it out.

Related: #692

[eternal-flame-AD]

I guess we can have a new API endpoint that exchanges an OAuth access code for a client token? It shouldn't change the infrastructure too much, and add a WebUI button that appears when you have OIDC configured.