search

gotify / server

A simple server for sending and receiving messages in real-time per WebSocket. (Includes a sleek web-ui)
https://gotify.net
Other
11.33k stars 631 forks source link

SSO/OIDC: Option to disable authentication #433

Open tpansino opened 3 years ago

tpansino commented 3 years ago

Have you read the documentation?

You are setting up gotify in

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:

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 commented 3 years ago

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 commented 3 years ago

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 commented 2 years ago

Any plans to implement this? Would be very useful

yeyeoke commented 3 months ago

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

gthbusrr commented 3 weeks ago

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 commented 3 weeks ago

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 commented 3 weeks ago

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 commented 3 weeks ago

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 commented 3 weeks ago

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 commented 3 weeks ago

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

Related: #692

najtin commented 2 weeks ago

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 commented 2 weeks ago

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.