This post summarizes what the LDAP Map Storage provider can do today, how it can be tested and configured, and things to watch out. Comments provided to in this discussion will be used to update the original post.

The code is the main branch of Keycloak.

Audience, Goals, Status

Audience: (will change while development progresses)

• Developers who want to explore and contribute to this store
• Future to-be-users that want to give this store a test run in a local development environment

Goal of the Map Storage Provider Family: Plugable storage back ends for the different first-class objects that will eventually support zero downtime upgrades, see https://github.com/keycloak/keycloak-community/blob/main/design/keycloak.x/storage-architecture.md

Goal of the LDAP Map Storage Provider: Map storage provider backed by an LDAP store. While LDAP will not be able to store all attributes needed for Keycloak, it should store as many as possible. Other attributes will be stored in other stores, and the tree store will combine them to a unified view.

Status: First support for roles in the main branch. Next up: users #9930

Supported Objects: Role

Supported Directory Servers: ApacheDS (other will eventually follow)

Known limitations:

• As a global provider, will serve all realms at the same time. Once Map stores can be configured on a per-realm basis, the LDAP store can also be configured per realm.
• All composite roles need to be LDAP roles in the current store. Future implementations will composite roles not part of the current LDAP in an artificial DN containing the internal Keycloak ID. With tree storage not available in main, there is no way to test/implement that feature yet.
• No pagination implemented yet
• Not part of the Arquillian integration tests yet, just some model tests and manual tests

Supported functionality for Roles

• list, create and update realm roles
• list, create and update client roles; each client uses its own DN prefix in LDAP, generated from the ID of the client
• support for composite roles, each composite role is stored as a member in the role
• support for additional LDAP attributes; each supported LDAP attribute needs to be listed in the store's configuration. Once it is listed, it can be added in the UI as an attribute with the same name as the LDAP attribute. Multiple values can be separated by a comma (,).

Setup of a test environment (minimal)

• Start ApacheDS that is part of the Keycloak distribution:

mvn -pl testsuite/utils exec:java -Pldap

• Cleanup if started for a second time: The setup of ApacheDS above will have an in-memory store only. Once it has been restarted, all information is reset, and it is then no longer in sync with the concurrenthashmap store. To also reset the other map stores using the concurrenthashmap store, run

rm -rf target/map

• Run org.keycloak.testsuite.KeycloakServer with the following parameters; the given properties will replace values in keycloak-server.json
  This will use map storage with defaulting to concurrenthashmap store for all providers, only the role storage will use LDAP.
  For development the Keycloak server can be restarted as often as needed as long as the ApacheDS server keeps its data.

mvn -pl testsuite/utils \
-Pkeycloak-server,map-storage \
-Dkeycloak.realm.cache.provider= \
-Dkeycloak.realm.cache.provider.enabled=false \
-Dkeycloak.role.map.storage.provider=ldap-map-storage \
-Dkeycloak.map.storage.ldap.connectionUrl=ldap://localhost:10389 \
-Dkeycloak.map.storage.ldap.bindCredential=secret \
-Dkeycloak.map.storage.ldap.bindDn=uid=admin,ou=system \
exec:java

• Verify setup after start: Connect to LDAP using the Apache Directory Studio. The initial setup will add roles like cn=admin,ou=RealmRoles,dc=keycloak,dc=org