[External] Re: Idp v3.46 with Unicon's Shib-Redis storage service

[Paul B. Henson]

> From: Cantor, Scott
> Sent: Wednesday, September 16, 2020 8:57 AM
> 
> There are only two cases you should need server state for that, broken clients
> and proxying. The former should be fixable, and the latter was just addressed
> for single-level proxying via a contributed patch that will be coming.

We are currently using Unicon's hazelcast storage engine as well. I've been pretty happy with it, other than once in a blue moon the cluster will go haywire and I have to shut down all the nodes to kill it and then restart them to get things happy again. That seems to primarily happen when I need to restart an individual node, once it goes down and comes back up the membership gets confused and the nodes stop replicating.

I was also looking at the newer redis storage engine, as we are planning on duplicating our idp services in the cloud and having both on premise and cloud nodes running. I didn't trust hazelcast to replicate in that configuration, whereas Netflix has a replication system layered on top of redis that is designed for it:

	https://github.com/Netflix/dynomite

However, in the end, it all just seemed too complicated, particularly given management's requirement of implementing the cloud system using an auto scaling group where nodes would be popping up and going away randomly as needed. The only reason we needed shared server-side storage was for CAS proxy, so I updated the existing CAS encoded ticket service to support one level of proxying (which is all we currently use), which will allow us to deploy without server-side storage. My hazelcast cluster just blew up again last week, so I'm looking forward to it :). Theoretically it would be possible to support multiple layers of CAS proxies, but that would be more complicated and that type of deployment is relatively rare.

In terms of full disclosure, without shared server-side storage you also lose out on replicating the replay cache between nodes, as well as no longer have the ability to configure a ticket as "single use only", it will be valid until it is expired. Unless you have some strict security requirements regarding those components though, the decrease in complexity and increase in reliability is totally worth it.

--
Paul B. Henson  |  (909) 979-6361  |  http://www.cpp.edu/~henson/
Operating Systems and Network Analyst  |  henson at cpp.edu
California State Polytechnic University  |  Pomona CA 91768