This is especially inconvenient for Non-SAML users. A SAML session is valid for 12 hours, so this problem is delayed. But a UMC session is valid only 10 minutes by default. After these 10 minutes, a login dialog is shown to the user. If this user is no UMC user, but just logged in to the portal to see the tiles, this dialog should not be shown. Maybe session-timeout could reset the session timeout? Maybe if {"reset": true} is sent? SAML sessions may or may not be fixed here.
(In reply to Dirk Wiesenthal from comment #0) > This is especially inconvenient for Non-SAML users. > > A SAML session is valid for 12 hours, so this problem is delayed. > > But a UMC session is valid only 10 minutes by default. After these 10 > minutes, a login dialog is shown to the user. management/univention-management-console/debian/univention-management-console-web-server.postinst: 67 univention-config-registry set \ 68 » umc/http/session/timeout?28800 \ By default the regular session timeout is also set to 8 hours.
I propose the following: The LoginButton does not use session-info during startup. No timer is added that would show any login dialog. No login dialog is shown after a session expires. Whether or not you are logged in is decided via cookie.get('UMCUsername'). But: Clicking on the button is doing the session-info call. If this yields something different from what the button expected (i.e. the session is unknown although the user should have been logged in and vice versa), the button just changes its state and that's it. If it yields what the button expected (i.e. the session is now unknown as it was at the beginning), the normal flow continues (i.e. redirect to the login page). This would not only reduce load on the system (fewer requests, maybe no UMC request at all for that session) but also prevent some bugs with session handling. (Bug #52314, I suppose?)
(In reply to Dirk Wiesenthal from comment #2) > Whether or not you are logged in is decided via cookie.get('UMCUsername'). That's not possible. The cookie is also set explicitly for user not being logged in. I think the initial session-info request is ok?
This is also a problem for single logout (SLO). As long as you still have a session at the UMC the SLO is started when clicking on logout. After the session timed out, the UMC just assumes you are already logged out and does not start the SLO.
(In reply to Jürn Brodersen from comment #6) > This is also a problem for single logout (SLO). As long as you still have a > session at the UMC the SLO is started when clicking on logout. After the > session timed out, the UMC just assumes you are already logged out and does > not start the SLO. Jürn, thank you so much for figuring that out. I didn't understood why the logout sometimes isn't triggered. Do you experience the same behaviour that the portal despite no logout being triggered still renders the "logged out" view of the portal (in our case it's just a "login" tile). But just hitting F5 loads the logged in status afterwards. This makes it especially dangerous as the user will assume to be logged out successfully in the first place.
The expected behaviour for SSO logged in UCS users (no matter of the UCS component that is being used by the user) is as follows: Any "local" (UCS only) session must adhere to the leading SSO session by - being valid as long as the SSO session is valid, - being invalidated when a [backchannel or frontchannel] logout for the SSO session is received, - being invalidated within a short timeframe after the SSO session got invalidated (e.g. due to IdP idle timeout), - invalidating the SSO session if an explicit logout request is trigged by the user. That probably goes beyond the bug described here, but may be important for an overall view on the topic and also for testing the software once the bug is resolved.
We've had a chat with Florian about it. The bug should be fixed by reimplementing the Dojo/UMC Sessionmanagement-Features - Passiver IFrame SAML Login (../sessioninfo) - "checkSession"-functionality (checks 30sec before session expires its validity)
*** Bug 56487 has been marked as a duplicate of this bug. ***