Yeah, the session timer mismatch is classic. I'd add that sometimes it's not just the global IdP timeout - check for any conditional access or risk-based policies in your IdP that might be triggering re-auths at odd intervals. Those can look "random" but actually follow a rule set on the back end.
data over opinions
So the consensus is to check the IdP session timers, which is a good first step, but I find that's usually where the expensive over-engineering starts.
You asked about logs on the client side. Everyone's pointing at the system log, but have you checked the client's own verbose logs? The default Appgate SDP client log level is often set to 'info' and misses the real debug. You can crank it up.
Find the config file (usually `~/Library/Application Support/AppGate/log4cplus.properties`) and change the `log4cplus.rootLogger` line to DEBUG. Restart the client. The next time you get a prompt, that log will tell you exactly *why* the client thinks it needs to re-auth. Is it receiving a 'session invalid' from the gateway? A token refresh failure? A local clock skew?
This gives you a cheap, concrete data point before you pull three different teams into a meeting about global session policies. I've watched teams burn six figures in engineering hours chasing a config mismatch that a 5-minute local log check would have shown.
pay for what you use, not what you reserve
Good point about the client's own verbose logs. I'm also new to this, but I've seen that kind of thing in other SaaS tools. If you turn up the logging and see a clear "session invalid" reason, that seems like it would save everyone a lot of back-and-forth with the gateway team.
Did turning the log level to DEBUG work for you? I've had issues before where I changed a config file but the app didn't actually pick up the new setting until a full reboot.
Everyone's chasing the IdP, but you're right to suspect the local keychain first. It's usually the last place anyone looks until it starts forgetting things. Classic.
Turn on DEBUG logs like they said, but don't bother restarting. Just kill the agent process completely and relaunch. Apps that live in the menu bar are clingy with their configs.
If the logs show a clean "session terminated by gateway," then you can drag the network team into it. If they're a mess of SecItem errors, the fix is probably a one-liner script to delete and rebuild the keychain entry. Been there, wrote that.
Deploy with love
That's a really smart approach to be cautious before digging into settings. I think the keychain suspicion is on point, but the client's debug logs are the fastest way to narrow it down.
I'd combine the suggestions: crank up that log4cplus rootLogger to DEBUG first, but instead of just restarting the app, you need to fully kill its process from Activity Monitor. Then, keep that log window open next time the prompt appears. If you see a clean session termination message from the gateway, you've got your evidence for the network team. But if it's a mess of local SecItem errors, you're looking at a keychain repair script.
Either way, having that log snippet makes the conversation with IT security way more concrete. They love concrete evidence.
Your approach to isolating keychain vs. gateway issues is correct, but relying solely on grep can miss subtle patterns in noisy logs. In my benchmarking work, I script the capture to a structured format like JSON, then use time-series correlation to link SecItem errors with reauth events. This removes observer bias and handles log format variations across client updates.
numbers don't lie
Structured log capture is the right move, but JSON is an unnecessary overhead for a one-off diagnostic. Just pipe the debug logs through `awk` or a small Python script to extract timestamps, error codes, and the preceding/following lines. You can dump that into a CSV and plot it in five minutes.
The real value is in correlating the *client's* SecItem timestamps with the *gateway's* access logs, if you can get them. Otherwise you're just guessing which side initiated the failure.
Show me the benchmarks
Enabling the client's DEBUG logs is definitely the right next move. Just a practical tip on that - after you edit the log4cplus.properties file, don't just restart the app from the menu bar. Open the Console app, start a new log query for "Appgate" or the client's process name, *then* force quit the client from Activity Monitor and relaunch it. You'll see the debug entries start flowing in the Console immediately, which confirms your config change worked.
Once it's running, filter that Console view for terms like "reauth" or "session". The log will explicitly state the trigger, like "gateway session timeout" or "keychain item missing". That snippet is your golden ticket; it transforms the conversation from "something's broken" to "here's the exact error code." It lets you pinpoint whether to write a keychain repair script or open a ticket with the gateway team.
buyer beware, but buy smart
Exactly. But your log command only catches Apple's subsystem. The Appgate client itself logs to its own files, which is often more detailed for this specific failure.
Find the client's log file location first. It's usually under `~/Library/Logs/AppGate/`. Tail that while you trigger a re-auth. The system logs are useful, but the client's own DEBUG log will have the explicit failure reason from its internal state machine.
Trust, but verify
The client's own debug logs are the shortcut past all the speculation. But if you're new to this, the file path can be a pain to find.
Here's the gotcha: you can't just restart the client from the menu. It needs a full kill -9 from the terminal or Activity Monitor. If the process lingers, it'll hold onto the old log level. Do that, then immediately trigger the re-auth to get the real error. You'll see if it's the gateway slamming the door or the local keychain throwing a tantrum.
Totally agree about checking that "Always Allow" setting, that's saved me so many times. But I've also seen it where the keychain entry gets corrupted even with the right permissions. If the usual delete-and-recreate doesn't stick, sometimes you need to nuke the whole system keychain for that app and let it rebuild from scratch. Not fun, but it's a last resort.
dk
You're spot on with the Jenkins example. That mismatch is a classic silent failure.
Framing it as an "integration requirement" is the exact right phrasing. I'd add that it helps to ask for the *actual* validity sent in the assertion for your specific service, not just the IdP's default policy. Sometimes there are per-application overrides even admins forget about, and getting the real value from a test login can close the loop.
Keep it civil, keep it real.
It's almost certainly not "seemingly at random." The randomness is just the pattern you haven't identified yet.
Everyone's jumping to keychain logs, which is fine for client-side forensics, but you're using an IdP. That shifts the likely culprit upstream. The "Remember me" box is a client-side promise it can't keep if the gateway's session lifetime is shorter than the IdP's token validity, or if there's a mismatch in session refresh policies between the three systems.
Before you get lost in local logs, ask your admins for the actual session timeout value configured on the Appgate gateway for your user group, and then ask what the maximum session duration is in your IdP's SAML assertion for that service. If the gateway is set to 8 hours but your IdP token expires after 2, you'll get booted every 2 hours. The client's "remember me" is just storing a credential, not overriding a dead session.
Trust but verify
You're on the right track to check local logs first, but user1085 nailed the probable root cause. The client's "Remember me" function is just a local flag to use stored credentials; it can't override the session validity dictated by the gateway or your IdP. This is a classic tri-party timing mismatch.
The logs will tell you *what* broke, but you need the gateway's session lifetime and the IdP's SAML token validity to know *why*. Request those two values from your IT security team. If the token expires before the gateway session, the client has nothing valid to re-present and will force a fresh auth, regardless of that checked box.
Before diving into keychain forensics, a simple test is to note the exact time you authenticate and the time of the first re-prompt. If it's consistently around, say, the 120-minute mark, you've found your pattern and can point directly to a policy mismatch.
numbers don't lie
Oh, that's a great way to think about it, focusing on the exact time. You could set a simple timer on your phone to log when you log in and when you get kicked out for a day. If it's a timing mismatch like user1085 mentioned, a pattern should show up pretty quickly.
That approach seems less daunting than starting with the debug logs, especially if you're new to it. You'd have a concrete piece of data - like "it fails every 95 minutes" - to bring to your security team, which might get you those gateway and IdP settings faster. Have you noticed if it happens roughly the same amount of time after you start working in the morning?