Add Configuration for Reverse Proxy

[robotdan]

Add Configuration for Reverse Proxy

Problem

A reverse proxy such as Kong may set the X-Forwarded-Port header and this value may need to be overridden so that the CSRF handling in FusionAuth can successfully validate the Origin header against the request values.

Solution

Add a configuration to FusionAuth allow this value to be specified.

Alternatives/workarounds

See solution in @trollr's comment below ( #470 (comment) )

Additional context

Keycloak has an option to set the port for a reverse proxy.
https://www.keycloak.org/docs/7.0/server_installation/#enable-https-ssl-with-a-reverse-proxy

Comment from @trollr

In keycloak it's the combination of

<http-listener name="default" socket-binding="http"
     proxy-address-forwarding="true" redirect-socket="proxy-https"/>

and the definition of proxy-https

<socket-binding name="proxy-https" port="443"/>

Related Issues

#88

How to vote

Please give us a thumbs up or thumbs down as a reaction to help us prioritize this feature. Feel free to comment if you have a particular need or comment on how this feature should work.

[trollr]

This is how it looks like if you use kong as reverse proxy:

Kong port in k8s cluster: 8000/8443 (SSL) - public port: 80/443
Fusionauth container port in k8s cluster: 80/443 (SSL)

Reported request origin:

https://auth.fusionauth.com

Actual request origin:

https://auth.fusionauth.com:8443

The following X-Forwarded- HTTP request headers were detected on the request:

X-Forwarded-Proto: https
X-Forwarded-Host: auth.fusionauth.com
X-Forwarded-Port: 8443

Kong doesn't allow to change the x-forwarded-port at the moment.

[trollr]

Another possibility would be to allow to disable csrf protection

[trollr]

For everyone with the same issue using kong see: Kong/kong#5559

Fixed it with post-functions

[robotdan]

Thanks @trollr for sharing the solution. There may still be some value to add some advanced configuration to the admin UI to help in these situations.

We'll see how the community votes on this one to see if we can prioritize some resources.

Thanks

[ricardo-trevizo-b]

I have a similar situation using an AWS Api Gateway Http API + AWS Cloud map setup. Since Api Gateway doesn't support modifying headers whatsoever I can't workaround it meaningfully.

[arnecornillie-gantner]

Any update on this issue? I already reached out to fusionauth support, but still no feedback.. I'm using cloudfront as proxy.

[robotdan]

It probably makes the most sense to solve this in the proxy as @trollr did with Kong ( #470 (comment) ) I would assume this can also be done in CloudFront.

[mooreds]

@arnecornillie-gantner I have set up CloudFront proxies recently and used the instructions here: https://fusionauth.io/docs/v1/tech/admin-guide/proxy-setup with no issues.

If you have specific issues with CloudFront, please share your config and troubleshooting steps.

[arnecornillie-gantner]

Thanks for the feedback, the problem is not related to cloudfront itself, but the AWS ALB which is behind it.
Our setup looks like this:
Cloudfront -> AWS ALB -> ECS cluster
Cloudfront is listening to port 443 & our ALB is allowing port 9011, so in cloudfront I can configure the x-forwarded-port on 443, but our ALB will overwrite the value to 9011, resulting in issue using fusionauth..

I "temporary" fixed it by using the same port (443) on the load balancer, but this can potentially introduce security issues.

[philbenoit]

I have another set up matching @ricardo-trevizo-b above.

We use AWS HTTP API Gateway into ECS directly. Fusion Auth is again upset about the proto header but there are no options in AWS to change this. Implementing a reverse proxy would add dev time, maintenance and additional overhead to the call.

Being able to accept another header, perhaps one thats fusion auth specific would be of real benefit.

[mooreds]

Thanks for sharing your use cse @philbenoit . Please make sure to upvote the issue by clicking the 'thumbs up' icon on the body of the issue description. Here's our general roadmap guidance: https://fusionauth.io/docs/v1/tech/core-concepts/roadmap

You also may want to raise the issue with AWS support as I know they track customer requests too.

[connors511]

I have the same issue as @philbenoit and @ricardo-trevizo-b using the API Gateway, and don't really feel implementing a proxy is a viable solution due to added cost, maintenance and overhead.

Being able to accept another header, or even assuming X-Forwarded-Proto to be https when its missing and X-Forwarded-Port is 443 would be nice.

[MartinKavik]

The issue blocks the use of FusionAuth on Render.com - see https://community.render.com/t/setting-network-port-forward-reverse-proxy-manually-fusionauth/8419

[alex-fusionauth]

@MartinKavik sorry for the long delay, but I think you could use something like this to proxy all of your calls.

https://github.com/alex-fusionauth/fusionauth-render-proxy

[mooreds]

@alex-fusionauth does it make sense to add this to fusionauth-contrib? That's where we've put proxy configs in the past.

[AlanGRutter]

I have the same issue trying to use FusionAuth as an Azure Container App. I get a proxy error due to the way Azure Containers work. There is no option in Azure Container to add any headers. I already have a KrakenD API gateway but I really don't want to have my auth go through this step. I would rather be able to configure FusionAuth in some way directly.