<div dir="ltr">Thanks Eric for your great description! <br>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...<br><br>Am I missing anything? <br><br><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 20, 2016 at 2:21 PM, Eric Goodman <span dir="ltr"><<a href="mailto:Eric.Goodman@ucop.edu" target="_blank">Eric.Goodman@ucop.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> So how is it possible to override that entityID location with another more specific SP's link<br>
<br>
</span>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.<br>
<br>
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.<br>
<br>
For information on using the RelayState in a Shibboleth SP, see <a href="https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPSessions" rel="noreferrer" target="_blank">https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPSessions</a> (if the SP is not Shibboleth, this is the wrong list!)<br>
<br>
<br>
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.<br>
<br>
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...)<br>
<br>
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).<br>
<br>
<br>
But again, deep linking support and "hard coded IdP links" are mostly opposite approaches to exposing services.<br>
<span class="HOEnZb"><font color="#888888"><br>
-- Eric<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
--<br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net">users-unsubscribe@shibboleth.net</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">Best,<br>Zico</div>
</div></div>