SSO Redirect Strips URL Fragment Identity Request Deep Link Not Preserved for Unauthenticated Users

IdentityIQ (IIQ) IIQ Discussion and Questions
1

Which IIQ version are you inquiring about?

8.5

We’re facing an issue with deep links in our notification emails.

We include links in this format so users can navigate directly to a specific Identity Request:

${requestBaseUrl}/identityRequest.jsf#/request/${identityRequestId}

This works perfectly for users who already have an active session. However, for users who are not logged in and go through SSO (SAML), the URL fragment (#/request/…) gets stripped during the authentication redirect flow. They end up on the default Access Requests page instead.

I suspect this happens because the fragment is never sent to the server, so it’s lost during the SSO redirect.

Has anyone found a way to handle this or a workaround to preserve the deep link target through SSO authentication?

Thanks.

3

We have the issue in our one of the projects. Below are the steps , how we fix it??

The Root Cause is URL fragments (everything after #) are browser-only — they are never transmitted to the server in any HTTP request. When an unauthenticated user clicks your deep link:

  1. Browser sends GET /identityiq/identityRequest.jsf to the server (fragment stripped).
  2. IIQ detects no session → redirects to the SAML IdP.
  3. After SAML POST-back, IIQ only knows the original path (identityRequest.jsf) — the #/request/{id} context is gone forever.
  4. The Angular router on identityRequest.jsf has no fragment to parse, so it defaults to the Access Requests list.

No amount of SAML/RelayState configuration can fix this, because the fragment never leaves the browser in the first place.

step 1- Change the email link to use a query parameter (sent to the server) and build a small servlet that converts it back into a fragment after authentication.

${requestBaseUrl}/identityRequest.jsf#/request/${identityRequestId}

Replace this with below
${requestBaseUrl}/deeplink?target=request&id=${identityRequestId}

Step 2 — Create WEB-INF/classes/.../DeepLinkServlet.java (or drop it into a custom JAR) and register it in web.xml behind the authenticated URL pattern so IIQ/SAML protects it automatically.

public class DeepLinkServlet extends HttpServlet {
    @Override
    protected void doGet(HttpServletRequest req, HttpServletResponse resp)
            throws ServletException, IOException {

        String target = req.getParameter("target");
        String id     = req.getParameter("id");

        // By the time we reach here, SAML auth is complete and a session exists.
        String redirect;
        if ("request".equals(target) && id != null) {
            redirect = req.getContextPath()
                     + "/identityRequest.jsf#/request/"
                     + java.net.URLEncoder.encode(id, "UTF-8");
        } else {
            redirect = req.getContextPath() + "/home.jsf";
        }
        resp.sendRedirect(redirect);
    }
}

Step 3: in your web.xml,add the entry

<servlet>
    <servlet-name>DeepLinkServlet</servlet-name>
    <servlet-class>sailpoint.custom.DeepLinkServlet</servlet-class>
</servlet>
<servlet-mapping>
    <servlet-name>DeepLinkServlet</servlet-name>
    <url-pattern>/deeplink</url-pattern>
</servlet-mapping>

note: *Make sure /deeplink is inside the <security-constraint> block that triggers SAML authentication (it should be by default since IIQ protects everything except /external/* and login pages)

try these steps, and it will resolve it.

4

@LohithHarish This seems to be an existing issue with IIQ. Above workaround should work. However I would recommend reaching out to Sailpoint Support as well and take their opinion, in case there is any standard workaround available without introducing a custom servlet.

5

@LohithHarish - Please refer this links

The loss of URL fragments during SSO redirects is an inherent behavior of web browsers and HTTP protocols. For SailPoint IdentityIQ users, the ui/rest/redirect endpoint provides an effective and supported mechanism to this issue by transforming client-side fragments into server-side query parameters. By correctly constructing these redirect URLs, users can maintain a seamless deep linking experience even when navigating through SAML-based SSO authentication flows.

Orginal deeplink format - ${requestBaseUrl}/identityRequest.jsf#/request/${identityRequestId}

Regards,

Kannan

6

Thank you kannan it worked

7

Figure I would share this article we wrote in case it also helps: Using Tomcat Rewrites to Customize the UI and Add Friendly URLs in IdentityIQ – Instrumental Identity

8

@kannan_sb85 This solution does not work for us. As far as I can tell, it cannot work.

The path /ui/rest/redirect is unauthenticated. This can be found by looking in the web.xml, where /redirect is one of the values in the ignorePaths filter paramter (of the restAuthenticationFilter filter, which applies to this path).

Therefore, while the redirect itself works as expected, it happens immediately, even if the user is not currently authenticated. When the target page (with the fragment) tries to load, if not already authenticated, that triggers the authentication (possibly SSO), thus discarding the fragment.

Even if the restAuthenticationFilter required authentication, it still would not work as the authentication there is OAuth, whereas OP needs web SSO (as do we).

A bit of digging in the web.xml suggests the correct solution (hopefully it’s also documented somewhere), which is to use the certificationRedirectFilter, by making a path like:

/identityiq/manage/certification/detail.jsf?id=<id>

which authenticates first (and with SSO, maintains the certification id across the SAML login via the RelayState mechanism), then only redirects to the actual page (with the fragment) after authentication.

Or for the OP, use the identityRequestListRedirectFilter using one of the paths for that filter from the web.xml (such as /manage/accessRequest/myAccessRequests.jsf).