Please let us know what worked. I'll be attempting something similar soon & it'd be nice to know what worked for you<span></span>. <div><br></div><div>Dave<br><br>On Tuesday, January 21, 2014, Wessel, Keith <<a href="mailto:kwessel@illinois.edu">kwessel@illinois.edu</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">All,<br>
<br>
Thanks, some good suggestions.<br>
<br>
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.<br>
<br>
We'll experiment with both Dave's keep-alive idea and, if not, look at the host cookie and proxy idea.<br>
<br>
Thanks again, everyone.<br>
<br>
Keith<br>
<br>
<br>
-----Original Message-----<br>
From: <a href="javascript:;" onclick="_e(event, 'cvml', 'users-bounces@shibboleth.net')">users-bounces@shibboleth.net</a> [mailto:<a href="javascript:;" onclick="_e(event, 'cvml', 'users-bounces@shibboleth.net')">users-bounces@shibboleth.net</a>] On Behalf Of Cantor, Scott<br>
Sent: Tuesday, January 21, 2014 7:50 PM<br>
To: Shib Users<br>
Subject: Re: IDP node stickiness without an SLB?<br>
<br>
On 1/21/14, 6:38 PM, "Christopher Bongaarts" <<a href="javascript:;" onclick="_e(event, 'cvml', 'cab@umn.edu')">cab@umn.edu</a>> wrote:<br>
><br>
>Off the top of my head - not sure if this would actually work:<br>
><br>
>Update the login.jsp to look at the Host: header - if it's the "virtual"<br>
>name (<a href="http://idp.illinois.edu" target="_blank">idp.illinois.edu</a>), redirect to one of the "real" names<br>
>(<a href="http://idpN.illinois.edu" target="_blank">idpN.illinois.edu</a>). Otherwise leave it alone.<br>
><br>
>I'm pretty sure that you only really need to sticky that page (because<br>
>the login context stored locally to that IdP server).<br>
<br>
I don't think so. By the time login.jsp is involved, the login context has<br>
been created and a cookie sent back, and a switch there would break it.<br>
Same goes for after the password is posted, I think, but I'm less sure of<br>
that step, that may be a part of my customizations.<br>
<br>
At least in my IdP, you have /.../SAML2/SSO/Redirect -> /idp/AuthnEngine<br>
-> /.../SAML2/SSO/Redirect -> SP, and breaking the sticky at any stage of<br>
that will break the login.<br>
<br>
I think you'd have to do something like what Jim described.<br>
<br>
-- Scott<br>
<br>
<br>
--<br>
To unsubscribe from this list send an email to <a href="javascript:;" onclick="_e(event, 'cvml', 'users-unsubscribe@shibboleth.net')">users-unsubscribe@shibboleth.net</a><br>
--<br>
To unsubscribe from this list send an email to <a href="javascript:;" onclick="_e(event, 'cvml', 'users-unsubscribe@shibboleth.net')">users-unsubscribe@shibboleth.net</a><br>
</blockquote></div><br><br>-- <br>David Langenberg<div>Identity & Access Management</div><div>The University of Chicago</div><br>