1

我的 IDP 经历了一些成长的痛苦。我们目前使用的开源系统需要进行一些升级才能安全兼容。但是，我有足够多的用户，提供的迁移选项是完全不可接受的（1 个月 + 停机时间）。

我开发了一个脚本来自动迁移用户，但 API 为用户分配了一个新 ID。我依靠这个 ID 来映射其他服务（购买等），我需要确保这个 ID 保持不变。

好的。看起来我刚刚长大了这个 IDP？

选项 1：更改 IDP：当我调查 Auth-0 等其他 IDP 时，没有人提供任何保留我当前用户 ID 的选项 - 有些提供链接帐户的选项，但没有从此链接 ID 中查找选项（本质上是我的主要 ID ) -

选项 2：使用脚本手动更改 IDP。我已经调查过手动更改 ID.. 但我觉得这太冒险了，更不用说我得到了各种各样的结果。

选项 3：日落期 - 在这种情况下，我只是混淆了一个安全问题，它需要我在一段时间内保持过时的安全性（更不用说增加的成本）。

选项 4 - 每月停机，暂停注册/增长 - 处理此问题。如果可能的话，我想不惜一切代价避免这是一个非常痛苦的选择。

我正在努力辨别的是社区在这种情况下会做什么？许多其他资源都与此 ID 相关联，因此我不能简单地更改它。我在这里缺少“最佳实践”吗？如果是这样，您将如何解决这个迁移问题？我考虑了用户 ID 和我们用来识别的任何 ID 之间的查找表。这将在我使用的任何 IDP 和 ID 本身之间添加一个缓冲区/代理，因此将来不会再发生这种情况。

我想知道的是：迁移数据库/IDP 并保留用户 ID 的最佳做法是什么？

谢谢！

4

1 回答 1

2

考虑到我永远无法找到对这个问题的回应或令人满意的答案（RedHat 等的所有线索都是死胡同） - 我想我会更新这篇关于我的解决方案的帖子（尽管无法分享）。

最后，我的解决方案是开发一个脚本，利用多线程和并发的优势，使用 Keycloak 自己的 API 批量创建用户。在 3 小时内超过 1/2 百万用户。这揭示了下一个问题：尽管 Keycloak 文档清楚地表明它接受一个 ID，但它在创建时对这些信息没有任何作用。这是一个问题，因为与 IDP ID 的传统联系意味着更改 ID 会破坏一切。

因此，后续解决方案是启用此脚本来生成一个 MYSQL 脚本，该脚本可以运行后处理来修复 ID。

因此，我们能够将 Keycloak 更新到最新版本，并且还没有看到直接数据库操作的任何后果。如果您正在等待 keycloak 开发更好的迁移方法：我的建议是不要。从我们可以确定的情况来看，我们可能是 KC 用户，拥有我们见过的最多用户之一。

有关此的任何问题，我将很乐意回答。请随时给我发电子邮件。

于 2019-07-23T23:28:38.477 回答