SP load balancing

[Cantor, Scott]

On 9/11/12 11:11 AM, "Paul Brears" <pbrears at rm.com> wrote:

>I'm looking at this because I'm having some issues with a non-sticky load
>balancer. 
>Once Shibboleth has passed attributes to the application,  we don't
>require sticky because the application generated and stores it's session
>information in an encrypted cookie. All we choose to protect with
>shibboleth is the application sign in page.

Well, you have a minimum of the gap between the POST and the first request
to your code that does the cookie set. If that's not sticky, it won't
work. You should be able to avoid any other stickiness.

>Currently the load balancer is sometimes putting the request to the
>session initiator on server#1 and the reply to Shibboleth.sso/SAML/POST
>onto server#2

That doesn't require stickiness unless you use options that make it that
way.

>I assume that because the reply address was stored in memory it doesn't
>know where to send the user when the two halves of the communication land
>on different servers and it goes wrong.

If you use in-memory relay state, yes.

>Using relayState="cookie" should it be capable of getting the session
>established in a non-sticky environment?

Not entirely non-sticky, but between the initial request and the POST, yes.

-- Scott