-
-
Notifications
You must be signed in to change notification settings - Fork 66
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support reverse proxy authorization #24
Comments
I started work on this as a feature over here -> https://github.com/imnotjames/portr/tree/feat/proxy-auth But I decided it'd be a good idea to open up the issue to get feedback before I add tests, configuration, etc. |
I could implement a trusted IP mechanism but after digging into this further it really increases the scope of the work by a lot. Perhaps we first enable the header if it's set and to be honest that's all I really need as far as a feature. The trusted proxy IP aspect was a nice to have in my mind. |
I do have something working over in my branch. I've built it in a new docker file and have deployed it as my local instance of portr. Works great behind traefik. I'll clean it up a bit. |
I would have to read up more about forwardAuth and security-related stuff. But this looks like adding support for a different kind of auth, which I think is something portr should support. |
Sure thing. I think in an ideal world portr would integrate with OIDC providers and handle authentication that way. With that, you could hook up to everything from Keycloak to Authelia to Google. It'd accomplish the same goals as forward auth but in a more secure manner. It's how things like minio & portainer handle these kinds of authentication problems. Unfortunately, that's quite a bit more involved than forward-auth seems to be. Probably would require bringing in external packages & is not a "hmm I can get this done in like an hour!" Kind of project. :) |
Is your feature request related to a problem? Please describe.
In my local set up I'm using traefik and forwardAuth -- this means that I have a trusted single sign on that goes from traefik -> oauth2-proxy -> keycloak.
Once that authentication occurs (+ authorization as defined in keycloak) users will be granted access to various services -- including portr. Aat that point, currently they then need to connect portr to their github account for a second authentication.
That's not ideal. I'd prefer if there's a simpler flow given I already manage the authentication and authorization.
Describe the solution you'd like
If configured via some sort of environment variables, I'd like for portr to check that it's currently connected to the trusted proxy & if it is accept a particular header as the authenticated user's email. Then create a user if they don't already exist - and if they do exist, allow them to continue as normal.
Describe alternatives you've considered
I'm currently using a patched dockerfile that implements this behavior - patching particular files so that this feature works, but it's very specific to my use environment.
I did think of turning off the traefik auth entirely for portr - relying solely on github -- but I'd really rather not require a github specific flow.
Additional context
The header is
X-Auth-Request-Email
for oauth2-proxy &Remote-Email
by default for authelia.I think this should also work for other reverse proxies such as caddy & nginx setups.
The text was updated successfully, but these errors were encountered: