Return trip from IdP after AuthN redirects to incorrect path

[Ian Walsh]

Thanks for the replies folks.

The engineer currently troubleshooting this notes that when he experiences
the problem he also tests using his hosts file to bypass the load balancer,
yet he continue to have this issue on individual hosts protected by
Shibboleth SP.

That would suggest that something else in the ecosystem is leading to this
behavior, not (necessarily) the load-balancer doing the wrong thing.

They've upgraded to 3.0.2 now so we'll see if they continue to report
trouble.

-Ian

On Wed, Aug 8, 2018 at 1:00 PM, Cantor, Scott <cantor.2 at osu.edu> wrote:

> > According to that team the shibd logs don't show any kind of smoking gun.
> > Once this begins to occur it appears to continue until action is taken.
> They have
> > been restarting shibd to mitigate, which appears to work until it occurs
> again,
> > but that's not a sustainable solution.
>
> There are no supported relay state options that could possibly be "fixed"
> by a restart unless you're pointing it at a database or memcache storage
> back-end for the relayState setting and it's losing its connection.
> Otherwise it's cookie, in-memory, or literal and all of those are entirely
> subject to client, IdP, or load balancer whims, never the SP itself.
>
> It's likely that the restart is a red herring but since you mentioned it,
> I'm compelled to call that impossible without having done something
> unusual. My guess is restart correlates to "load balanced node change" and
> this is a deployment with an insufficiently sticky load balancer relying on
> in-memory relay state, which is impossible.
>
> -- Scott
>
> --
> For Consortium Member technical support, see https://wiki.shibboleth.net/
> confluence/x/coFAAg
> 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/20180808/e14a85b8/attachment.html>