IDP node stickiness without an SLB?

[David Langenberg]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20140122/91af1e3d/attachment.html