Переход на корпоративный SSO нельзя сводить к замене формы входа. У локального пользователя уже есть заказы, файлы, роли и настройки, которые необходимо связать с внешней учётной записью без создания дубля.

Главное правило — не использовать изменяемый email как единственный ключ. Связь должна хранить внутренний user_id, провайдера и неизменяемый внешний идентификатор subject.

Что сделать в первую очередь

  • Составьте инвентаризацию способов входа и таблиц, связанных с пользователем.
  • Определите уникальный внешний идентификатор в SAML или OpenID Connect.
  • Подготовьте таблицу связей local_user_id, provider и external_subject.
  • Прогоните миграцию на копии базы и тестовой организации.

Почему возникает проблема

Потеря данных обычно происходит из-за автоматического создания нового профиля при первом SSO-входе.

  • Email в SSO отличается регистром, доменом или уже занят другим профилем.
  • Система ищет пользователя только по email и не хранит external subject.
  • Один сотрудник имеет несколько локальных аккаунтов.
  • Роли локального приложения ошибочно заменяются группами провайдера.
  • Отключение локального входа выполняется до завершения связывания.

Пошаговая диагностика

  • Найдите дубли email и пользователей без подтверждённого адреса.
  • Сравните claims реального SSO-токена с проектируемой схемой.
  • Проверьте, какие сущности ссылаются на user_id.
  • Смоделируйте смену email и увольнение пользователя.
  • Проверьте сценарий повторного входа и отзыв корпоративной сессии.

Как исправить

Надёжная миграция выполняется в два этапа: связывание, затем переключение основного способа входа.

  • Добавьте отдельную таблицу внешних идентификаторов с уникальным ограничением.
  • Разрешите подтверждённое связывание из существующей локальной сессии.
  • Для массовой миграции используйте проверенную таблицу соответствий, а не приблизительный поиск.
  • Оставьте аварийный локальный вход ограниченному кругу администраторов.
  • Логируйте операции связывания и отвязывания без содержимого токенов.

Как проверить результат

  • После SSO-входа открывается прежний профиль с его данными.
  • Повторный вход не создаёт нового пользователя.
  • Смена корпоративного email не разрывает связь.
  • Роли и блокировка доступа применяются согласно утверждённой политике.

Как не допустить повторения

  • Закрепите контракт claims с владельцем Identity Provider.
  • Добавьте тесты конфликтов и повторного связывания.
  • Не храните SAML assertion и access token в обычных логах.
  • Регулярно проверяйте пользователей без активной внешней связи.

Чего не стоит делать

  • Не объединяйте аккаунты только по совпавшему имени.
  • Не удаляйте локальные записи после успешного первого входа.
  • Не включайте обязательный SSO без проверенного аварийного доступа.

Что подготовить для диагностики

  • Схема пользователей и связанных таблиц.
  • Примеры claims без секретов.
  • Правила сопоставления ролей и групп.
  • Список конфликтных и тестовых аккаунтов.

Частые вопросы

Можно ли связать пользователей только по email?

Email допустим как предварительный кандидат, но окончательная связь должна подтверждаться и сохраняться по стабильному внешнему идентификатору.

Нужно ли удалять пароль после миграции?

Сразу удалять хеши необязательно. Сначала отключают локальный вход политикой, проверяют SSO и только затем выполняют согласованную очистку.

Когда стоит обратиться за помощью

Если в системе несколько ролей, организаций и способов входа, миграцию стоит проектировать вместе со схемой отката и аудитом конфликтов.

Итог

SSO без потери данных — это задача идентификации, а не только настройки протокола. Если нужно внедрить SAML или OpenID Connect и аккуратно связать существующие аккаунты, я могу подготовить миграцию, тестовый контур и безопасное переключение.