'Deep linking' in Shibboleth

Eric Goodman Eric.Goodman at ucop.edu
Wed Jan 20 15:21:38 EST 2016


> So how is it possible to override that entityID location with another more specific SP's link

You can't override the specific SP links. It's not even meaningful, because the metadata lists the only URLs the SP CAN accept your assertions at.  If you change those URLs then the SAML conversation doesn't happen.

As Scott said RelayState is the value the SP can set to "save" the information about where the user is going as part of the request to the IdP. After authentication the IdP returns the RelayState as part of the assertion to the SP's SAML-related URLs. The SP then retrieves its RelayState information and directs the user as the SP sees fit. There is nothing that the IdP does to support deep links, other than returning the RelayState unchanged to the SP. 

For information on using the RelayState in a Shibboleth SP, see https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPSessions (if the SP is not Shibboleth, this is the wrong list!)


Based on your questions, you may be thinking of a different use case which is not deep linking, but links with hardcoded IdPs to bypass user discovery. This is where you create a link -- e.g. in your central portal -- that the user is asked to click instead of going directly to the application website. If the user clicks your link they do not get prompted to select their IdP, but is instead directly routed to the IdP. You can include a URL that you want the user to attempt to access after login is complete. 

This approach is the opposite of deep linking because it relies on the assumption that your users will never bookmark application pages directly, and that they will always use your portal and custom link to login. (Spoiler alert, users will not do this, and will always bookmark application pages directly...) 

I don't think there's a standard for building such links, but Shibboleth supports them in in ways that can leverage either IdP-initiated SSO (via a Shib IdP) or SP-initiated SSO (via a Shib SP).


But again, deep linking support and "hard coded IdP links" are mostly opposite approaches to exposing services.

-- Eric
 


More information about the users mailing list