Return trip from IdP after AuthN redirects to incorrect path

[Ian Walsh]

This issue has persisted since the upgrade and I have more details. We set
the relayState parameter to 'cookie' so the client could see the relay
state.

It appears that the relay state isn't being set correctly when the SP
redirects to do the authn request. An example:

I navigate to:

https://blogs.uw.edu/ianwalsh/wp-admin/

I am immediately redirected to the IdP with the AuthN request but my shib
state cookie has the value of:

_shibstate_xxxxxxxxxx_xxxx=https%3A%2F%2Fblogs.uw.edu%2Fwp-admin%2F;

which is not the full path which I originated.

Any thoughts, with this additional data point?

Thanks in advance.

-Ian

On Wed, Aug 8, 2018 at 2:50 PM, Ian Walsh <ianwalsh at uw.edu> wrote:

> 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/20180809/96e35a0e/attachment.html>