SAML doesnt redirect post login

Hi ​@kolluax,

Based on the behaviour you described, the SAML authentication itself appears to be reaching PingFederate successfully, but the flow is not completing the final redirect back into AEM Author after login. In other words, the user is able to authenticate with the Identity Provider, but after authentication the browser is not being returned to the expected AEM page such as /sites.html.

Since the same configuration worked previously through the F5 URL and the main change is that traffic is now being routed to the new Dev Author server, the issue is most likely related to how the post-authentication response is being handled on the new path rather than to the IdP login itself.

What I believe is happening

In a successful AEM SAML flow, after the user authenticates with the Identity Provider:

1. the SAML response is posted back to AEM at the configured saml_login endpoint
2. AEM validates the SAML response
3. AEM issues the authenticated session cookie
4. AEM redirects the browser back to the requested page, or to the configured default redirect page

At the moment, the issue appears to be occurring in steps 3 or 4 above.

Most likely causes

The most likely causes are:

• the redirect target is not being preserved correctly after authentication
• the authenticated session cookie is not being returned to or reused by the browser correctly
• the load balancer / reverse proxy path to the new server is altering or not forwarding part of the response required for the final redirect
• there is a mismatch between the external F5 URL and what AEM expects for the post-login callback / redirect

Why this points to the new environment path

You mentioned that:

• SAML was already configured and working on the old Dev Author
• the same F5 URL is being used
• the SAML settings were copied as-is to the new Dev Author
• after traffic was switched to the new backend, login no longer returns the user to /sites.html

That strongly suggests the issue is tied to how the new server or the new F5-to-backend route is handling the post-login response, rather than to the PingFederate authentication itself.

To isolate the issue, I recommend validating the following items.

1. Confirm the response to the POST back to AEM after authentication

Please capture the browser network trace for one failed login attempt and identify the request where the Identity Provider posts the SAML response back to AEM, typically to a URL ending in:

/saml_login

For that request, please check:

• the full request URL
• the HTTP response status
• whether the response includes a Location header
• whether the response includes a Set-Cookie header for the AEM login token/session

This is the most important check, because it will confirm whether AEM is successfully completing authentication and attempting to redirect the browser.

2. Confirm the final redirect target

Please verify whether, after successful authentication, the response is redirecting the browser to:

• /sites.html
• /aem/start.html
• another AEM path
• or no redirect at all

If there is no redirect or if the redirect points to an unexpected host/path, that would explain why the browser remains on the PingFederate page.

3. Verify whether the requested path is being preserved

AEM normally stores the originally requested page so that after successful SAML login it can return the user to that location.

Please verify whether the request path being accessed before login is being preserved and then used after login. If it is not being preserved, AEM may not know where to send the browser after authentication.

4. Validate the F5 / reverse proxy handling for the new backend

Because the issue started only after moving traffic to the new Dev Author, please verify whether the F5 or any reverse proxy/security layer in front of the new server is:

• modifying response headers
• rewriting redirect locations
• altering cookie attributes
• dropping or changing Set-Cookie headers
• changing the external host/protocol presented back to the browser

Even when the SAML configuration itself is unchanged, any difference in how the new route handles redirects or cookies can interrupt the final handoff back into AEM.

5. Compare the old and new backend behavior

If the old Dev Author path is still available for comparison, it would help to compare one successful login trace from the old backend with one failed trace from the new backend, specifically for:

• the /saml_login response
• the redirect target after authentication
• the cookies returned to the browser

AEM-side configuration items to review

Please also review the SAML Authentication Handler configuration on the new Dev Author and compare it against the previous working environment, including:

• protected path(s)
• Assertion Consumer Service URL
• Service Provider Entity ID
• default redirect value
• IdP URL
• certificate/trust configuration
• any settings controlling redirect behavior after authentication

In addition, please confirm that the configured redirect target is valid and accessible on the new Author environment.

Suggested logging for troubleshooting

To gather more detail from the AEM side, it would be helpful to enable DEBUG logging temporarily for the authentication flow and reproduce the issue once. In particular, logs around the SAML authentication handler and Sling authentication flow will help confirm whether:

• the SAML response is accepted successfully
• the authenticated session/token is created
• AEM determines a redirect target
• the redirect response is sent back as expected

Information requested for next analysis

To continue the investigation, please share the following from one failed attempt:

1. HAR file or browser network capture covering:

   • request to the protected AEM page
   • redirect to PingFederate
   • POST back to /saml_login
   • final response after /saml_login

2. For the /saml_login response specifically:

   • full URL
   • response status
   • Location header, if present
   • Set-Cookie header(s), if present

3. Relevant AEM authentication logs from the same time window

4. Confirmation whether any F5/iRule/rewrite/header handling differs between the old and new backend routing

Interim conclusion

At this stage, the issue does not appear to be a failure of PingFederate authentication itself. Instead, it appears that after successful authentication the browser is not being redirected back into AEM Author correctly on the new Dev Author path.

The next step is to confirm whether AEM is sending the expected post-login redirect and authenticated cookie, and whether those are reaching the browser unchanged through the new F5 route.

Once we have the network trace and matching AEM logs, we should be able to determine whether the issue is:

• on the AEM side
• on the reverse proxy / load balancer side
• or due to a mismatch in redirect/callback handling between the new backend and the external F5 URL

Please share the above details and we will review them further.

Thanks

Pranay