7 ms·

The issue with Keycloak is that it’s been around a while and has gone through a ton of changes. While it started as a JBOSS project, its usefulness as an IdP sh

The issue with Keycloak is that it’s been around a while and has gone through a ton of changes. While it started as a JBOSS project, its usefulness as an IdP shines in on-prem cluster auth. However, that’s where I would stop. I implemented Keycloak at scale on AWS ECS for a Fortune 500 department and it was unholy war for 1,000 years getting it to cluster properly. DNS discovery didn’t work right. Cluster discovery was over UDP (which didn’t work in our cloud environments). Stateful login on one server was missing from the others so dumb load balancing was off the table - sticky sessions was the only way. While it’s easy to docker run Keycloak and plug it in like Auth0, it’s like buying a 1996 Ford F-150 with 250,000 miles. It runs. It works. But Jesus is it a maintenance madonna.

mooreds 3y ago
I've heard there have been improvements since it fully moved to quarkus. When did you do that deployment to ECS?
- reactordev 3y ago
  2017-2019, by 2020 we moved to another IdP middleman.
reactordev 3y ago
OAuth with OpenID Connect and being able to add apps and clients to a realm was its saving grace and the only reason we kept it around.
silverquiet 3y ago
I did it at quite small scale, but within an on-prem docker swarm. It was indeed a pain because if I remember correctly the default discovery uses multicast which is not enabled on typical cloud networks or on a Swarm/Kubernetes overlay network. I looked at database pings where they'd use your RDMS for a sort of quorum mechanism, but that seemed very brittle and I got the impression it was more of a last-resort type thing. I was able to use the kubernetes cluster driver which uses the Swarm cluster's DNS for node discovery. It was indeed quite a pain to get working, but since then has been solid as far as I know. I believe there is also a native ec2 networking driver these days, but that is not something that I explored.
bird_person_ 3y ago
> Cluster discovery was over UDP (which didn’t work in our cloud environments) Ouch, we are only allowed UDP for DNS.

mooreds 3y ago

I've heard there have been improvements since it fully moved to quarkus. When did you do that deployment to ECS?

reactordev 3y ago
2017-2019, by 2020 we moved to another IdP middleman.

reactordev 3y ago

OAuth with OpenID Connect and being able to add apps and clients to a realm was its saving grace and the only reason we kept it around.

silverquiet 3y ago

I did it at quite small scale, but within an on-prem docker swarm. It was indeed a pain because if I remember correctly the default discovery uses multicast which is not enabled on typical cloud networks or on a Swarm/Kubernetes overlay network. I looked at database pings where they'd use your RDMS for a sort of quorum mechanism, but that seemed very brittle and I got the impression it was more of a last-resort type thing. I was able to use the kubernetes cluster driver which uses the Swarm cluster's DNS for node discovery. It was indeed quite a pain to get working, but since then has been solid as far as I know. I believe there is also a native ec2 networking driver these days, but that is not something that I explored.

bird_person_ 3y ago

> Cluster discovery was over UDP (which didn’t work in our cloud environments) Ouch, we are only allowed UDP for DNS.