by Michael Schwartz, CEO of Gluu
What’s great about Keycloak is that it’s an “all in one container” that has SAML, OpenID and even some old school web access management features, like Realms and RBAC policies. It also has a small memory footprint because it uses the minimalistic Quarkus Java framework. For these reasons, Keycloak is handy tool for small workgroups that may find themselves disconnected for a period of time, for example, out to sea. This has given me an idea about how to create a network of Keycloak servers managed by the Janssen control plane.
A Keycloak “shard” would have its own hostname, keys and a distinct set of relying party applications. But what it would share with the “mother ship” is a subset of users, including some credentials, like passwords, FIDO keys, TOTP tokens, and user certificates.
When the shard is “wandering”, some user claims may get updated either on the shard or at the mothership. Some new users may even enroll, especially if that user can present a verifiable credential (or even a trusted, pin-protected X.509 certificate). But when the shard docks with the mothership, there would be a bi-directional user sync.
This topology provides the advantages of the Janssen in the mothership:
This topology provides an interesting mix: federated authentication with enterprise user synchronization!