> Could the assertion be retained in the cache until the SessionNotOnOrAfter > time is reached?
Yes, but that will be a dev for SOGo 6 đ Cheers, -- Quentin Hivert || Alinto || R&D Lead Developer 19 Quai Perrache 69002 Lyon <http://www.alinto.com> www.alinto.com From: [email protected] <[email protected]> On Behalf Of "sysadminyyoy" Sent: samedi 5 juillet 2025 02:04 To: [email protected] Subject: [SOGo] [SPAM] RE: session timeout after approx 5min Hi, thank you for this excellent information. You are correct, changing SOGoCacheCleanupInterval changed the timeout behaviour - in this case I set it to 900 (seconds) which resulted in 15min of editing a draft message before the timeout occurred. I am not particularly familiar with either SAML2 or CAS but I note in my SAML2 assertions that there is a âSessionNotOnOrAfterâ value (snippet below). <saml:AuthnStatement AuthnInstant="2025-07-04T23:25:41.918Z" SessionIndex="e0c46040-4129-469e-bd48-88675f0eab34::d244438a-637a-4740-9635-98d656179c91" SessionNotOnOrAfter="2025-07-05T09:25:41.918Z"> <saml:AuthnContext> <saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified</saml:AuthnContextClassRef> </saml:AuthnContext> </saml:AuthnStatement> This appears to be controlled by the Keycloak parameter âSSO Session Maxâ which has description âMax time before a session is expired. Tokens and browser sessions are invalidated when a session is expired.â I have this set to 10 hours which corresponds to the date/time values provided in the assertion. Could the assertion be retained in the cache until the SessionNotOnOrAfter time is reached? Thankyou again for the advice! Mark. -------- Original Message -------- Subject: RE: [SOGo] session timeout after approx 5min Date: Thursday, July 03, 2025 22:42 ACST From: "qhivert" ([email protected] <mailto:[email protected]> ) <[email protected] <mailto:[email protected]> > Reply-To: [email protected] <mailto:[email protected]> To: <[email protected] <mailto:[email protected]> > References: <806-68667780-37-3ed8f300@107794680> Hello, I donât know much about saml2 but after a quick glance at the specs it seems this is the same problem as with CAS. If Iâm wrong about smal2/cas protocol, please tell me! What I find strange with those protocol, it is that after the first connection, there is no way for SOGo to check if the user is still valid. SOGo receives a SAML assertion and itâs up to SOGo to decide when it will be expired. Whereas with openID, SOGo can request the openID server to check if the token is not expired and get the user information. SOGo even can refresh the user token without any interaction from them. For saml2 and CAS, what SOGo does is to store de SAML assertion/cas ticket into the cache. When the cache expires, the user is redirected to their IdP again. The error you see is because the key session store in your cookie is used to fetch the data from the cache, but being empty, it fails. The 5 minutes directly comes from the parameter SOGoCacheCleanupInterval which is 300 (seconds) by default. These parameters tell how long a data is stored in the cache. You could try to set it at 360 to see if it stands for 6 minutes instead of 5 now. Regards, -- Quentin Hivert || Alinto || R&D Lead Developer 19 Quai Perrache 69002 Lyon <http://www.alinto.com> www.alinto.com From: [email protected] <mailto:[email protected]> <[email protected] <mailto:[email protected]> > On Behalf Of "sysadminyyoy" Sent: jeudi 3 juillet 2025 14:29 To: [email protected] <mailto:[email protected]> Subject: [SOGo] [SPAM] session timeout after approx 5min Hi SOGo user list. Hoping for guidance please. SOGo 5.12.2 (upgraded from 5.8.0 or so) configured with SAML via Keycloak 26.2.4. MariaDB 11.8.2 Broadly speaking everything works very well. However I am experiencing sogo web session timeout consistently approx 5min after login (not aligned with cron execution). As the session is still valid in Keycloak it drops to Keycloak then immediately returns to the SOGo web interface with only a small (500ms) delay. However if the user is in the middle of drafting an email any edits since the last autosave are lost and the draft is closed and needs to be reopened to continue. Autosave is set to 1min to mitigate. I have confirmed that sogo_sessions_folder table in MariaDB is being populated. Structure is: > describe sogo_sessions_folder; +----------------+--------------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +----------------+--------------+------+-----+---------+-------+ | c_id | varchar(255) | NO | PRI | NULL | | | c_value | text | YES | | NULL | | | c_creationdate | int(11) | NO | | NULL | | | c_lastseen | int(11) | NO | | NULL | | +----------------+--------------+------+-----+---------+-------+ 4 rows in set (0.001 sec) Session timeout is not aligned to cron job executions. In the instant before timeout the sogo_sessions_folder session is updated with the new âlastseenâ value however on return from keycloak a new session is written into the database and the old session(s) is eventually expired. The log file shows the following: 2025-07-02 14:53:07.043 sogod[869523:869523] <MySQL4Channel[0x0x5644342e0620] connection=0x0x5644344ab160> SQL: SELECT t1.c_creationdate, t1.c_id, t1.c_lastseen, t1.c_value FROM sogo_sessions_folder t1 WHERE t1.c_id='REDACTED'; 2025-07-02 14:53:07.043 sogod[869523:869523] <MySQL4Channel[0x0x5644342e0620] connection=0x0x5644344ab160> query has results, entering fetch-mode. 2025-07-02 14:53:07.043 sogod[869523:869523] <MySQL4Channel[0x0x5644342e0620] connection=0x0x5644344ab160> SQL: ROLLBACK; 2025-07-02 14:53:07.044 sogod[869523:869523] <MySQL4Channel[0x0x5644342e0620] connection=0x0x5644344ab160> query has no results. 2025-07-02 14:53:07.044 sogod[869523:869523] <MySQL4Channel[0x0x56443414c950] connection=0x0x5644340a4be0> SQL: BEGIN; 2025-07-02 14:53:07.044 sogod[869523:869523] <MySQL4Channel[0x0x56443414c950] connection=0x0x5644340a4be0> query has no results. 2025-07-02 14:53:07.044 sogod[869523:869523] <MySQL4Channel[0x0x56443414c950] connection=0x0x5644340a4be0> SQL: UPDATE sogo_sessions_folder SET c_lastseen = 1751433787, c_creationdate = 1751433457, c_value = 'VERY_LONG_REDACTED_TOKEN', c_id = 'REDACTED' WHERE c_id='REDACTED'; 2025-07-02 14:53:07.045 sogod[869523:869523] <MySQL4Channel[0x0x56443414c950] connection=0x0x5644340a4be0> query has no results. 2025-07-02 14:53:07.045 sogod[869523:869523] <MySQL4Channel[0x0x56443414c950] connection=0x0x5644340a4be0> SQL: COMMIT; 2025-07-02 14:53:07.047 sogod[869523:869523] <MySQL4Channel[0x0x56443414c950] connection=0x0x5644340a4be0> query has no results. Jul 02 14:53:07 sogod [869523]: <0x0x5644339a4b70[SOGoWebAuthenticator]> tried wrong password for user 'VERY_LONG_REDACTED_TOKEN_WITH_63_LEADING_CHARACTERS_CHANGED'! The 'VERY_LONG_REDACTED_TOKEN' from the SQL UPDATE is the value from the c_value field in the sogo_sessions_folder table. I haven't been able to decode what the meaning of the 63 changed leading characters in the 'user' attempt toward SOGoWebAuthenticator represents but only the leading 63 characters (out of some 600++) are altered. The "tried wrong password for user" has been the focus of my diagnostic effort. In this context (https://github.com/Alinto/sope/blob/master/sope-appserver/NGObjWeb/SoObjects/SoCookieAuthenticator.m#L255) I believe this refers to session details stored in the cookie file. If I open a draft immediately on login I can see via detailed logging that the cookie details succeed the first 4 authentication checks (it appears a check is undertaken as a test immediately prior to autosave). On the 5th attempt / 5 minutes the identical check appears to fail with the error message above âtried wrong password for userâ. The c_id changes from one login session to the next but not within a single login session as far as I can tell. Altering various session timeout / token validity periods within Keycloak has no impact at all. I am also getting the following two errors which may be related and are included for completeness: (process:1035072): Lasso-CRITICAL **: 23:41:45.860: 2025-07-02 23:41:45 (profile.c/:913) Trying to unref a non GObject pointer file=profile.c:913 pointerbybname=profile->identity pointer=0x55556efe2b30 (process:1035072): Lasso-CRITICAL **: 23:41:45.860: 2025-07-02 23:41:45 (profile.c/:916) Trying to unref a non GObject pointer file=profile.c:916 pointerbybname=profile->session pointer=0x55556ec0b210 I tried SOGoTrustProxyAuthentication = YES; but no change in behaviour. I have SOGoXSRFValidationEnabled = YES; Any advice would be greatly appreciated. Mark.
