Application Deep-Linking

[LenoreTumey]

When I use the term “deep linking,” I'm talking about the ability to navigate directly to a particular application page (like when I set a bookmark or get a link to a specific page in an email), and then land on the requested page after performing any necessary authentication.  There are a few ways this can work depending on how the application is integrated with the IDR:

• SP-initiated SAML applications – most SP-initiated SAML applications support deep linking through the use of the RelayState parameter.  When a user requests a specific page (say, a bookmark to a particular page in their wiki), the service provider will generate a SAMLRequest to send the Identity Provider.  Along with this request is a RelayState parameter (“this is where the user is trying to go.”)  The user’s browser will post the SAMLRequest & RelayState to the IdP, the IdP (IDR) will authenticate them, and perform any necessary step-up, and then send back a SAMLResponse along with the same RelayState back to the SP.  If the SAMLResponse looks good, the SP will then redirect the user to the originally requested page.
• Some SAML applications don’t use the RelayState to handle deep linking, but instead might do something like set a pre-authentication session cookie in the user’s browser before redirecting the user to the IdP.  After the IdP authenticates the user (including any necessary step-up), and the user comes back to the SP with a SAMLResponse, the cookie can be used to pick up where they left off and redirect them to the originally requested application.
• Some SAML applications don’t support deep-linking at all.   For those applications, users typically wind up at a standard landing page and would have to manually navigate to the desired page (or possibly re-click their bookmark) after logging into the app.
• HFED applications typically support deep-linking, as long as the user navigates to the protected (proxied) URL.  In this flow, let’s say the user navigates to https://www-myapp-com.sso.example.com/some/specific/page.html.  If they don’t have a session with the IDR, they’d be redirected to the authentication process (whether interactive login at the portal, or logging in through an external IdP or IWA).  Once authenticated (and step-up if necessary), the IDR will redirect the user to the originally requested page.  In this case, because the original request hit the IDR, we’re able to know where they were going (and not rely on the application to handle the deep linking).  The one caveat to deep-linking with HFED apps is that if the user already has an IDR session AND they have already accessed an HFED app, but then the HFED app session times out while the IDR session is still active, the IDR won’t know that the app session is no longer valid.  As such, the user could wind up getting redirected to the app’s login page.  To avoid this (and force the IDR to re-negotiate the HFED login ceremony in the background), you can append a &singlepoint-force-sso=true URL parameter (like:  https://www-myapp-com.sso.example.com/some/specific/page.html&singlepoint-force-sso=true).  Users wouldn’t know to do this, but if a company is embedding deep links into their portals, or pushing out a set of managed bookmarks to domain joined computers, they could include this parameter.

Note that deep-linking should work regardless of how you log into the IDR (interactive username/password at the portal login page, a custom portal, or an external Identity Provider or IWA).  It should also work regardless of whether step-up is enabled for the app.