[IdPv3] State Management and Clustering

[Chad La Joie]

On Tue, Oct 11, 2011 at 19:04, Russell Beall <beall at usc.edu> wrote:
> Do I read this correctly in that the Infinispan optional solution will then only replicate a small packet of data sufficient to enable back-channel support?  The smaller that packet is, the more efficient the clustering will be, and this will be good for clusters over wide networks (for instance the LIGO project).  Will this now be feasible for wide networks?

The size of the packets will vary.  For example, the data sent across
the network in order to replicate artifact data will be larger the
larger the referenced SAML message is.  But yes, in the general case,
the packets should be pretty small.

In terms of replicating over a WAN, that's still gong to depend a lot
on the network and your IdP setup.  The higher the latency and the
higher the link saturation, the worse it's going to be.  If you have a
good link though it should be fine.

> I had planned to suggest that only a very small packet be synchronously clustered, and then larger amounts of data, such as the attribute consent data, be clustered asynchronously.  Is that part of the idea?  It looks like this isn't necessary if the packet is already small (only a few KB).

As I mentioned before, the choice between synch and asynch replication
is really going to depend on what sorts of guarantees you need.  Given
that the use of clustering tech is only necessary for back-channel
support and the packet sizes are small, the shipped sample
configuration will use asynch replication.

> I had heard that the attribute consent engine would be packaged in with the new clustering solution.  Is that still happening, or will it still require database support?

Out of the box, I think I'm going to do what Scott suggested, which is
simply to store that data in a cookie.  However, there will be plugins
for storing the data in a database and in an Infinispan replicated
datastore.

-- 
Chad La Joie
www.itumi.biz
trusted identities, delivered