Load Balancing and Sticky Sessions

Brian Reindel brian at reindel.com
Mon Aug 26 18:24:32 EDT 2013


Well, I can only tell you how we manage our environment, but I
couldn't tell you if we're a fringe case or not. We already put a
significant amount of financing and resources behind our database
(Oracle Enterprise), and so we readily accept it as our single point
of failure. It is both highly transactional and a warehouse and both
tiers are clustered to my knowledge. I'm not a database architect so I
couldn't give you every detail, but I know we prefer this setup. If
the database goes down the enterprise comes to a screeching halt.

On the application side we're going to be using Shibboleth IdP for SSO
and two service providers to start. The first SP is a legacy
application that requires sticky sessions already, but it will have an
end of life. The next generation of application services (SP #2) we're
building is stateless and uses OAuth integrated with Shibboleth for
the authentication. Spring Security is our OAuth implementation and
we've swapped their in-memory token services with a database version.
This is because we want everything to be stateless. Any new service
based applications we build will follow a similar pattern. Which
brings me to the IdP. We don't want to go through all of the effort to
make all future applications stateless, only to require sticky
sessions for SSO.

Our goal is to start/stop/balance/cluster with little to no
interruption to the end users. The best way I feel to do that is to
move toward complete statelessness.


On Mon, Aug 26, 2013 at 4:57 PM, Cantor, Scott <cantor.2 at osu.edu> wrote:
> On 8/26/13 4:31 PM, "Brian Reindel" <brian at reindel.com> wrote:
>
>>Does the IdP require sticky sessions on an Apache load balanced
>>environment in order for an authenticated user to maintain their
>>existing session? If yes, is it possible to swap the in-memory
>>management of authenticated users and service providers to a database
>>model?
>
> See https://wiki.shibboleth.net/confluence/display/SHIB2/IdPClusterIntro
>
> Short answers yes and with third party extensions.
>
> I'd love to understand the value of a single point of failure moved to
> another spot in terms of impact on maintenance (that's a serious question,
> I'm still trying to understand the point of it).
>
> Active/passive, load permitting, seems more viable to me than a database
> or memcache if you ever want to patch without downtime.
>
> (Though of course I do the stateless thing myself, allowing that I can't
> do certain things with it)
>
> -- Scott
>
>
> --
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net


More information about the users mailing list