Return trip from IdP after AuthN redirects to incorrect path

[Ian Walsh]

Yes, httpd is the webserver. The application team troubleshooting ended up
fixing this by ensuring the shibd handler was only invoked in the location
intended, there was some extra httpd configuration for the /wp-admin/
directory which, when removed, resolved this issue. I'd attribute it to the
application doing unexpected things during the sign-in flow.

We were also experiencing what appeared to be a similar issue with
incorrect return URLs but that other issue now appears to be unrelated and
has to do with starting out on plaintext HTTP but returning with TLS and we
have workarounds to fix that case.

Thanks much for the assistance.

-Ian

On Thu, Aug 9, 2018 at 12:42 PM, Ian Walsh <ianwalsh at uw.edu> wrote:

> 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/20180810/ee1cf093/attachment.html>