Share all details about your problem, including any error messages you may have received.
We are upgrading from IIQ 8.1p2 and have SAML auth working as expected in 8.1p2, but using the same settings as we upgrade to 8.5, the session times out after 5 minutes (the sticky session time on our load balancer). Are there any new configurations that we need to change with 8.5?
We are containerizing version 8.5 and running it via podman - just one container per host, very basic, if there is anything helpful that this may be causing.
Hi @daniel_burtenshaw, are you getting issues with your IDP (identity provider), here service provider is SailPoint identity iq. were there any SAML SSO configurations settings changed when you upgraded to 8.5 ?
Hi @daniel_burtenshaw -
Basically, the jump from 8.1 to 8.5 changed how SailPoint handles “handoffs” between your Load Balancer and the application.
Here is the breakdown of what’s happening:
The “5-Minute” Conflict
Your Load Balancer is currently set to a 5-minute “sticky session.” This means it only guarantees a user will stay connected to the same container for 5 minutes. In version 8.1, if a user got moved to a different container after those 5 minutes, SailPoint was more relaxed—as long as the user had a valid SAML token, it would usually let them stay logged in.
I assumes With version 8.5, SailPoint introduced IIQSR-879. This was meant to be a feature to stop users from losing their work, but it made the application much more “sensitive” to session changes.
Now, when your Load Balancer hits that 5-minute limit and moves a user to a different Podman container, version 8.5 notices that the session ID doesn’t match the new host. It tries to “fix” the session using the SAML persistence logic, but since your containers are isolated (basic Podman setup), the new container has no idea who that user is. Instead of a seamless transition, it sees a security mismatch and kills the session.
Why Containerization Matters
Because you are running a “basic” Podman setup (one container per host), these containers are like islands—they don’t share a memory bank.
In 8.1: The “island” didn’t mind if a visitor showed up with a valid SAML pass.
In 8.5: The “island” is suspicious. If the Load Balancer drops the connection and moves the user to a new island, 8.5 sees it as a session break and triggers a timeout to be safe.
The Fix
The easiest way to resolve this is to stop the Load Balancer from moving users so quickly.
Increase LB Stickiness: Change your Load Balancer timeout from 5 minutes to at least 30 or 60 minutes. This ensures the user stays on the same container for their entire session.
Cookie Alignment: You need to tell the 8.5 containers to use modern cookie settings (SameSite) so the browser doesn’t “lose” the session cookie during the SAML redirect.
@amit_1140 thank you for your detailed reply - that does make sense why it is behaving differently.
We have tried different sameSiteCookie settings in the tomcat config with no change in behavior, we have also tried moving the session store to replicated storage (memcached, using memcached session manager in tomcat) as that was a recommendation we found online, but we have not had success with that either.
Our load balancer team does not want to increase the stickiness time, so that is not an option for us either.
Do you have any recommendations for any other changes that will help us make this work with IIQ 8.5?”
Hi @vinnysail , thanks for the reply, no issues with the IdP and no SAML SSO config changes on the IdP or within IIQ, just using the same config as 8.1p2 with 8.5.
Could you try to add below entry in SystemConfiguration.xml file .
Go to the Debug Page > SystemConfiguration. Add the below entry
<entry key="noIdpSameSiteNone" value="true"/>
This prevents IIQ from enforcing a “Lax” or “Strict” cookie policy that would cause the browser to drop the session cookie when the request comes from the SAML redirect or a different LB node.
Hi @amit_1140 , yes, we already had that set before we tried any other tomcat or other configs. We were hoping it would be as easy as that, but doesn’t seem to be for us.
