<div dir="ltr">There are a number of ways technically that you could actually do it. e.g. store the redirected page name in the relay state and then have the SP route correctly based on the relay state. If you go this route, make sure to validate the page routing, otherwise it becomes a security vulnerbility.<div><br></div><div>If you try and have the IdP handle the routing, it is generally considered bad form, harder to maintain. Especially when you consider that the IdP would need to manage the custom routing logic for each SP. It gets becomes problematic very quickly.</div><div><br></div><div>Tim</div><div><br></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Thu, Jan 2, 2025 at 3:17 PM Check via users <<a href="mailto:users@shibboleth.net">users@shibboleth.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_default" style="font-family:arial,sans-serif">Many thanks to all those chiming in. I simply used Terms of Use as an example because we're currently using the Consent Profile Intercept that has Terms of Use as one of its capabilities. </div><div class="gmail_default" style="font-family:arial,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,sans-serif">What I'm attempting, is to have the IdP query LDAP and based on an attribute, direct them to a page where I can record something within the SP. What I don't have yet though is what web page they typed in in the first place.</div><div class="gmail_default" style="font-family:arial,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,sans-serif">What I'm hearing is that the SP records where the user was headed, Page1 or Page2, redirects them to the IdP, then waits for the IdP to send them back to the SP. At that point, the SP knows where they were headed and takes them to the right place, Page1 or Page2, and the IdP has no knowledge of that. I would have expected the IdP to remember the referrer that sent it to the IdP in the first place and then re-direct to that place when it finished its part.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jan 2, 2025 at 3:09 PM IAM David Bantz <<a href="mailto:dabantz@alaska.edu" target="_blank">dabantz@alaska.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Perhaps useful to some to recognize the (appropriate) design behind the separation of functions between the SAML IdP and SP. The IdP provides information about the user to the SP relying on that IdP. That circumscribed role leaves details - especially details concerning different "parts" or response locations - up to the service. That distribution or segregation of responsibilities contrasts with a "central command" model in which a single central hub assumes detailed control of "which users can do what under what conditions. Those contrasting models reflect different philosophies of how to provide trusted access to service; to put it a bit contentiously, one facilitates collaboration and distributed control, the other facilitates central authority and control.<br><br>In the current SAML IdP & SP context, that means a "terms of use" required for a proper subset of functions behind the SP should be triggered and recorded within the service.<br><br>Apologies if not helpful.<br><br>David St Pierre Bantz<br>U Alaska IAM</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jan 2, 2025 at 9:30 AM Cantor, Scott via users <<a href="mailto:users@shibboleth.net" target="_blank">users@shibboleth.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> How does it know where the user was heading to?<br>
<br>
It doesn't, that's all up to the SP to handle. The things an IdP knows are the identity of the SP, the response location (from the metadata), and the state token, which is opaque.<br>
<br>
Of those, the identity of the SP is the only relevant bit that can be used in any sort of "what was the user trying to do?" sense.<br>
<br>
-- Scott<br>
<br>
<br>
-- <br>
For Consortium Member technical support, see <a href="https://shibboleth.atlassian.net/wiki/x/ZYEpPw" rel="noreferrer" target="_blank">https://shibboleth.atlassian.net/wiki/x/ZYEpPw</a><br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net" target="_blank">users-unsubscribe@shibboleth.net</a><br>
</blockquote></div>
</blockquote></div>
-- <br>
For Consortium Member technical support, see <a href="https://shibboleth.atlassian.net/wiki/x/ZYEpPw" rel="noreferrer" target="_blank">https://shibboleth.atlassian.net/wiki/x/ZYEpPw</a><br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net" target="_blank">users-unsubscribe@shibboleth.net</a><br>
</blockquote></div>