It sure is strange!
I recorded the network log from the point I started the SAML request up to the final redirect after the authentication was successful and the port gets in. In short, this is how the flow looks like:
-
https://sq.example.com/sessions/init/saml?return_to=%2f- 302 redirected to
https://idp.example.com/... - goes through Kubernetes to Nginx of IdP
- IdP Nginx handles and passes request to IdP
- 302 redirected to
-
https://idp.example.com/.../login?...- normal login to the IdP
- after login redirects to SQ callback
-
https://sq.example.com/oauth2/callback/saml- callback handles SAML data and authenticates the user
- 302 redirected to
https://sq.example.com:8443
I can replicate this final redirect by accessing /oauth2/callback/saml outside of this flow. So if I just access the above URL as is, I also get redirected to https://sq.example.com:8443, which is why we first suspected the plugin as the culprit. However, as you correctly pointed out, it doesn’t really make sense. Also, when looking at the response headers for this final redirect, the Server header is set to nginx/1.12.2, so it would make sense that the problem is with Nginx somewhere.
My only problem is: why doesn’t the port appear on other SQ URLs? Why does this only happen in this one case?
Altough the port does not appear until the very final callback, I could imagine that maybe the Nginx of our IdP (which as you guessed correctly is also running on Kubernetes) is somehow responsible by setting a strange header? I’m totally shooting in the dark here, but since the SQ and the SQ Nginx setup looks correct, I really don’t know where else to look.
I saw that there are also plugins for GitHub and Azure Active Directory. I will try to setup one of these and see if I can replicate the problem. If the problem appears again it should be a very strong indicator that the problem is with our Nginx. However, if everything works fine, then the problem is somewhere else. I will report back once I tried it out!