Any Thoughts/Recommendations on Load Sharing and Failover?

[Cantor, Scott]

On 8/16/12 3:51 PM, "Henry B. Hotz" <hotz at jpl.nasa.gov> wrote:

>There was a thread a week or two ago about redundant SPs and
>sharing/splitting shibd.  Sounded like it wouldn't accomplish much.  OTOH
>if a SP failover forces a trip back to the IDP, at least the user doesn't
>have to re-log-in?

Not generally, but that's up to the IdP as with any request to it.

The basic SP position on this is that it's not a good use of my time to
build a google-scale session system. If your application minus SAML is
clusterable, then the best way to SAML-enable it is to bridge the SP
session to the app session and then throw away the original one. That
holds if you don't believe web logout is feasible (as I do not). It's very
minimal in terms of work and doesn't ask much from the load balancer.

If you need a truly clustered session, sharing a shibd is a shortcut. The
"intended" way is an ODBC back-end, and memcache is also fine. I wish that
I could provide the memcache plugin on Windows for people, but there is no
stable (as in maintained and relased) memcache client there for C/C++.
I've considered just doing it as a one-off build that would be
unsupported, but at least available. I can't ship it officially when
there's no tagged release of code to base it off of.

There really is no way with the provided plugins to make shibd itself
redundant, only remove the state so that the process can cycle without
impact.

Architecturally, there are places plugins can go to support different
models if somebody cares enough to do that (which is where the memcache
option came from).

>OTOH it seems superficially like redundant/load balanced IDPs would work
>fairly well if they shared keys.  Given all the other things that would
>be shared (like configurations and hence vulnerabilities) I don't see
>that as much of a problem.

It has performed extremely well in that way for me for about 8 years now.
I would not see myself ever going back to a shared state model in the IdP,
but that again comes back to logout (as in not doing it).

-- Scott