Univention Bugzilla – Bug 39233
UMC session timeout in SAML sessions
Last modified: 2015-11-17 12:11:46 CET
With the new SAML UMC login we are using SAML assertions for the authentication against PAM or SASL. SAML messages contain time restrictions for the validity of the message, for example: <saml:Conditions NotBefore="2015-08-14T15:05:42Z" NotOnOrAfter="2015-08-14T15:11:12Z"> We have to adjust the session timeout and relogin handling so that these limits do not make conflicts.
The current validity of a SAML message is 5 minutes. During authentication there is a grace time of 10 minutes. We need a way to renew the assertion every 15 minutes. This can be implemented via a HTTP redirect but we must keep the tab as is. So I hope it is possible via AJAX.
grace time is now configurable via the UCR variable umc/saml/grace_time: univention-management-console (8.0.10-1): r63499 | Bug #39233: implement UCR variable umc/saml/grace_time univention-management-console-frontend (5.0.20-1): r63499 | Bug #39233: implement UCR variable umc/saml/grace_time
Introduced side effect which occurs when the UMC server closed the connection and the client/browser makes a request causing the UMC-Webserver to hang: Traceback (most recent call last): File "/usr/sbin/univention-management-console-web-server", line 86, in _decorated return func(*args, **kwargs) File "/usr/sbin/univention-management-console-web-server", line 315, in check_queue client.authenticate_user(queuerequest.request, queuerequest.response_queue) File "/usr/sbin/univention-management-console-web-server", line 182, in authenticate_user self.client.authenticate(request) File "/usr/lib/pymodules/python2.7/univention/management/console/protocol/client.py", line 370, in authenticate self.request(msg) File "/usr/lib/pymodules/python2.7/univention/management/console/protocol/client.py", line 279, in request if self._resend(sock): File "/usr/lib/pymodules/python2.7/univention/management/console/protocol/client.py", line 198, in _resend bytessent = sock.send(data) AttributeError: 'NoneType' object has no attribute 'send'
The SAML assertion is now renewed in the background. If this fails the regular login dialog is shown.
I'm not sure if these changes are the reason but if I reduce the umc/http/session/timeout to 60 seconds, login via username and password and the session expired after 60 seconds, I can simply press F5 and I'm logged in again.
(In reply to Stefan Gohmann from comment #5) > I'm not sure if these changes are the reason but if I reduce the > umc/http/session/timeout to 60 seconds, login via username and password and > the session expired after 60 seconds, I can simply press F5 and I'm logged > in again. For SAML sessions the lifetime of the assertion is used as session timeout. If you make a page reload then you get automatically logged in - except the IDP session is also expired (e.g. if you remove cookies over there). At the identity provider you are regulary still logged in, the session get's automatically renewed in the background if it times out - except you explicitly logout/remove cookies at the IDP. If I would trigger a logout at the IDP on session timeout you would also be logged out from every other UMC session (e.g. on the Slave). I think we shouldn't do this?!
(In reply to Florian Best from comment #6) > (In reply to Stefan Gohmann from comment #5) > > I'm not sure if these changes are the reason but if I reduce the > > umc/http/session/timeout to 60 seconds, login via username and password and > > the session expired after 60 seconds, I can simply press F5 and I'm logged > > in again. > For SAML sessions the lifetime of the assertion is used as session timeout. > If you make a page reload then you get automatically logged in - except the > IDP session is also expired (e.g. if you remove cookies over there). > At the identity provider you are regulary still logged in, the session get's > automatically renewed in the background if it times out - except you > explicitly logout/remove cookies at the IDP. > > If I would trigger a logout at the IDP on session timeout you would also be > logged out from every other UMC session (e.g. on the Slave). I think we > shouldn't do this?! I didn't use SAML. But I did not restart the UMC web server after changing the UCR variable. After restarting the UMC web server, it worked like expected.
currently, after the frontend session times out, the normal login window appears. As discussed, we should check if the SAML Session is still valid with the idp.
(In reply to Erik Damrose from comment #8) > currently, after the frontend session times out, the normal login window > appears. As discussed, we should check if the SAML Session is still valid > with the idp. The frontend side session timeout has been adapted to check the session every 30 seconds. If logged in via SAML it (tries to) renew the session automatically.
(In reply to Florian Best from comment #9) > If logged in via SAML it (tries to) renew the session automatically. What could cause the session renewal to fail? I currently see the following: * Login to UMC via saml * Every few minutes, a request is done to the simplesamlphp page, spawning a php-cgi script * The session does not seem to be renewed: If i do an action (try to add user) in UMC after more than 10 minutes of idling, i get the UMC login windows with the 'Session-Timeout' message -> Reopen. I repeated my test several times
(In reply to Erik Damrose from comment #10) > (In reply to Florian Best from comment #9) > > If logged in via SAML it (tries to) renew the session automatically. > > What could cause the session renewal to fail? I currently see the following: The session renewal can fail if the memcached gets restarted or the IDP-server is not reachable or if you locally remove the cookies for the IDP or if the 8 hours session validity is expired. > * Login to UMC via saml > * Every few minutes, a request is done to the simplesamlphp page, spawning a > php-cgi script > * The session does not seem to be renewed: If i do an action (try to add > user) in UMC after more than 10 minutes of idling, i get the UMC login > windows with the 'Session-Timeout' message -> Reopen. I repeated my test > several times Maybe this was a race condition. I could trigger some error by restarting the univention-management-console-web-server during being logged in which caused to pop up a login dialog. Fixed this in svn r65316.
The current version fixes the issue. A request to templates caused the problem, which was fixed by your change. Verified
I fixed another typo + ignore every error != 401 when checking the session to prevent login dialogs if the old UCS 4.0 webserver still runs and if the UMC-server is not reachable in some update scenarios.
UCS 4.1 has been released: https://docs.software-univention.de/release-notes-4.1-0-en.html https://docs.software-univention.de/release-notes-4.1-0-de.html If this error occurs again, please use "Clone This Bug".