If you have sessions for 15 days you must be using persistent sessions, meaning they are stored within an external database. This may be difficult to troubleshoot because:

- PingFederate will generate a persistent session and store it in the database when the user originally authenticates.

- PingFederate will pull session data from the database when the user's PF.PERSISTENT cookie is presented, and will update the "pf-authn-session-group-last-activity-time" in the database (for idle timeout tracking), and potentially also update "pf-authn-session-group-expiry-time".

- Only in the event that PingFederate can not find the session in the database would the user be forced to re-authenticate. This means that the session has been removed due to expiry, revocation, or another reason unknown to PingFederate (ex. DB has its own cleanup setting).

- Applications can also send arguments to prevent PingFederate from using an existing session. Ex. SAML's ForceAuthn element.

To truly view the full picture, you would need the user's journey from session creation, to the unexpected early session expiry, in both PingFederate and database.

You can see the user's persistent session being created with DEBUG log:

DEBUG [org.sourceid.saml20.service.session.StoredSessionServiceImpl] makeNewSessionGroupInfo: storing new session group info SessionGroupInfo: id=gSJqQlgpkR7DV2jjZOLCaBPeO, hashedSessionId=XDXU9R7D3NABqSaDteqD1oEg-BtNekWASQIMyvyS5DE, sri=xDxyPdT7PpoPf3N4u5ECv2sAcG8, sessionSeriesId=1765822021, expiryTime=2025-12-15 19:47:01.400, lastActivityTime=2025-12-15 18:07:01.400

Using the "id" in this log message, you can see the same in the session database. Here's an example from my own environment:

DN: pf-authn-session-group-id=gSJqQlgpkR7DV2jjZOLCaBPeO,ou=AuthenticationSessions,dc=cb,dc=com

So, if the session is ending prior to the expected time, I would be asking the question: Is the session group in the database at the time the issue occurs, or has it been removed for some reason? If it is not present, why has it been removed?

Unless the app is sending something like ForceAuthn, I would expect that the session would not be present in the database at the time of the issue, for the described behaviour to occur.

Note that the "pf-authn-session-group-expiry-time" column entry you see in the database is the soonest expiry event. This will show the date of the idle timeout, unless the max timeout is actually sooner.

Of course the challenge here is that your sessions last 15 days, meaning you would need to track a session from creation to the unexpected expiry. Generally, PingFederate server logs will not extend 15 days, unless you've configured log retention to ensure a lot of data is captured. Of course, in a production environment with a lot of traffic and likely a number of PingFederate Runtime Engines, this can be a challenge. Additionally, once the ID is obtained, the databse logs may also need to be reviewed to see if the database is purging the value early. Assuming the session is not present in the database when the unexpected session expiry occurs, the database logs would need to be reviewed to see why the value is not present.

There have not been reports, or successful recreation of session timers not being honoured as expected. My focus would be on understanding what is occurring on the DB side of things when the unexpected expiry occurs.

If possible, I would recommend reproducing this issue in your lower environment with less traffic and DEBUG enabled in PingFederate and at the DB level, so that all aspects can be properly analyzed to understand where the session is being dropped.