Detachable IDP: Keycloak for wandering workgroups

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:

  • More flexibility (20+ Janssen interception scripts)
  • Single control plane for multiple components
  • Turnkey cloud deployment especially for multi-region
  • Casa self-service portal for credential management
  • Link data syncronization service 

In order to make this happen, the Jans Link service, which was introduced in version 1.0.16, would have to know which subset of users gets synchronized to which shard. This would require some new features to the new Jans Link syncronization service and some changes to the Jans Config API. 

This topology provides an interesting mix: federated authentication with enterprise user synchronization!