Миграция провайдеров идентификации, сохранение идентификаторов пользователей и стратегия миграции (аутентификация 0 и т. Д.)

Question

У меня были некоторые проблемы с ростом для нашего ВПЛ.В настоящее время мы используем систему с открытым исходным кодом, которая требует некоторых обновлений для обеспечения безопасности.Однако у меня достаточно пользователей, поэтому предлагаемый вариант миграции совершенно неприемлем (1 месяц + простоя).

Я разработал скрипт для автоматической миграции пользователей, но API назначает пользователям новый идентификатор.Я использую этот идентификатор для сопоставления других услуг (покупки и т. Д.), И мне нужно убедиться, что этот идентификатор остается прежним.

ОК.Похоже, я только что перерос этот IDP?

Вариант 1: Изменить IDP: Когда я исследую другие IDP, такие как Auth-0, ни один не предлагает какой-либо вариант сохранения идентификаторов моего текущего пользователя - Некоторые предлагают варианты для привязки учетных записейно нет опции поиска из этого связанного идентификатора (который по сути был бы моим основным идентификатором) -

Вариант 2: вручную изменить IDP с помощью скрипта.Я исследовал изменение идентификаторов вручную ... но я чувствую, что это слишком рискованно, не говоря уже о том, что я получаю сильно различающиеся результаты.

Вариант 3: Период заката - в этом случае я просто запутываю проблему безопасности, и это потребовало бы от меня поддерживать устаревшую систему безопасности активной (не говоря уже о повышенных затратах) в течение определенного периода времени.

Вариант 4 - Месячное время простоя, приостановка регистрации / роста - получите это обработано.Это действительно болезненный вариант, который я хотел бы избежать любой ценой, если это возможно.

Что я пытаюсь понять, что сообщество делает в этой ситуации?Многие другие ресурсы привязаны к этому идентификатору, поэтому я не могу просто изменить его.Есть ли «лучшая практика», которую я здесь пропускаю?Если так, как бы вы подошли к этой проблеме миграции?Я рассмотрел таблицу поиска между идентификатором пользователя и любым идентификатором, который мы используем для идентификации.Это добавит буфер / прокси между любым IDP, который я использую, и самим идентификатором, так что в будущем этого больше не повторится.

Что я хочу знать, так это: как лучше всего переносить базы данных / IDPи сохраняя идентификатор пользователя?

Спасибо!

Answer 1

Учитывая, что я так и не смог найти ответ на этот вопрос или удовлетворительный ответ (и все лиды в RedHat и т. Д. Были тупиками) - я думал, что буду обновлять этот пост о своем решении (несмотря на то, что не смог поделиться им).

В конце концов, мое решение состояло в том, чтобы разработать сценарий, использующий преимущества многопоточности и параллелизма для пакетного создания пользователей с использованием собственного API Keycloak.Более 1/2 миллиона пользователей в возрасте до 3 часов.Это выявило следующую проблему: несмотря на то, что в документации Keycloak четко указано, что он принимает идентификатор, он ничего не делает с этой информацией при создании.Это является проблемой, потому что устаревшая связь с IDP означала, что изменение ID повредило бы все.

Следовательно, последующее решение состояло в том, чтобы позволить этому сценарию сгенерировать сценарий MYSQL, который можно запустить после обработки довосстановить идентификаторы.

Таким образом, мы смогли обновить Keycloak до последней версии и еще не видели каких-либо последствий от прямого манипулирования БД.Если вы ждете, когда Keycloak разработает лучший способ миграции: мой совет - нет.Судя по тому, что мы могли определить, мы могли быть пользователем KC с одним из наибольшего числа пользователей, которое мы видели.

На любые вопросы, касающиеся этого, я буду рад ответить.Пожалуйста, не стесняйтесь, напишите мне.