SP State and Clustering

[Cantor, Scott]

> What I have read so far implies that state is saved on the SP, so that when
> the user returns from authenticating at the IdP they must return to the same SP.

It is.

> BTW -- Returning to the same SP is not important for our web application as
> the application does not share sessions with the SP.  (The SP "resource"
> makes an API call to the application which returns a user-specific redirect URL
> to the web app that is passed back to the browser.)

There is always stickiness for at least an initial redirect to a resource and if you take over at that point then as long as there are no other actively protected resources the SP will never be involved after that one access.
 
What you're describing however, in terms of some kind of API call, is very possibly not secure. I have no idea, but people that cook up schemes like that generally get it wrong.

> Just to be clear, is there state stored on the SP even if we use relayState="cookie"?

Yes. You can't avoid a session for at least one request.

> I'm asking because it takes quite a bit of time to restart shibd (about 8
> minutes) and during this time the SP is unavailable.

There is no earthly reason shibd would take 8 minutes to start up barring no resources or a totally screwed up approach to metadata. Even the eduGAIN metadata aggregate doesn't take much more than a minute or so, still bad, but nothing like that. And we have that improved now so that initial startup doesn't verify the signature on the backup file, so I doubt it even takes that long. You're doing something wrong.

> Our load balancer is currently configured for sticky sessions (by IP) for the SP cluster.  So, if one of
> the SPs in the cluster is taken down then any in-flight authentications would fail.

Any in flight logins will fail on the initial redirect to a resource no matter what (unless the state is offloaded).

> I understand there are methods to share SP state in a cluster (e.g.
> memcached), but then we are back to a single point of failure. The cluster's
> purpose is for High Availability, not for load.

I happen to completely agree with that. But the requirement with the SP is for at least a minute or two of stickiness no matter what integration strategy is used, unless you offload the state.

- Scott