FusionAuth redirects to port 80 when logging in via HTTPS

[whiskerch]

(Put bug title here)

Incorrect redirection of OAUTH when logging in using SSL

Description

When logging in to the admin using HTTPS via: https://identity.********.io/oauth2/authorize, I enter my details, before being redirected to the 2FA challenge page.

Upon entering a correct challenge code, I am redirected to the following URL: https://identity.**********.io:80/login?code=**********&state=*******-*****************&userState=Authenticated

For some reason, port 80 has been specified at some point in the redirect URL.
When I correct the redirect URL and remove the port number the admin page is displayed

Steps to reproduce

FusionAuth has been deployed into a AWS hosted kubernetes cluster.

The Istio gateway configuration is as follows:

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: fusionauth-gateway
spec:
  selector:
    istio: ingressgateway # use Istio default gateway implementation
  servers:
    - port:
        number: 80
        name: http
        protocol: HTTP
      hosts:
        - "*********.eu-west-2.elb.amazonaws.com"
        - "identity.***********.io"
      tls:
        httpsRedirect: true
    - port:
        number: 443
        name: https
        protocol: HTTPS
      hosts:
        - "*******.eu-west-2.elb.amazonaws.com"
        - "identity.********.io"
      tls:
        mode: SIMPLE # enables HTTPS on this port
        serverCertificate: /etc/istio/ingressgateway-certs/tls.crt
        privateKey: /etc/istio/ingressgateway-certs/tls.key

Expected behavior

I expect the redirect url to be:
https://identity.**********.io/login?code=**********&state=*******-*****************&userState=Authenticated

not: https://identity.**********.io:80/login?code=**********&state=*******-*****************&userState=Authenticated

Platform

(Please complete the following information)

• Device: Desktop
• OS:macOS
• Browser + version: Chrome Version 72.0.3626.121 (Official Build) (64-bit)

[voidmain]

When FusionAuth logs into itself, we try to build the authorized redirect based on the information in the HTTP request that came in.

The code that builds the redirect_uri is using these components:

{scheme}://{host}:{port}/login

Each component is built from the request like this:

{scheme} = The X-Forwarded-Proto header if not null otherwise the Scheme header
{host} = The X-Forwarded-Host header if not null otherwise the host portion of the Host header
{port} = The X-Forwarded-Port header if not null otherwise the port portion of the Host header

If you are using a proxy (and it looks like that is the case), the proxy needs to properly set all of these headers in order for the redirect to work. I'm not familiar with Istio, but you might look into their configuration and see if you need to specify anything special to ensure that the headers are set.

[whiskerch]

Thanks for the quick response! - I'll have a look into what headers get set by the Istio gateway.

The main reason I am using Istio for this is because it forms part of the containers example here: https://github.com/FusionAuth/fusionauth-containers

Chris

[robotdan]

Perhaps there is a better way, but I found this example where the user configured a VirtualHost and used appendHeaders:. See: istio/istio#7964 (comment), which references this issue as well envoyproxy/envoy#4496.

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
...
  http:
...
    appendHeaders:
        "x-forwarded-proto": "https"
        "x-forwarded-port": "443"

[whiskerch]

I had come up with the same solution too!

I did try passing through the TLS connection to the FusionAuth container, however setting up certificates and keys got more difficult.

[robotdan]

This gist has an example of using proxy_set_header X-Forwarded-Proto.

https://gist.github.com/chanjarster/a0529d14466895de1ea69866d69c107c

[robotdan]

@whiskerch were you able to find the correct configuration to add X-Forwarded-Proto, X-Forwarded-Host and X-Forwarded-Port to the request?

If you have found something that works, I'd like to update the example configuration. You are also welcome to submit a PR to the fusionauth-containers project.

Thanks!

[whiskerch]

I did,

This is the config I used in my fusionauth-vservice.yaml:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: fusionauth
spec:
  hosts:
    - "xxxxx-xxxxx.eu-west-2.elb.amazonaws.com"
    - "identity.xxxxx.io"
  gateways:
    - fusionauth-gateway
  http:
    - match:
        - uri:
            prefix: /
      route:
        - destination:
            port:
              number: 9011
            host: fusionauth
      appendHeaders:
        "x-forwarded-proto": "https"
        "x-forwarded-port": "443"

and this is the fusionauth-gateway.yaml config to support https:

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: fusionauth-gateway
spec:
  selector:
    istio: ingressgateway # use Istio default gateway implementation
  servers:
    - port:
        number: 80
        name: http
        protocol: HTTP
      hosts:
        - "xxxxxx-xxxxxx.eu-west-2.elb.amazonaws.com"
        - "identity.xxxxx.io"
      tls:
        httpsRedirect: true
    - port:
        number: 443
        name: https-443
        protocol: HTTPS
      hosts:
        - "xxxxx-xxxxx.eu-west-2.elb.amazonaws.com"
        - "identity.xxxxx.io"
      tls:
        mode: SIMPLE # enables HTTPS on this port
        serverCertificate: /etc/istio/ingressgateway-certs/tls.crt
        privateKey: /etc/istio/ingressgateway-certs/tls.key

When I get a chance I'll submit a new PR, with updates and some words on how to create the kubernetes secrets for the tls certs

[robotdan]

Thanks @whiskerch! This is great. @nadilas did you run into similar issues with your K8s config?

[nadilas]

@robotdan I can’t speak to Istio yet, I have it currently deployed on my OpenShift cluster which is using routes for the incoming traffic, no issues so far. I can run a few tests if it helps.