Univention Bugzilla – Bug 44217
Login redirection loop
Last modified: 2017-06-15 17:58:07 CEST
A partner added 10.200.18.12 myucs ucs-6529.foo.intranet ucs-sso.foo.intranet to /etc/hosts on local client. When trying to connect to https://myucs/umc/ there is a redirection loop between several login pages. If https://ucs-6529.foo.intranet/… is used, there is no problem. Could this lead to problems if additional CNAMEs/A/AAAA records are used for UCS systems that are e.g. located in a DMZ?
The affected system has been updated from UCS 4.1 to UCS 4.2.
The problem might also be an effect of ongoing 4.2 development. I experienced a similar issue as my browser had cached some JS code which had been adapted some time between RC and final release.
Is slapd, stunnel and memcache correctly running?
*** Bug 44453 has been marked as a duplicate of this bug. ***
(In reply to Florian Best from comment #4) > *** Bug 44453 has been marked as a duplicate of this bug. *** For me Bug #44453 is part of the setup process, so I'll increase the importance.
Created attachment 8802 [details] Screenshot Yes, the reason is that the hostname is not the FQDN or IP of the service provider. The "X-Frame-Options" header only allows SAMEORIGIN. The origin of "localhost" is then different to the FQDN of the service provider. This causes that the iframe for background-passive-authentication is not displayed. In chromium it works when unsetting X-Frame-Options explicit for /univention/saml/. In firefox this doesn't work: In the screenshot one can see that a request to https://localhost/saml/ is done. Then the single sign on at the IDP is done (SSOService.php) then there is a redirection to the FQDN(!) of the service provider. After the /auth/sso call one is redirected back to "localhost". This happens only in firefox somehow. But this cannot work because the Cookies are stored for the FQDN and not for "localhost".
(In reply to Florian Best from comment #6) > Created attachment 8802 [details] > Screenshot > > Yes, the reason is that the hostname is not the FQDN or IP of the service > provider. > > The "X-Frame-Options" header only allows SAMEORIGIN. The origin of > "localhost" is then different to the FQDN of the service provider. This > causes that the iframe for background-passive-authentication is not > displayed. > In chromium it works when unsetting X-Frame-Options explicit for > /univention/saml/. The X-Frame-Options can be ignored because it only refuses the iframe to be displayed but the redirection inside of it still works. > In firefox this doesn't work: > In the screenshot one can see that a request to https://localhost/saml/ is > done. Then the single sign on at the IDP is done (SSOService.php) then there > is a redirection to the FQDN(!) of the service provider. After the /auth/sso > call one is redirected back to "localhost". This happens only in firefox > somehow. But this cannot work because the Cookies are stored for the FQDN > and not for "localhost". The handling of redirecting the user back to the location where she came from has been fixed so that the correct URL of the service provider is now used instead. univention-management-console.yaml: r79015 | YAML Bug #44217 Bug #44450 Bug #43859 univention-management-console (9.0.80-5): r79013 | Bug #44450: Bug #44217: fix errors during SAML login
Seems to work great. -> Verified
<http://errata.software-univention.de/ucs/4.2/40.html>