'Deep linking' in Shibboleth

[Zico]

Thanks Eric for your great description!
So.. what I can understand .. there is actually nothing to do from IDP side
to facilitate deep linking. As resources are available there in resource
provider ( aka. SP ), so it's actually there inside SP's RelayState ( for,
Shibboleth SP of course ) configuration which link should go to where...

Am I missing anything?



On Wed, Jan 20, 2016 at 2:21 PM, Eric Goodman <Eric.Goodman at ucop.edu> wrote:

> > 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
>
> --
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>



-- 
Best,
Zico
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20160122/51848e48/attachment-0001.html>