I am not sure if this a bug or a misconfiguration on my side: When I log in to the Univention portal via Keycloak (SAML), the session seems to expire after 5 minutes. The portal page reloads and I am brought back to the login tiles. When I click the SSO tile again, I am logged in without entering my credentials again, so the IdP session still persists. 5 minutes are a default expiration time of a few things in Keycloak. It seems as if the refreshment doesn't work. The portal has to go to Keycloak and ask again explicitly. One idea is that it is related to the content security policy frame-ancestors, so I modified these settings, but to no avail: univention-app configure keycloak --set keycloak/csp/frame-ancestors=https://ucs-sso-ng.test.intranet https://portal.test.intranet" (Question: Are both needed or which one is correct?) ucr set ucs/server/sso/fqdn=ucs-sso-ng.test.intranet (for the Apache template univention-portal.conf, by default, it has ucs-sso in there) systemctl restart apache2 The apache access.log shows these requests: In contrast to the requests from my user agent these come from localhost: a successful reload of the portal: 127.0.0.1 - - [22/Oct/2024:20:09:24 +0200] "GET /univention/get/session-info HTTP/1.1" 200 485 "-" "-" a rejected one: 127.0.0.1 - - [22/Oct/2024:19:58:28 +0200] "GET /univention/get/session-info HTTP/1.1" 401 2525 "-" "-" Tested in different environments with: Customer: UCS: 5.0-8 errata1106 Installed: adconnector=12.0 keycloak=25.0.1-ucs2 ox-connector=2.2.11 self-service-backend=5.0 Upgradable: ox-connector My tests: UCS: 5.0-9 errata1140 Installed: keycloak=25.0.6-ucs1 Upgradable: UCS: 5.0-8 errata1125 Installed: keycloak=25.0.1-ucs2 nextcloud=28.0.7-0 self-service=5.0 self-service-backend=5.0 UCS: 5.0-7 errata1072 Installed: keycloak=24.0.5-ucs1 Upgradable: How to reproduce it: * Configure the portal to use Keycloak as a SAML service provider * add the above settings (or not, it doesn't seem to matter) * Log in to the portal * Reload after 5 minutes
Meanwhile I modified the Assertion Lifetime of the portal's SAML client in Keycloak. This postpones the problem. But I am still confused: What do I define with umc/saml/assertion-lifetime (discussed in https://forge.univention.org/bugzilla/show_bug.cgi?id=57642)? Is that still a relevant setting? Does autofresh work and how? Are CSP settings relevant for SAML at all?
Thanks for taking the time to reproduce this, I am sure this caused some effort. I do not want to reject your claims with "please update", but we indeed changed exactly this part of the product with erratum 1144 via Bug 57516 and it seems that your most recent 5.0-9 was just 4 errata behind that. Regarding your question to "umc/saml/assertion-lifetime": This value determines the assertion lifetime of the UMC SAML session, meaning that with increasing it you did indeed work around that by not having the UMC triggered refresh after 5min - Which is not wrong to resolve this issue. But hopefully erratum 1144 addresses the CSP site, could you check that?
The changes you mention don't have any effect on this behaviour as my portal speaks SAML, not OIDC. Thus, it is still the same with the new version, but I understand it better now: I did some more reading and testing. I think that "umc/saml/assertion-lifetime" would only be taken into account if the IdP didn't send any information in the AuthnStatement. But as the Keycloak IdP sends this (optional) piece of information (SessionNotOnOrAfter), the Keycloak setting is used. You cannot enforce a shorter time on the SP side, it is ignored. As a 5 minutes session is really short, it is confusing to the point where customers think that the SSO doesn't work properly. For me, it would be totally fine if the 5 minutes as a default configuration of the portals in Keycloak and the advice where to adapt it, were in our documentation.
I talked to two more customers who also observed the weirdness of this setting: Please have a look at the "inst" script of the Keycloak app. In there, it looks as if the value of "umc/saml/assertion-lifetime" was written into the SAML SP client configuration after the app installation and initial creation of the UMC client (line 237-238). But it isn't: I can change the ucr variable on a new machine, then install keycloak, check the client settings of the UMC, it stays at 300 seconds. Steps to reproduce this: # univention-app info UCS: 5.0-9 errata1149 Installed: Upgradable: ucr set umc/saml/assertion-lifetime=36000 univention-app install keycloak Log in to Keycloak -> Clients -> UMC -> Tab "Advanced" -> Advanced settings / Assertion Lifetime.
(In reply to Silke Meyer from comment #1) > Meanwhile I modified the Assertion Lifetime of the portal's SAML client in > Keycloak. This postpones the problem. But I am still confused: What do I > define with umc/saml/assertion-lifetime (discussed in > https://forge.univention.org/bugzilla/show_bug.cgi?id=57642)? Is that still > a relevant setting? Yes, it's still relevant. > Does autofresh work and how? Are CSP settings relevant for SAML at all? Yes, CSP is very relevant. Wrong settings in there break the iframe auto relogin. (In reply to Silke Meyer from comment #4) > Please have a look at the "inst" script of the Keycloak app. In there, it > looks as if the value of "umc/saml/assertion-lifetime" was written into the > SAML SP client configuration after the app installation and initial creation > of the UMC client (line 237-238). > > But it isn't: I can change the ucr variable on a new machine, then install > keycloak, check the client settings of the UMC, it stays at 300 seconds. It could be broken since git:25c8326742a865851b8b59b3685b814dfe14e16b.