Миграция пользователей в Azure AD B2C

Для миграции с другого поставщика удостоверений в Azure Active Directory B2C (Azure AD B2C) также может потребоваться перенос существующих учетных записей пользователей. Здесь рассматриваются два метода миграции, предварительная миграция и простая миграция. При любом подходе необходимо написать приложение или скрипт, использующий API Microsoft Graph для создания учетных записей пользователей в Azure AD B2C.

Просмотрите это видео, чтобы узнать о стратегиях миграции пользователей Azure AD B2C и действиях, которые следует рассмотреть.

Предварительная миграция

В ходе предварительной миграции приложение миграции выполняет следующие действия для каждой учетной записи пользователя:

1. Прочитайте учетную запись пользователя у старого поставщика удостоверений, включая его текущие учетные данные (имя пользователя и пароль).
2. Создайте соответствующую учетную запись в каталоге Azure AD B2C с текущими учетными данными.

Используйте поток предварительной миграции в любой из этих двух ситуаций:

• У вас есть доступ к учетным данным пользователя в открытом виде (имя пользователя и пароль).
• Учетные данные шифруются, но их можно расшифровать.

Сведения о программном создании учетных записей пользователей см. в статье "Управление учетными записями пользователей Azure AD B2C" с помощью Microsoft Graph.

Бесшовная миграция

Используйте плавный поток миграции, если пароли в открытом виде в старом поставщике удостоверения личности недоступны. Например, когда:

• Пароль хранится в односторонном зашифрованном формате, например с хэш-функцией.
• Пароль хранится устаревшим поставщиком удостоверений таким образом, что вы не можете получить доступ. Например, когда поставщик удостоверений проверяет учетные данные путем вызова веб-службы.

Бесшовный поток миграции по-прежнему требует предварительной миграции учетных записей пользователей, но затем использует настраиваемую политику для запроса REST API (который вы создаете), чтобы задать пароль каждого пользователя при первом входе.

Поток простой миграции состоит из двух этапов: предварительной миграции и задания учетных данных.

Этап 1. Предварительная миграция

1. Приложение миграции считывает учетные записи пользователей из старого поставщика удостоверений.
2. Приложение миграции создает соответствующие учетные записи пользователей в каталоге Azure AD B2C, но задает случайные пароли , которые вы создаете.

Этап 2. Настройка учетных данных

После завершения предварительной миграции учетных записей настраиваемая политика и REST API выполняют следующие действия при входе пользователя:

1. Прочитайте учетную запись пользователя Azure AD B2C, соответствующую введенной электронной почте.
2. Проверьте, помечена ли учетная запись для миграции, оценив булевый расширенный атрибут.
   • Если атрибут расширения возвращается True, вызовите REST API для проверки пароля в отношении устаревшего поставщика удостоверений.
     • Если REST API определяет неверный пароль, верните пользователю понятное сообщение об ошибке.
     • Если REST API определяет правильность пароля, напишите пароль в учетную запись Azure AD B2C и измените атрибут логического расширения на False.
   • Если логический атрибут расширения возвращает False, продолжайте процесс входа как обычно.

Чтобы просмотреть пример пользовательской политики и REST API, см. пример простой миграции пользователей на GitHub.

Безопасность

Подход к бесшовной миграции использует собственный пользовательский REST API для валидации учетных данных пользователя против старой системы управления идентификацией.

Вы должны защитить свой REST API от атак методом перебора. Злоумышленник может отправить несколько паролей в надежде на то, что в конечном итоге угадывает учетные данные пользователя. Чтобы помочь победить такие атаки, остановите обслуживание запросов к REST API, когда количество попыток входа проходит определенное пороговое значение. Кроме того, защитите обмен данными между Azure AD B2C и REST API. Сведения о защите API RESTful для рабочей среды см. в статье Secure RESTful API.

Атрибуты пользователя

Не вся информация из устаревшего поставщика удостоверений должна быть мигрирована в ваш каталог Azure AD B2C. Определите соответствующий набор атрибутов пользователя для хранения в Azure AD B2C перед миграцией.

• Do store in Azure AD B2C:
  • Имя пользователя, пароль, адреса электронной почты, номера телефонов, номера участников и идентификаторы.
  • Маркеры согласия для политики конфиденциальности и соглашений о лицензировании конечных пользователей.
• Не храните в Azure AD B2C:
  • Конфиденциальные данные, такие как номера кредитной карты, номера социального страхования (SSN), медицинские записи или другие данные, регулируемые государственными или отраслевыми органами соответствия.
  • Маркетинговые или коммуникационные предпочтения, поведение пользователей и аналитические сведения.

Очистка каталога

Прежде чем начать процесс миграции, воспользуйтесь возможностью очистки каталога.

• Определите набор атрибутов пользователя, которые будут храниться в Azure AD B2C, и переносите только необходимые атрибуты. При необходимости можно создать настраиваемые атрибуты для хранения дополнительных данных о пользователе.
• Если вы переносите среду с несколькими источниками проверки подлинности (например, у каждого приложения есть собственный каталог пользователя), перейдите в единую учетную запись в Azure AD B2C.
• Если у нескольких приложений есть разные имена пользователей, вы можете хранить все их в учетной записи пользователя Azure AD B2C с помощью коллекции удостоверений. О пароле позвольте пользователю выбрать его и задать его в каталоге. Например, при простой миграции необходимо хранить только выбранный пароль в учетной записи Azure AD B2C.
• Удалите неиспользуемые учетные записи пользователей или не переносите устаревшие учетные записи.

Политика паролей

Если учетные записи, которые вы переносите, имеют более слабую силу пароля, чем надежная сила пароля , применяемая Azure AD B2C, можно отключить требование строгого пароля. Дополнительные сведения см. в разделе "Свойства политики паролей".

Дальнейшие шаги

Репозиторий azure-ad-b2c/user-migration на GitHub содержит пример пользовательской политики миграции и пример кода REST API:

Простой пример пользовательской политики миграции пользователей и кода REST API