Our operators are experiencing major disruption in the shop floor control module (GPSF 2022.2) due to SSO session timeouts. They’re being forced to re-authenticate in the middle of production runs, which is causing incomplete transactions and data loss.
We implemented SAML SSO with Okta three months ago, and the IdP session timeout is set to 8 hours. However, operators are getting kicked out after what seems like 30-60 minutes of activity. When they click back into the SFC interface, they see:
Session expired. Please re-authenticate.
SAML assertion invalid: NotOnOrAfter condition failed
Redirecting to IdP login...
The problem is that production runs can last 2-4 hours continuously, and operators need to maintain their session throughout. We’ve checked the IdP configuration and it’s definitely set to 8 hours. This suggests there’s a mismatch between the IdP session timeout and GPSF’s local session configuration, but we can’t figure out where GPSF is enforcing the shorter timeout.
The operator workflow impact is severe - they lose context on multi-step processes and have to restart data entry. Has anyone successfully aligned session timeout settings between their IdP and GPSF shop floor control?
Priya, that sounds like the approach we need. Can you share the specific configuration settings you used for the web application session and the assertion refresh? We’re running GPSF on Tomcat 9 if that matters for the session configuration.
The NotOnOrAfter condition in SAML assertions is separate from the IdP session timeout. Your IdP might have an 8-hour session, but the SAML assertion itself has a validity window that’s typically much shorter (5-10 minutes by default). GPSF validates this assertion timestamp, and if it’s expired, forces re-authentication even if the IdP session is still active.
Check your Okta application settings for the SAML assertion validity period. It’s probably set to a very short window for security reasons.
Maria, I checked Okta and the SAML assertion timeout is set to 5 minutes. That would explain the issue. But if we extend that to match our 8-hour requirement, won’t that create a security risk? Is there a way to configure GPSF to refresh the assertion in the background without forcing operators to re-authenticate?
You don’t want to extend the SAML assertion to 8 hours - that defeats the purpose of SSO security. The correct approach is to configure GPSF to handle assertion refresh transparently. GPSF 2022.2 supports silent re-authentication where it requests a new SAML assertion from the IdP without user interaction, as long as the IdP session is still valid.
The key is in the web.xml session configuration and the SAML SP settings. You need to enable the assertion refresh mechanism and set appropriate session timeouts that work together. I can walk you through the configuration if you have access to the application server settings.