We have been using it for 6-7 years now. Have been able to run very stable and integrated a lot of external IdP's to offer proper SSO on mulitple of our software stacks. Added a lot of other open source pieces of software we run for our backoffice needs (hashi vault, adminbro, etc.). So far very happy with it. Running in clustered mode without issues and as such little issues with the startup times. It probably helps that we have a solid background in Java based development and deployment and are less worried about the amount of memory it uses for the full suite.

This fascinated me - where and how does this fit into other identity providers (and thence into SSO).

I kind of yearn for client certificates everywhere simply because I can grok how that remains secure as we pass through layer after layer. the rest I just worry about

keycloak can broker between identity providers. It can use social logins as identity providers, connect to ldap, kerberos and others for user federation, and then provide SAML and OpenIDC to other applications.

Exactly this. OIDC and SAML integrations with customers IdP's. Map identity metadata from the customer into our realm so they can provide data in any way they want and we map it down to our standard which allows our applications to stay clean when using this metadata for business logic.

We have also added an event plugin to keycloak to push login events to a queue for other services to consume.

We also offer local keycloak identities in case a customer does not or can not provide their own identities, and have added haveibeenpwnd logic to check password strength/reuse for these local keycloak identities.

As someone who has superficially looked into it a couple times and gotten pushed away by the complexity: what do you recommend for a backend? Is there another container that provides an LDAP service I could use? Or Kerberos?

I am rebuilding my homelab soon and I am interested in having centralized auth across all systems and as many applications as feasible, using my centralized fileserver as an IDP source via some application or another, as well as using Keycloak for some one-off projects where I don't really want to write a user layer.

Personally I just use Keycloak as the backend(storing the user and group information). I provision it with terraform since I find it easier to use than the webUI.

Keycloak is now running on Quarkus, so startup times are much faster (few seconds). But -- KC is not something you start up often (in production).

It's reliable, flexible and actively developed, so not a bad choice as a self-hosted IAM solution.

With Quarkus, they went into other extreme -- if you are using docker, to get as fast startup as possible, you have to build your image with your configuration/modules used baked in.

Overall, I'm pretty satisfied. There are some bumps, but they are not Keycloak fault (having two different keytabs for two different host names for two different container images sharing same IP and reverse name not matching is kind of difficult).

There is an auto-build option so building a custom Docker image is an optimisation.

In my experience, Keycloak is best treated as a "pet" in the "pet v.s. cattle" spectrum. It takes a while to warm up, so you don't want to be constantly restarting it. I deployed it out-of-sync with the main application deployments.

As an open source option, it's quite powerful and full-featured. It's also quite configurable.

If I had one feature ask, it's that it doesn't play well with infrastructure-as-code ideas. While you can load a new realm from a JSON, it's harder to keep changes synced after that.

Which?