我对IDP感到有些痛苦。我们目前使用的开源系统需要进行一些升级才能安全兼容。但是，我有足够的用户认为提供的迁移选项是完全不可接受的（停机时间超过1个月）。
我开发了一个脚本来自动迁移用户，但是API为用户分配了一个新ID。我依靠此ID来映射其他服务（购买等），并且我需要确保此ID保持不变。
好。看起来我刚刚超过了这个IDP？
选项1：更改IDP：当我调查其他IDP（例如Auth-0）时，没有人提供保留我当前用户ID的任何选项-一些提供选项用于链接帐户，但没有从该链接ID中查找的选项（实际上是我的主要ID）-
选项2：使用脚本手动更改IDP。我已经研究过手动更改ID的问题。.但是我觉得这样做太冒险了，更不用说我得到了各种各样的结果。
选项3：日落期-在这种情况下，我只是混淆了一个安全问题，这将需要我在一段时间内保持过时的安全性（更不用说增加的成本）了。
选项4-每月停机，暂停注册/增长-处理此问题。如果可能的话，我想不惜一切代价避免这样做。
在这种情况下，我难以辨别的是社区在做什么？许多其他资源都与此ID相关联，因此我不能简单地对其进行更改。我在这里缺少“最佳实践”吗？如果是这样，您将如何解决此迁移问题？我考虑过在用户ID和我们用来识别的任何ID之间的查找表。这样会在我使用的任何IDP和ID本身之间添加一个缓冲区/代理，因此以后不会再发生这种情况。
我想知道的是：迁移数据库/ IDP并保留用户ID的最佳实践是什么？
谢谢！
答案 0 :(得分：0)
考虑到我始终无法找到对此问题的答复或令人满意的答案（并且RedHat等处的所有潜在客户都死胡同）-我以为我会更新有关我的解决方案的这篇文章（尽管无法分享它） ）。
最后，我的解决方案是开发一个脚本，该脚本利用多线程和并发性使用Keycloak自己的API批量创建用户。在不到3小时的时间内，超过1/2百万的用户。这揭示了下一个问题：尽管Keycloak文档明确声明它接受ID，但在创建时不使用此信息。这是一个问题，因为与IDP ID的旧联系意味着更改ID会破坏一切。
因此，一种后续解决方案是使此脚本能够生成MYSQL脚本，该脚本可以在后期处理中运行以修复ID。
因此，我们能够将Keycloak更新到最新版本，并且尚未发现直接DB操作带来的任何后果。如果您在等待keycloak开发更好的迁移方法：我的建议是不要。根据我们的判断，我们可能是KC用户，是我们见过的最多用户之一。
对此有任何疑问，我很乐意回答。请随时给我发送电子邮件。