<div dir="ltr"><div class="gmail_default" style="font-family:arial,sans-serif">Tim,</div><div class="gmail_default" style="font-family:arial,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,sans-serif">I'm just looking at what it does today.  The Consent Profile Intercept (<a href="https://shibboleth.atlassian.net/wiki/spaces/IDP5/pages/3199509862/ConsentConfiguration">https://shibboleth.atlassian.net/wiki/spaces/IDP5/pages/3199509862/ConsentConfiguration</a>) has a terms of use capability that we're currently using.  When I type <a href="https://mySP.com/Page1">https://mySP.com/Page1</a>, it shows me the Terms of Use page.  I click a checkbox, then Submit, and it takes me to <a href="https://mySP.com/Page1">https://mySP.com/Page1</a>.  If I type <a href="https://mySP.com/Page2">https://mySP.com/Page2</a>, when done, it takes me to Page2.  I'm just trying to figure out how it knows where to take me when it's done.</div><div class="gmail_default" style="font-family:arial,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,sans-serif">To use an example from the IdP documentation for Relying Party:</div><div class="gmail_default" style="font-family:arial,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,sans-serif"><!-- Example matching three (or more) SPs --><br><bean parent="RelyingPartyByName"><br>    <constructor-arg name="relyingPartyIds"><br>        <list><br>            <value><b><a href="https://sp.example.org/sp">https://sp.example.org/sp</a></b></value><br>            <value><b><a href="https://another.example.org/sp">https://another.example.org/sp</a></b></value><br>            <value><b><a href="https://still.another.example.org/sp">https://still.another.example.org/sp</a></b></value><br>        </list><br>    </constructor-arg><br>    <property name="profileConfigurations"><br>        <list><br>            <!-- Your refs or beans here. --><br>        </list><br>    </property><br></bean></div><div class="gmail_default" style="font-family:arial,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,sans-serif">How does it know whether to take me to <b><a href="https://sp.example.org/sp">https://sp.example.org/sp</a></b>, <b><a href="https://another.example.org/sp">https://another.example.org/sp</a></b>, or <b><a href="https://still.another.example.org/sp">https://still.another.example.org/sp</a></b> once I click the submit button?</div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Thu, Jan 2, 2025 at 3:26 PM Timothy Spear 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">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"><div dir="ltr" class="gmail_attr">On Thu, Jan 2, 2025 at 3:17 PM Check 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"><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>
-- <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>