Hacker News Reader

Comment by toomuchtodo | Hacker News Reader

Any pitfalls you’ve encountered when implementing?

It’s highly integrated with Wildfly (or JBoss EAP for the commercial product), so if you’re not deploying it with the Docker images expect to have fun dealing with the special hell that is Java application servers - setting up infispan and configuring the database in JNDI at a minimum will require some moderate reading.

If you do use the Docker images it’s pretty straightforward though.

Past that, customization could be better - not because it doesn’t support it but because many of the SPI’s are poorly documented at best, or totally undocumented at worst. You’ll need to read the code and understand Java EE to do anything not supported out of the box, which, to be fair is a lot - but I’m having to spend far more time looking through code than I’d like to add a Steam login for PCGamingWiki, as an example. Thankfully I’ve dabbled with Java EE before so it’s no big deal to me, but something to consider if you wanna do something simple like add extra profile fields.

EDIT: one major nag I have is that the LDAP integration has an annoying bug related to renaming of users. Keycloak can be configured to use a GUID in an LDAP store as the link between a Keycloak user profile and an LDAP object, but when the username changes it will delete and recreate the account instead of updating the username. This creates a whole new sub identifier in the JWT assertions, which has caused me headaches.

I have a bug on file for this which just recently got updated targeting a fix in 10.0, so hopefully this gets fixed soon.

I would agree that a pain point is the lack of documentation, examples, and googleability of the SPI's. I have spent much longer than I would have expected integrating an existing user database.

Agree on the lack of documentation. But one thing I've found really nice is that the source code is really well structured and readable. Every time the documentation has let me down I've been able to find what I needed by reading the source code. That's one of the great underrated advantages of using open source solutions, you're not completely hamstrung when the docs don't give you what you need.

It looks like Quarkus is going to be considered for one of the next major release [1].

That said, do you believe it will still be possible to extend Keycloak using the deployment-scanner?

Also, do you happen to have open-source code related to Keycloak and/or custom extensions?

Beside the poor doc, finding more open-source code is one of the best way to learn this.

[1]: https://issues.redhat.com/browse/KEYCLOAK-13068?jql=project%...

Some more scraps of information regarding Keycloak on Quarkus is available at https://www.keycloak.org/2019/10/keycloak-x.

I'm hoping this will lead to significantly faster startup times so that my integration tests will run faster.

> do you believe it will still be possible to extend Keycloak using the deployment-scanner?

Even if it wouldn't bundling your keycloak-with-amenities is a 10-minutes job (1. make a pom.xml with keycloak dependency and your stuff 2. mvn package 4. there is no step 3)

The biggest thing we encountered was related actually to our initial deployment with active directory. This made logins slow, but actually found we could remove the requirement for Active Directory.

It is super heavily based on Wildfly, and if you're not using a tool like docker, it can be kind-of a burden. It runs decently well in standalone mode, but we ended up using the docker container's clustering with Kubernetes service discovery helping to find the other nodes to achieve a clustered deployment.

Outside of that is has been extremely stable, we use Kubernetes deployment mechanism along with a correctly defined readiness check to allow us to seamlessly upgrade, and we've gone from 4.3.0.Final to 7.0.1 in production without any problems. We haven't upgraded to 8 or 9 yet as we're actually working on some new frontend UI changes we wanted to get out the door with the release.

I'm curious how you manage upgrades. I am in the process of rolling Keycloak out to production now and the only thing I don't quite grok is how to do zero-downtime upgrades. It seems like the upgrade may make backwards-incompatible changes the DB schema. Do you replicate the entire database for the upgraded environment?

When using a K8s cluster with the helm chart [1], it's actually the stateful set that takes care to the update.

When the first replica restart, Keycloak makes the updates to the database itself. Sometimes rolling back to a previous version can break. They do not hold the reverse of the database version [2].

I believe the reason behind the STS (StatefulSet) is so the cache have the time to spread among the replicas as it get upgraded.

[1]: https://github.com/codecentric/helm-charts/tree/master/chart... [2]: https://www.keycloak.org/docs/9.0/upgrading/

We schedule a downtime window during upgrade, but typically see no frontend impact to the core service, SSO for end users. We snapshot the DB for rollback if needed as the migrations are not reversible.

Our actual DB size is pretty small so these are very non-intensive tasks.

May I know how many replicas and CACHE_OWNERS do you have?

Reply on news.ycombinator.com