Skip to content
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

Open
imnotjames opened this issue Apr 3, 2024 · 5 comments · May be fixed by #25
Open

Support reverse proxy authorization #24

imnotjames opened this issue Apr 3, 2024 · 5 comments · May be fixed by #25
Labels
enhancement New feature or request

Comments

@imnotjames
Copy link
Contributor

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.

@imnotjames
Copy link
Contributor Author

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.

@imnotjames
Copy link
Contributor Author

imnotjames commented Apr 4, 2024

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.

@imnotjames
Copy link
Contributor Author

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.

@amalshaji
Copy link
Owner

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.

@imnotjames
Copy link
Contributor Author

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. :)

@amalshaji amalshaji added the enhancement New feature or request label Apr 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants