Shibboleth SP behind load balancer with session affinity

[Sean Townsend]

The first part makes sense based on what I’ve gathered from the
documentation. However, I didn’t realize that it falls back to the homeURL.
That’s very helpful!

I have a question about your cookie-backed relayState comment. I’m not sure
what you mean by “after” the post back to the SP. In this scenario, would
the login loop be successful if the user started the flow on SP server 1,
logs in at IdP, and then posts back to SP server 2 with the cookie? If
that’s true, it sounds like I wouldn’t need to worry about affinity at all.
Our app just looks for the remote user header, and takes over from there.

Sorry for all the questions. I really appreciate your help!

— Sean


On Mon, Dec 4, 2017 at 8:49 PM Cantor, Scott <cantor.2 at osu.edu> wrote:

> >I would like to test this, but I would like a way to verify that the load
> balancer is doing its job and we don’t have a
> > significant number of users being redirected by to the IdP because they
> ended up on the wrong server on their way back
> > from the IdP. Is there something that will show up in the logs when this
> happens?
>
> Using the default relayState mechanism requires affinity across the login
> loop, and would be identifiable by setting homeURL to something unusual and
> checking for any access to it.
>
> Using cookie-backed relayState limits the affinity requirement to after
> the POST back to the SP and I don't know offhand what it logs, probably
> something in native.log related to an unidentified session.
>
> -- 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/20171205/453eec6c/attachment.html>