IDP node stickiness without an SLB?

[David Langenberg]

I'd assume the browser would've done the DNS query once rather than
once-per-connection, but if we have to get difficult then so be it.  You
could rectify it by having the login.jsp detect the IP address of the node
it's running on and send down all further references for elements in the
page to be grabbed by IP address rather than by DNS name.  That'd force
everything to that single node.

Dave


On Fri, Jan 24, 2014 at 2:41 PM, Wessel, Keith <kwessel at illinois.edu> wrote:

>  This is an interesting suggestion, Dave. And at first, seems like
> that’ll do the trick. Enter concurrent connections. Looks like the HTTP 1.1
> spec recommends browsers support two persistent connections to a given host
> to speed up page loading by doing it in parallel. With the launch of IE 8,
> our friends at Microsoft bumped their browser up to a max of six concurrent
> persistent connections.
>
>
>
> Problem arises if one of those connections grabs the 1st IP from the load
> balancer and the next one grabs the other. Usually won’t happen with DNS
> caching, but depending on when consecutive connections are opened, I can
> theoretically see a problem here.
>
>
>
> Know any magic to work around this one? We really like this idea if we can
> make it work!
>
>
>
> Keith
>
>
>
>
>
> *From:* users-bounces at shibboleth.net [mailto:users-bounces at shibboleth.net]
> *On Behalf Of *David Langenberg
> *Sent:* Wednesday, January 22, 2014 4:56 PM
>
> *To:* Shib Users
> *Subject:* Re: IDP node stickiness without an SLB?
>
>
>
> You could extend that 60 second timeout by adding an AJAX request back to
> the IdP every, say, 10 seconds for something silly like making a HEAD
> request on some CSS or text file.
>
>
> Dave
>
>
>
> On Wed, Jan 22, 2014 at 3:51 PM, Wessel, Keith <kwessel at illinois.edu>
> wrote:
>
> David,
>
>
>
> I haven’t done more than research this idea, and it’s an interesting one.
> Problem is, from what I’ve read, browsers are going to have their own
> persistent connection timeout. IE seems to default to 60 seconds, for
> instance. That’s long enough for most users to log in, but I don’t think we
> want a 60-second lag on the login screen to cause a user to get an error.
>
>
>
> This is such a simple and clean solution other than this and, of course,
> the fact that you’ll have more httpd processes lingering around.
>
>
>
> Still considering the IDP proxy model. But all of this sure is making
> active/passive tempting.
>
>
>
> Keith
>
>
>
>
>
> *From:* users-bounces at shibboleth.net [mailto:users-bounces at shibboleth.net]
> *On Behalf Of *David Langenberg
> *Sent:* Tuesday, January 21, 2014 4:36 PM
>
>
> *To:* Shib Users
> *Subject:* Re: IDP node stickiness without an SLB?
>
>
>
> Just a complete shot in the dark, but what if you set each node to use an
> HTTP KeepAlive with a long timeout?  The idea being getting the browser to
> maintain an open connection to the node while the user is entering their
> credentials.  Submission of the form would then (hopefully) happen over the
> existing connection back to the same node & thus allow everything to
> succeed.
>
>
>
> Dave
>
>
>
> On Tue, Jan 21, 2014 at 3:21 PM, Wessel, Keith <kwessel at illinois.edu>
> wrote:
>
> All,
>
>
>
> I’m trying to find a way for our IDP nodes to remain sticky for a user
> throughout the login process in a GSLB environment where client stickiness
> isn’t an option. The GSLB talks to DNS servers, not clients, and we don’t
> want our entire campus DNS resolver to be sticky to a single IDP node if we
> can help it.
>
>
>
> We deployed Paul’s excellent database-backed storage service but had to
> back out the change. As I understand it, the login process has to stick to
> a single IDP node when using this solution and, sure enough, we saw
> problems when a user’s browser started on one IDP node then went to the
> other, either while getting to the login page or when the login page was
> submitted. Since the session wasn’t yet known to the other IDP node, the
> login couldn’t be completed.
>
>
>
> Can anyone make any suggestions of how we might, once a user hits node 1
> or node 2, keep them going back to that node until they’re logged in and
> returning to the SP? I see no easy way to, say, put an absolute URL in
> place of /idp for all of the relative URLs presented by the IDP.
>
>
>
> If we can’t accomplish this, we’re planning to still use the
> database-backed storage service combined with active-passive from our GSLB.
> But we really do like being able to balance traffic between the two sites
> when they’re both available.
>
>
>
> Thanks,
>
> Keith
>
>
>
>
> --
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
>
>
>
>
> --
> David Langenberg
>
> Identity & Access Management
>
> The University of Chicago
>
>
> --
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
>
>
>
>
> --
> David Langenberg
>
> Identity & Access Management
>
> The University of Chicago
>
> --
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>



-- 
David Langenberg
Identity & Access Management
The University of Chicago
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20140124/78575198/attachment.html