IDP node stickiness without an SLB?

[Wessel, Keith]

All,

Thanks, some good suggestions.

Chris, I wish your idea would work as it's so easy to implement. Scott's correct, though, and we saw exactly that behavior with our GSLB. A user starts on node 1 and, once being redirected to the UsernamePassword login handler, switched to the other node... and things break there.

We'll experiment with both Dave's keep-alive idea and, if not, look at the host cookie and proxy idea.

Thanks again, everyone.

Keith


-----Original Message-----
From: users-bounces at shibboleth.net [mailto:users-bounces at shibboleth.net] On Behalf Of Cantor, Scott
Sent: Tuesday, January 21, 2014 7:50 PM
To: Shib Users
Subject: Re: IDP node stickiness without an SLB?

On 1/21/14, 6:38 PM, "Christopher Bongaarts" <cab at umn.edu> wrote:
>
>Off the top of my head - not sure if this would actually work:
>
>Update the login.jsp to look at the Host: header - if it's the "virtual"
>name (idp.illinois.edu), redirect to one of the "real" names
>(idpN.illinois.edu). Otherwise leave it alone.
>
>I'm pretty sure that you only really need to sticky that page (because
>the login context stored locally to that IdP server).

I don't think so. By the time login.jsp is involved, the login context has
been created and a cookie sent back, and a switch there would break it.
Same goes for after the password is posted, I think, but I'm less sure of
that step, that may be a part of my customizations.

At least in my IdP, you have /.../SAML2/SSO/Redirect -> /idp/AuthnEngine
-> /.../SAML2/SSO/Redirect -> SP, and breaking the sticky at any stage of
that will break the login.

I think you'd have to do something like what Jim described.

-- Scott


--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net