Recommended configuration for SP high availability

[Cantor, Scott]

On 7/15/13 12:08 PM, "Jim Hoy" <jim.hoy at gmail.com> wrote:
>
>Before posing my actual question I should mention that we'll be using the
>SP in the "bootstrap" fashion, wherein we'll be initiating an
>authentication request to the IdP and getting the response. From there,
>we'll look at the return attributes and make
> a decision about what permissions/roles/accessibility the user has.
>We'll create a session for the user in our application at which point we
>no longer care about the Shibboleth session. Our load balancer is
>round-robin and we are leaning (as my CTO says) HEAVILY away from server
>affinity or stickiness.

That's fine, but you cannot use the SP without either clustering the
session cache, reintroducing a single failure point by sharing a shibd
process, or having at least a short term sticky session. Period. There is
no stateless way to use it.

>So my question for this group is: If I install the Shibb SP on each
>server is it true that if server[1] in my load balancer accepts a user
>request for protected resources and initiates an authentication request
>to the proper IdP, (based on the previous
> paragraph) can server[2] handle the POST coming from the IdP (if so
>chosen by the load balancer) so I can log in my user as described?

Yes. But then the POST handler redirects to the resource and if that's not
server[2], it will break (unless one of the other approaches is used).

> Again, I won't need the Shibboleth session (that I'm aware of). If that
>turns out to not be true, what might you recommend.

It's cut and dried, and is outlined in some detail in the wiki on the
clustering page. The options mentioned are the only ones.

-- Scott