StorageService-backed RelayState mechanism did not return a state value.

[Dan McLaughlin]

Our scenario is that we have a TCP load balancer in front of a number
of Apache web servers with local SP's.  The load balancer is
configured with sticky sessions using a cookie placed by the load
balancer.  Our applications support clustering using Tomcat in-memory
replication, so sticky sessions is not required by our applications.
So for the most part all users will stay on the same webserver, unless
we reboot or stop a webserver, in which case the load balancer will
fail over all the users to the next webserver with the least number of
connections. We configured it this way in the past not because our
applications require session affinity, but because if we didn't then
users would keep getting asked to login again anytime the load
balancer would start the user on one web server and move them to
another.

So is it correct to say that if I don't want users to have to
authenticate again in the case of a failover event, then I must have
relayState="cookie" at a minimum. And is it correct that only problem
with a failover using relayState="cookie" is that if the IDP
authentication wasn't complete when the failover occurred then it
won't work (unless I configured NativeSPClusteringByProxy on Apache).

My next best option would be using a Shared shibd process, but this
introduces a single point of failure, so I'm not interested it that.
The preferred option is a Shared Database, but my webservers live in a
DMZ with no access to a database server, so this isn't an option.   So
would using relayState="cookie" along with NativeSPClusteringByProxy
get me close to the failover ability provided by a Shared Database
configuration?

--

Thanks,

Dan
On Mon, Nov 19, 2018 at 4:57 PM Cantor, Scott <cantor.2 at osu.edu> wrote:
>
> On 11/19/18, 5:49 PM, "users on behalf of Dan McLaughlin" <users-bounces at shibboleth.net on behalf of dmclaughlin at tech-consortium.com> wrote:
>
> > I'm guessing you noticed that I had the DataSealer configured, which is why you commented about the relay
> > state and clustering.
>
> It's why I assumed you were clustering but it's not connected to the scenario I was assuming. I can't know whether somebody's load balancer is working, and the symptom fit a node change.
>
> > But what you were pointing out earlier was that because I had a relayState
> > of ss:mem that clients that failed over would have issues unless I set
> > the relayState to cookie.
>
> That's a very rare matter of timing, it would not affect things in a noticeable way unless "fail over" means "lack of stickiness".
>
> >  I think if there was an update to Session Recovery section that made it a little more clear that
> > relayState="cookie" was required then I might not have missed that step.
>
> I didn't design that feature to eliminate stickiness. It might not perform adequately in that scenario, it wasn't meant to be done that frequently.
>
> -- 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