Keycloak MySQL数据库与LDAP及外部MySQL数据库同步方案咨询

背景 #

我们已为产品解决方案部署Keycloak作为身份提供商，计划将LDAP用户导入Keycloak的MySQL生产数据库，同时需将Keycloak数据库中的本地及LDAP用户同步至产品所用的外部MySQL数据库的systemusers表。我们不依赖SCIM插件，拟自行实现同步，现纠结两种方案：

• 扩展User Storage SPI，在Keycloak用户（本地或LDAP）更新时写入外部数据库
• 扩展自定义EventListener SPI，在触发UPDATE_PROFILE等事件时同步CRUD操作至外部数据库

疑问 #

1. Keycloak从LDAP导入用户时是否会触发事件？仅通过管理控制台更新用户时才会触发吗？
2. 如何检测LDAP用户的更新？
3. 若EventListener Provider不合适，User Storage SPI是否为实现三方数据存储同步的正确方式？

解答 #

1. LDAP导入用户的事件触发情况 #

• LDAP初次批量导入：默认不会触发USER_CREATED这类核心事件，因为批量导入是后台执行的批量操作，Keycloak事件系统默认只捕获用户主动操作（如控制台手动修改、用户自助改资料）或认证相关事件。
• 控制台/API更新用户：无论是本地用户还是已导入的LDAP用户，通过管理控制台或Admin API修改属性、重置密码、启用/禁用时，都会触发对应事件（比如UPDATE_PROFILE、UPDATE_PASSWORD）。

2. 检测LDAP用户的更新 #

分两种场景对应不同处理方式：

• Keycloak内修改LDAP用户：通过控制台或API修改已同步的LDAP用户属性，会触发常规用户事件，可直接用EventListener捕获。
• LDAP源端修改用户：Keycloak默认不会主动感知LDAP服务器端的用户变更，需配置LDAP用户存储的同步策略：
  • 开启Periodic Full Sync（定期全量同步）或Periodic Changed Users Sync（定期增量同步），让Keycloak定期拉取LDAP的变更。
  • 这类后台同步操作默认不触发事件，需通过User Storage SPI扩展拦截同步流程，在importUsers或syncChangedUsers等方法中处理同步逻辑。

3. 两种SPI方案的选型建议 #

EventListener SPI的优劣势

• 优势：开发成本低，逻辑简单，适合捕获用户主动操作产生的CRUD事件。
• 劣势：无法覆盖LDAP批量导入、LDAP源端同步更新这类后台操作，会导致外部数据库漏同步。

User Storage SPI的优劣势

• 优势：能覆盖所有用户数据变更场景（包括LDAP导入、LDAP源端同步、本地用户操作）：
  • 针对本地用户：可扩展JpaUserStorageProvider，重写createUser、updateUser等方法，在操作Keycloak数据库的同时同步到外部表。
  • 针对LDAP用户：自定义LDAP User Storage Provider，在importUserFromLDAP、syncChangedUsers等方法中，将同步到Keycloak的用户数据同时写入systemusers表。
• 劣势：需要对Keycloak用户存储逻辑有一定了解，开发成本略高于EventListener。

折中方案

如果不想完全依赖User Storage SPI，可以结合两种方案：

• 用EventListener处理用户主动操作的事件同步；
• 用User Storage SPI扩展处理LDAP导入、定期同步的后台操作；
• 给外部systemusers表添加唯一键约束（比如用Keycloak用户ID），避免重复同步导致的数据冲突。

内容的提问来源于stack exchange，提问作者TechQuestion