Closed chrsin closed 3 years ago
Hi! Please provide the diagnosis data mentioned in section https://github.com/morincer/teamcity-plugin-saml#troubleshooting
I've tried logging it with the debug-auth-saml preset and the only lines that are logged when clicking the "login with SSO" button are as follows (I've replaced some of the values with
[2021-06-11 10:26:45,282] DEBUG [), no auth; http-nio-80-exec-9] - Settings validated
[2021-06-11 10:26:45,282] DEBUG [), no auth; http-nio-80-exec-9] - AuthNRequest --> <samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" ID="ONELOGIN_<UUIDHERE>" Version="2.0" IssueInstant="2021-06-11T08:26:45Z" Destination="https://login.microsoftonline.com/<GUIDHERE>/saml2" ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" AssertionConsumerServiceURL="https://build.impact.dk/app/saml/callback/"><saml:Issuer>https://build.impact.dk/app/saml/callback/</saml:Issuer><samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" AllowCreate="true" /></samlp:AuthnRequest>
[2021-06-11 10:26:45,282] DEBUG [), no auth; http-nio-80-exec-9] - AuthNRequest sent to https://login.microsoftonline.com/<GUIDHERE>/saml2 --> <ALongGarbledHashImUnsureIfSafeToShare>//n1x81c=
TeamCity version: Enterprise 2020.2.4 (build 86063) TeamCity saml config
Metadata xml file
Ok, well, definitely "AuthNRequest sent to https://login.microsoftonline.com" shows that the request is sent to the correct destination. Let's now see what happens in your browser. In Chrome, open devtools (F12), switch to the Network tab, make sure the "Preserve log" checkbox is set and re-do the sequence. Find the response from teamcity and show me the headers. I bet something is replacing the Location header
These are the requests
The first request to https://build.impact.dk/app/saml/login/
receives a 302 redirect to
https://build.impact.dk/671a20e3-be78-467d-8591-cc4c22259a1b/saml2?SAMLRequest=<TheFullSamlRequest>&RelayState=http%3A%2F%2Flocalhost%2Fapp%2Fsaml%2Flogin%2F
Once the browser has been redirected it gets a 404 since TeamCity can't handle the saml request
Here is an image of the headers for the redirect
Seems like your reverse proxy is spoiling the Location header - 302 redirect should be targeting login.microsoft.com.
Am also experiencing this when accessing TeamCity directly (without going through the reverse proxy). But I just noticed that when clicking the login button I get redirected to the reverse proxy url. I tried manually doing localhost/app/saml/login and it works (avoiding the reverse proxy) So I think you are right. This must be the reverse proxy causing issues.
Thank you very much for your help 🥇 and so sorry I didn't catch this myself. 😞
For anyone else ending up here. See this to solve: https://stackoverflow.com/questions/32513861/iis-reverse-proxy-interfering-with-redirect-location-header
I'm experiencing a weird issue where TeamCity redirects to the url I entered in "Single Sign-on URL" but with the hostname replaced with TeamCity's own hostname.
So for an example when I enter "https://login.microsoftonline.com/guid-guid-guid-guid-guid-guid/saml2?lotsofstuffinquerystring" in Single Sign-on URL I get redirected to "https://myteamcityurl/guid-guid-guid-guid-guid-guid/saml2?lotsofstuffinquerystring" when clicking the sso button. I've tried manually replacing the hostname of the url I get redirected to and this will initiate the login flow with the idp.
So for some reason the Single Sign On is "rewritten" to teamcitys hostname.
Prior to installing the plugin I tested it out in a docker instance on my local machine and this was not an issue. The only thing I can think of is that the server on which I'm experiencing the issues is behind a reverse proxy. But I havent been able to imagine why this would cause any problems. (Also, accessing TeamCity on the server directly using the localhost url also does the redirect to the same url as I've described earlier)
Since we are never redirected to the idp, I don't feel this can be a misconfiguraiton at the idp. I'm at my wits end here. Is there any log files I could look to for a chance to resolve this? :)
I can provide more information I'm just not sure what information to provide.