Closed fatmcgav closed 4 years ago
https://support.okta.com/help/s/question/0D51Y00007HGjfxSAD/need-a-way-to-pass-query-param-in-login-url-get-the-same-back-when-login-is-successful-in-callback-or-in-saml-response?language=en_US suggests using the RelayState
query param to pass the tc-csrf-token
around, and it should get echo'd back to TC on a successful login...
Though looking through the history here, I found https://github.com/morincer/teamcity-plugin-saml/pull/48 which added support for this already, so not sure what's going on here...
Yes, the support for this stuff is already implemented. Do you have the "SAML Callback CORS Filer Exception" enabled in your settings? If yes - I guess it might be again an issue with URL behind LB. Anyway, enable debug-auth logging preset (or even better - my brand new SAML logging preset) and attach teamcity-auth.log file.
@morincer So yeh, the Filter exception is enabled.
Attached is a relevant log extract. teamcity-auth.log
LMK if need anymore info.
Thanks
Do you have full auth debug enabled? I don't see Csrf filter-related message - but it's configured to send debug messages even when it's disabled https://github.com/morincer/teamcity-plugin-saml/blob/master/saml-authentication-server/src/main/java/jetbrains/buildServer/web/SamlCsrfCheck.java
My bad, looks like I messed something up there...
Updated log attached: teamcity-auth-cors.log
I see that the callback URL configured is https://ci.elastic.dev/app/saml/callback but it should be https://ci.elastic.dev/app/saml/callback/ (with trailing slash) - that's causing custom CORS filter to not understand the destination path. Would you please try with a valid trailing slash? And also - did you get the callback URL without slash from somewhere in UI or metadata or it was just a copy-paste typo?
Meanwhile I will make the filter slash-agnostic
Wow, the devil really is in the detail there...
Yeh, looks like a typo on my part when transferring into to setup request.
Value tweaked and logged straight in...
Sorry for the noise... 😏
The devil is in the fact that URL manipulations are always painful or at least I don't know a good small Java library for this :) Anyway, hope my fix closes the issue for future generations (however I don't know if the SAML strict mode would get exhausted for the URL differences)
So I've just updated our dev server to
2020.1.3
, and was presented with the following error:It looks like a new feature was added in
2020.1.3
- TW-49672 which now requires the use of atc-csrf-token
param or aX-TC-CSRF-Token
header.Will be digging into possibly fixes shortly, but wanted to raise issue for awareness...