State Management and Clustering (IdP)

[Paul Hethmon]

It's JDBC via Hibernate. I've got it on my list to fix up and donate. 

The thing that would help in v3 would be something explicit for the idp to save state. With the current method of Terracotta it's assumed that changing the session object is auto persisted. So we end up writing a filter to do that on each request

Paul


(This phone has more cpu power than my first several computers, combined)

On Nov 12, 2012, at 2:15 PM, "Cantor, Scott" <cantor.2 at osu.edu> wrote:

> On 11/12/12 9:41 AM, "Paul Hethmon" <paul.hethmon at clareitysecurity.com>
> wrote:
>> 
>> To add a bit to this, even though I wrote that extension with Infinispan
>> for the current version, I've abandoned it for my own use. In my data
>> center, it worked pretty well, but in a few customer hosted sites, I had
>> problems even getting it working. Tuning the network parameters seems a
>> big challenge.
> 
> That's certainly a significant red flag for me.
> 
>> I ended up writing another storage plug-in that persisted sessions to a
>> database, with heavy support for not throwing errors if the database is
>> down. So I have a full local copy of anything that starts on that server,
>> send it to the database for persistence and to move the session to another
>> server. If a server doesn't have a local copy of the session, it will ask
>> the database for it. If it can't get it from the database, then that user
>> will simply have to login again.
> 
> Right, a lot sort of depends on the state itself. The biggies for the IdP
> are support for reversing transient IDs and artifact lookup, because that
> directly hits user functionality at SPs. Both of those can be handled with
> no clustered state (at least in SAML 2 in the artifact case).
> 
> If you're willing to donate the JDBC code (assuming it's JDBC), we might
> want to talk about that, it is on the list of future extensions in Jira.
> 
> -- Scott
> 
> 
> --
> To unsubscribe from this list send an email to dev-unsubscribe at shibboleth.net