A quick update on clustering work. The plan is:
* Infinispan User Session Provider - supports local, distributed and replicated modes /
almost completed
* Infinispan Realm Cache - supports local and invalidation modes (should not be used in
distributed/replicated modes) / almost completed
* Infinispan User Cache - supports local and invalidation modes (should not be used in
distributed/replicated modes) / almost completed
* Clustering support for adapters
- Support stateless (no http session) and distributed http session / not started
- Support direct communication with Keycloak (avoid proxy when auth-server url is
relative) / not started
* Security for clustering - use an interceptor to sign/verify messages with realm keys -
question is, do we really need this? Nodes need to be on the same subnet, realm/users are
invalidation only and the only thing a malicious node could do with user sessions is to
prevent them from expiring.
* Docker config for setting up test environment / almost completed
* Cluster testsuite / not started
* Jenkins clustering tests / not sure we'll get around to this
We're aiming to complete the above work by the end of the week, and release
1.1.0.Final with clustering support next week (or should we wait for SAML?).
With regards to using Infinispan for realm and user cache invalidation. Reasoning for
using this instead of a custom solution include:
* Significantly less time to impl (took only ~2h to impl!)
* Multicast/jgroups is much more efficient compared to http messages
* No need to deal with cluster memberships, disconnect/partitions, etc ourselves
* Infinispan provides loads of configuration options (evictions, transports, cache-modes,
etc.)
* Sensitive data never transferred between nodes (only invalidation messages)
* We can still sign messages with realm keys for security
* In theory we could also support distributed and replicated cache-modes in the future -
not sure this makes sense (maybe for users only?), also we're certainly not doing it
for this round
Show replies by date