HTTPS Redirect Issue while SSO Url is embedded in iFrame

[prasanna10021991]

The FusionAuth SSO server returning an HTTP response instead of an HTTPS response during a SAML request

Description

Fusion auth is giving me the response in http for the SAML request even though my request was

This causes the page which authenticates using the SAML request to be blocked as the browser identifies it as a page loading mixed content.

The nginx server on which the fusionauth app is hosted, returns proper 301 redirects with http requests upgraded to https but only fails on this fusionAuth authorize requests.

Upon enforcing a nginx conf change to redirect all http to https, the issue is temporarily handled in few browsers like chrome and firefox, but still fails in safari and ios versions of chrome and safari.

There is something odd that is happening with these versions of browsers as the SAML request keeps getting repeated in a loop and never stops thereby not loading the page in this instance too.

Steps to reproduce

Steps to reproduce the behavior:

1. Embed the page which authenticates with FusionAuth IDP in an iFrame
2. On load of the iFrame the URL embedded will initiate a SAML request in the background to the configured FusionAith IDP
3. FusionAuth returns http URL in response instead of https
4. Page stops loading as it is blocked by the browser for trying to load mixed content

Expected behavior

Response from FusionAuth server to be https url instead of http url

Platform

• Device: [Desktop, iPhone X, iphone 7, etc]
• OS: [e.g. iOS, macOS, Windows 10]
• Browser [ safari 13+, chrome in iOS, firefox in iOS ]

Screenshots

[prasanna10021991]

@robotdan , @jerryhopper .. I've raised a bug as suggested, to identify the source of this issue and if there can be any suggested workarounds to immediately get this working. I've tried upgrading requests by setting Content Security Policy and also as mentioned nginx conf..Both only work on chrome and firefox of desktops. Safari and other iOS devices have problem loading the page in all browsers. Could you please help me with this issue.

[robotdan]

Ensure your proxy is adding the appropriate X-Forwarded-Proto header.

[prasanna10021991]

@robotdan ..yes that is added in already, coz when we remove that we get a notification on the fusion auth admin portal.

[robotdan]

1. What is your configured redirect URL in your Application --> SAML configuration?
2. Can you enable debug in your SAML configuration (Application --> SAML configuration) and then see what the Debug Event logs show.
3. What is the value in the Location header in your first screenshot? You can remove the host, I'm looking for the path value.

[prasanna10021991]

1. What is your configured redirect URL in your Application --> SAML configuration?

2. Can you enable debug in your SAML configuration (Application --> SAML configuration) and then see what the Debug Event logs show.

Yes, I'm getting the SAML request, but response is not being sent back. The request seems to be fine:

3. What is the value in the Location header in your first screenshot? You can remove the host, I'm looking for the path value.

Path Value:
http://dev.sso/oauth2/authorize?client_id=be04d618-b2bd-4ecd-88ac-69959d548347&redirect_uri=%2Fsamlv2%2Fcallback%2F4d30cc31-ea5c-f9c7-9ace-d7da9994ebea&response_type=code&state=%7B%22ai%22%3A%22be04d618-b2bd-4ecd-88ac-69959d548347%22%2C%22id%22%3A%22id_bab47b32%22%7D

[robotdan]

These seems likely an issue with your proxy configuration. I am not an nginx expert, but if you post your config I may be able to review it.

[prasanna10021991]

Will send it out as soon as I get the info from the Devops team Dan. Thanks a ton

[JesperWe]

I had the exact same issue. @prasanna10021991 's suggested solution to add

proxy_redirect http:// https://;

solved the problem for me.

So apparently the X-Forwarded-Proto header which resolves other redirect issues was not enough for this particular function, which seems kind of strange.

[prasanna10021991]

@robotdan ..Is this something we're missing on our end in nginx configurations, or something's getting missed out during the communication with FusionAuth as the urls being sent out become http instead of https.

[robotdan]

@prasanna10021991 When we build a redirect URI we prefer the value provided in the X-Forwarded-Proto header, if that is not present then we use the schema on the servlet request.

I don't know a lot about NGINX proxy config, perhaps they don't always add the X-Forwarded-Proto header based upon the configuration.

[jlusky]

X-Forwarded- headers aren't working at all for me with nginx. And I've confirmed with wireshark that nginx is really adding them. I see these headers and broken redirect when I do curl https://login.mydomain.com:

tshark -V -i lo port 9011 | egrep 'X|ocation:|Host:'
Running as user "root" and group "root". This could be dangerous.
Capturing on 'Loopback'
X-Forwarded-Proto: https\r\n
X-Forwarded-Host: login.mydomain.com\r\n
X-Forwarded-Port: 443\r\n
X-Forwarded-For: 104.7.123.123\r\n
Location: http://localhost:9011/login\r\n

[jlusky]

The workaround for me in nginx is these two lines:
proxy_set_header Host "login.mydomain.com";
proxy_redirect http:// https://;

This doesn't actually fix FusionAuth, it just makes nginx rewrite the broken Location header from FusionAuth.

[robotdan]

Please re-open if you believe there is still a bug in FusionAuth causing this issue.