A software suite to sync users actively from Keycloak to other applications user databases on a regular basis. This might be helpful if an application does not support an LDAP backend natively.
If there is a LDAP backend available, please take a look on Keycloak LDAP server.
Currently, these applications are supported as sync targets:
- None, see issues
We use TOML for our configuration. A config file should be assembled by concatenating the
general configuration options applying to all use cases as well as the configuration
required for the used Source and Target components (see architecture).
All default configurations can be found in the default config folder.
This project consists of three main components:
- Source (Keycloak)
- Controller
- Target (Application)
For just in time sync, there is a fourth component: KIDS event listener. This is a Keycloak event listener issuing web requests to syncer instances if certain objects are modified. This component is only necessary if a near real-time sync is desired.
The project aims to support two different sync types.
The syncer should ensure, that no parallel syncs are happening on the same object. However, targets should ensure that, even if this happens, no data loss occurs. Targets should also ensure that, on the next sync, a clean state can be reached.
The syncer will always support a full sync of all users and groups of the source to the target.
This type is intended to be triggered e.g. once a day. During this sync, all caches are emptied and afterwards a clean state should be reached between source and target.
During full sync, targets will get triggered like with an incremental sync, but when it starts, targets will get notified to e.g. clean runtime caches.
By utilizing the Keycloak event listener, the syncer might be notified about changes of specific groups and users. The controller will then trigger the sync to the target accordingly.
As the events are on a fire and forget basis, some changes might not be reflected in (near) real time. Therefore, to be sure, a periodic full sync is still required.
The source (currently only Keycloak) provides the user data. It has the responsibility to provide a common interface to interact with the data source.
In the Keycloak case, we use the Keycloak Admin API to fetch the data transparently.
The controller is responsible to schedule syncs and to receive and process events from the KIDS event listener. It is the central component using the defined interfaces of the target and source.
This component is responsible to sync the data received via the interface to the target application as well as to fetch the current state of the target application.
It has to translate the data format and ensure that the data is applied on the target.
This repository contains multiple targets, each with a single syncer app per source/target combination.
For manual end-to-end testing see here.
For easier error handling we use the anyhow create. The Error type can also capture and print backtraces if an error occurred. To see the backtrace you have to enable it through environment variables. You have the following options:
RUST_BACKTRACE=1: backtraces for panics and errorsRUST_LIB_BACKTRACE=1: backtraces just for errorsRUST_BACKTRACE=1andRUST_LIB_BACKTRACE=0: backtraces just for panics