SP load balancing

[Paul Brears]

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.

However I'm having trouble getting attributes through to the page and the session established.

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 

This means I occasionally see (with debug logging on)
ACS returning via redirect to: https://domain.com/
Instead of:
ACS returning via redirect to: https://domain.com/Application/foo/bar?parameters....

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.

I've tried updating the relayState="cookie" from relayState="ss:mem" and I no longer get "ACS returning via redirect to: https://domain.com/" but I have managed to get redirect loops when it fails a couple of times.

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

Is there anything else to configure in shibboleth2.xml to get it to work with the session details in the cookie?
Clearly the Shib session will disappear as soon as the load balancer decides to move the connection to the server#2 but that's OK in this case.

Paul



-----Original Message-----
From: users-bounces at shibboleth.net [mailto:users-bounces at shibboleth.net] On Behalf Of Cantor, Scott
Sent: 10 September 2012 18:26
To: Shib Users
Subject: Re: SP load balancing

On 9/10/12 1:13 PM, "Paul Brears" <pbrears at rm.com> wrote:

>The SP documentation has recommendations for using persistence where 
>required or the shared Shibd/ODBC solutions where session persistence 
>isn¹t not practical.
> 
>Are there any plans to offer using cookies on the SP to hold enough 
>session state to eliminate the need for either a shared store of 
>sessions or load balancing persistence?

In the abstract, it's impossible because the data size is unbounded.

In practical terms, yes, I've considered it. I should probably add it to the roadmap given that it's a large amount of work.

My guess is that it would not perform particularly well but would solve the stickyness problem associated with deployments that wanted to keep the session around only for the purpose of supporting logout or something like that. All the sessioning I know of in application frameworks that support arbitrary data objects use server-side sessions for performance.

It hasn't seemed compelling to do it if it doesn't work for full-on use across all the requests. Of course since I don't actually know that it
*wouldn't* perform well enough to use on a typical web app with dozens of requests to the server each page, I'm speculating. If it did, that would be a more compelling case for it.

-- Scott


--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
____________________________________________________________________


RM Books - the first ever ebook system designed specifically for schools.

Coming in Autumn 2012 - pre-register for free now!

www.RMbookshelf.com

____________________________________________________________________

P.S. Think Green - don't print this email unless you really need to.
This message is confidential. You should not copy it or disclose its contents to anyone. You may use and apply the information only for the intended purpose. Internet communications are not secure and therefore RM Education does not accept legal responsibility for the contents of this message. Any views or opinions presented are only those of the author and not those of RM Education. If this email has come to you in error please delete it and any attachments. Please note that RM Education may intercept incoming and outgoing email communications.

RM Education plc is a company registered in England and Wales, Company Reg. No: 01148594; Registered Office: New Mill House, 183 Milton Park, Abingdon, OXON OX14 4SE; VAT No: 630 8236 56