Please share any other relevant files that may be required (for example, logs).
[Please insert files here, otherwise delete this section]
Share all details about your problem, including any error messages you may have received.
After upgrading to IdentityIQ version 8.4p1, we’ve encountered an intermittent issue where the application enters a login loop on every page load. Our traffic routing is configured with IP-based sticky sessions, ensuring that once authentication is completed, requests should not redirect to Okta on subsequent page loads during the session.
The login loop issue you’re experiencing after upgrading to IdentityIQ version 8.4p1 may be related to session management with Okta
Session Cookies: Ensure that your application is correctly handling Okta session cookies. If third-party cookies are blocked by the browser, it can disrupt the authentication flow, causing repeated redirects to Okta.
Sticky Sessions: Verify that your IP-based sticky sessions are functioning correctly. If requests are not consistently routed to the same server instance, it can lead to authentication inconsistencies.
Session Expiry: Check if the session tokens are expiring prematurely or if there are issues with session persistence settings in your load balancer.
Okta side settings also needs to verified if any issues. Is this issue coming up in all browsers ?
I do suggest to make use of browser plugins like SAML-Tracer to gather more info when the data is pass to your application. Check also the network in the development mode (Chrome, Edge etc. have it). You need to check the loop from where to where.
Also check if your browser has also changed.
I believe reaching out the Okta support team might speed up the things for you.
If you share those data from tracers here, please make sure to not attach any sensible data like real hostnames or cookies (you know, for security reasons).
Yes, the issue is coming in all browsers. (Tried in edge, safari, mozilla).
Sticky Sessions: Verify that your IP-based sticky sessions are functioning correctly. If requests are not consistently routed to the same server instance, it can lead to authentication inconsistencies. - We checked this and this is configured properly.
Session Expiry: Check if the session tokens are expiring prematurely or if there are issues with session persistence settings in your load balancer - The session expiry is same in 8.1p5 before upgrade, so don’t think so session expiry is expiring here. Also observed the similar pattern in our QA instance which has two UI servers and two task servers.
I do suggest to make use of browser plugins like SAML-Tracer to gather more info when the data is pass to your application. Check also the network in the development mode (Chrome, Edge etc. have it). You need to check the loop from where to where.
Also check if your browser has also changed. - “I am getting this issue in every browser, also it temporary workaround is it works after restarting the browser every time”.
As @gentjan_kocaqi mentioned, need to enable saml tracer plugin in the browser to understand the flow between identity provider (okta) and the service provider (sailpoint) also enable more logs at okta end and sailpoint app server end to get more information.
If you’re using a load balancer for IIQ, I’ve always had to define a cookie name to maintain the sticky session. Otherwise clicking on any other page in IIQ would redirect to the login page.
After enabling the tracers, I noted that the page is returning 302 status and redirecting to Okta. We have two UI Servers with consistent hashing and sticky sessions enabled.
Well we do have 4 UI and 4 task. It doesn’t matter how many servers. Issue is coming across all environments. But after adding “noIdpSameSiteNone” it got resolved.
I am not sure in 8.4p1 because I haven’t test it. May be you can give it a try and let us know.