Deep Linking

In an IDR SSO Agent deployment, you can provide links to specific pages within an application (called deep links), through managed bookmarks or by email. Like a regular sign-in flow, with deep links, the identity router enforces the access policy applied to the application, including additional authentication. For example, if a user clicks a link in an email that is to a specific page within an application, SecurID prompts the user for required authentication before opening the application page.

SecurID supports deep linking with the standard or custom portal or if you are using an external SAML IdP or Integrated Windows Authentication (IWA).

Before you configure deep linking, review the following sections to understand how SecurID handles single sign-on (SSO) and access policy evaluation with deep links.

SSO with Deep Links

Configuring SSO with deep links varies depending on the type of application.

SAML

Depending on your SAML application, you might or might not be able to set up deep linking and SSO.

Most SP-initiated SAML applications support deep linking through the use of the RelayState parameter. The RelayState parameter indicates the page that the user is trying to access. The flow works in the following way:

  1. The user navigates to a page-specific link, for example, a bookmark to a particular page in a wiki.

  2. The service provider generates a SAML request to send to the IdP (the identity router). This request includes the RelayState parameter.
  3. The user’s browser sends the SAML request and RelayState to the IdP.
  4. The IdP prompts the user for required authentication (including additional authentication) and then sends back a SAML response along with the same RelayState back to the SP.
  5. The SP redirects the user to the originally requested page.

Instead of using the RelayState parameter for deep linking, some SAML applications might use a pre-authentication session cookie in the user’s browser before redirecting the user to the IdP. After the IdP authenticates the user (including additional authentication), and the user comes back to the SP with a SAML response, the cookie can be used to redirect the user to the originally requested application.

Some SAML applications do not support deep-linking. For those applications, generally users navigate to a standard landing page to sign into the application and then have to manually navigate to the page within that application (or re-click the bookmark).

HTTP Federation

HTTP Federation (HFED) Proxy applications typically support deep-linking and SSO, as long as the user navigates to the protected (proxied) URL. The flow works in the following way:

  1. The user navigates to a page-specific link, for example, https://www-myapp-com.sso.example.com/some/specific/page.html.

  2. The user does not have an SecurID user session, so SecurID prompts the user for required authentication.
  3. The user completes the authentication.

  4. The identity router redirects the user to the originally requested page.

If the session timeout of the HFED application is less than the session timeout of SecurID, this flow might change. If the user still has an active SecurID user session and has accessed the HFED application but now the HFED application session has expired, the user could be redirected to the application's sign-in page.

For example, a user clicks on an HFED application in the portal. The user is signed in and uses the portal for an hour. The user closes the application browser tab and takes a lunch break. After lunch, the user continues to use applications within the portal. The SecurID user session is still valid, but the HFED application has a shorter session duration and has timed out. The user clicks a deep link back to the HFED application. The user is directed to a proxied version of the application’s sign-in page.

To avoid this situation with deep links, SecurID automatically appends the following parameter to the portal URLs for all HFED applications:

Parameter Description
singlepoint-force-sso=true

Re-negotiates an application session within a valid SecurID user session, so that the user is not re-directed to the application's sign-in page.

For example, you specify a Portal URL of https://appname.sso.example.com/app/landing/page.html when you add the application. When the portal URL is actually constructed (for example, the URL that you see if you hover over the application in the portal or look at the link URL at the bottom of your browser), the URL is https://appname.sso.example.com/app/landing/page.html?singlepoint-force-sso=true

If you push out a set of managed bookmarks to domain joined computers (for example, Internet Explorer bookmarks for employees using Group Policy), append this parameter to the HFED application URLs to simplify your users' sign-in experiences.

Access Policy Evaluation with Deep Links

When a user tries to access an application for the first time, the identity router evaluates the access policy assigned to the policy. After the initial evaluation, the identity router evaluates the access policy differently, depending on the application and link type.

For SAML applications (with links either at the application home page or deep links) or HFED applications with links at the application home page, within the same SecurID user session, the identity router evaluates the policy each time the user accesses the application to monitor if anything has changed.

For HFED application deep links, the identity router evaluates the policy when the user first accesses the application. If you want the identity router to continue to evaluates the policy within an SecurID user session for HFED deep links, you must append the following parameter to the portal URLs for all HFED applications:

Parameter Description
singlepoint-reassess-policy=true

Specifies that SecurID re-evaluates the access policy on all application access attempts within an SecurID user session and not just the initial access attempt.

If you push out a set of managed bookmarks to domain joined computers, append this parameter to the HFED application URLs, for example, https://appname.sso.example.com/app/landing/page.html?singlepoint-reassess-policy=true

If you want to use both the SSO and policy evaluation parameters, you can join the parameters with an ampersand (&), for example, https://appname.sso.example.com/app/landing/page.html?singlepoint-force-sso=true&singlepoint-reassess-policy=true