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

[Cantor, Scott]

On 11/19/18, 6:36 PM, "users on behalf of Dan McLaughlin" <users-bounces at shibboleth.net on behalf of dmclaughlin at tech-consortium.com> wrote:
>  Our applications support clustering using Tomcat in-memory
> replication, so sticky sessions is not required by our applications.

Then I wouldn't bother clustering the SP and I'd get the SP session out of the way as early as possible once the application session is in place, and you're done, as long as logout isn't involved. A few minutes of stickiness is plenty.

> 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.

That's imposed by keeping the SP in the way instead of getting it out of the way up front.

> 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.

RelayState has nothing to do with that. It affects one specific hop between protected access and the SAML response and doesn't cause extra logins, it just (possibly) drops the user in the wrong place. It affects deep linking, not session behavior. It is not involved in anything you're asking about.

> 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).

I would think the opposite. That's the behavior when it's stored in memory. Cookies avoid the need for any node affinity during that step unless the cookie is prevented from working correctly, but then you just end up needing affinity immediately afterward anyway, which is why they're not the default anymore. Using them doesn't help all that much and they have other drawbacks. Logins don't "break" because of RelayState, it simply defaults the redirect location.

> 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. 

Nothing is worth that option.

>  So would using relayState="cookie" along with NativeSPClusteringByProxy get me close to the failover ability provided
> by a Shared Database configuration?

I suppose but that's a totally different thing. Jim's example is an add-on to the fundamental point: stop using the SP's session. Until you change that, the rest is academic.

-- Scott