Session/Cookie Question

[Timothy Spear]

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.

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.

Tim


On Thu, Jan 2, 2025 at 3:17 PM Check via users <users at shibboleth.net> wrote:

> 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.
>
> 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.
>
> 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.
>
> On Thu, Jan 2, 2025 at 3:09 PM IAM David Bantz <dabantz at alaska.edu> wrote:
>
>> 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.
>>
>> 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.
>>
>> Apologies if not helpful.
>>
>> David St Pierre Bantz
>> U Alaska IAM
>>
>> On Thu, Jan 2, 2025 at 9:30 AM Cantor, Scott via users <
>> users at shibboleth.net> wrote:
>>
>>> > How does it know where the user was heading to?
>>>
>>> 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.
>>>
>>> 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.
>>>
>>> -- Scott
>>>
>>>
>>> --
>>> For Consortium Member technical support, see
>>> https://shibboleth.atlassian.net/wiki/x/ZYEpPw
>>> To unsubscribe from this list send an email to
>>> users-unsubscribe at shibboleth.net
>>>
>> --
> For Consortium Member technical support, see
> https://shibboleth.atlassian.net/wiki/x/ZYEpPw
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20250102/d6c6a38b/attachment.htm>