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] <[email protected]> On Behalf Of "sysadminyyoy" Sent: jeudi 3 juillet 2025 14:29 To: [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.
