Перенос пользователей на внешний идентификатор Microsoft Entra

В этом руководстве вы узнаете, как перенести пользователей и учетные данные из текущего поставщика удостоверений, включая Azure AD B2C, на внешний идентификатор Microsoft Entra External ID. В этом руководстве рассматриваются различные решения, которые можно использовать в зависимости от текущей конфигурации. При каждом из этих подходов необходимо написать приложение или сценарий, использующий API Microsoft Graph для создания учетных записей пользователей во внешнем идентификаторе.

Предварительные требования

Прежде чем приступить к миграции пользователей на внешний идентификатор, вам потребуется:

• Внешний арендатор. Чтобы создать его, выберите один из следующих методов:
  • Используйте расширение Microsoft Entra External ID, чтобы настроить внешний клиент непосредственно в Visual Studio Code.
  • Создайте нового внешнего клиента в центре администрирования Microsoft Entra.

Подготовка: очистка каталога

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

• Определите набор атрибутов пользователя, хранящихся во внешнем идентификаторе, и переносите только необходимые атрибуты. При необходимости можно создать настраиваемые атрибуты в внешнем идентификаторе для хранения дополнительных данных о пользователе.
• При миграции из среды с несколькими источниками проверки подлинности (например, у каждого приложения есть собственный каталог пользователя), перейдите на единую учетную запись в External ID. Вам может потребоваться применить собственную бизнес-логику для слияния и согласования учетных записей для одного пользователя из разных источников.
• Имена пользователей должны быть уникальными для каждой учетной записи в системе External. Если несколько приложений используют разные имена пользователей, необходимо применить собственную бизнес-логику для согласования и слияния учетных записей. Для пароля позвольте пользователю выбрать его и задать его в каталоге. В учетной записи внешнего идентификатора должен храниться только выбранный пароль.
• Удалите неиспользуемые учетные записи пользователей или не переносите устаревшие учетные записи.

Этап 1. Миграция данных пользователей

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

1. Прочитайте учетные записи пользователей из вашего устаревшего поставщика идентификации.
2. Создайте соответствующие учетные записи пользователей в каталоге внешнего идентификатора. Сведения о программном создании учетных записей пользователей см. в статье "Управление учетными записями пользователей потребителей" с помощью Microsoft Graph.
3. Если у вас есть доступ к открытым паролям пользователей, их можно задать непосредственно в новых учетных записях при переносе данных пользователей. Если у вас нет доступа к паролям обычного текста, необходимо задать случайный пароль, который будет обновлен позже в процессе миграции паролей.

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

СОХРАНЯЙ во внешнем идентификаторе:

• Имя пользователя, пароль, адреса электронной почты, номера телефонов, номера участников и идентификаторы.
• Маркеры согласия для политики конфиденциальности и соглашений о лицензировании конечных пользователей.

НЕ хранить в внешнем идентификаторе:

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

Этап 2. Миграция паролей

После того как вы перенесли данные пользователя, следует перенести пароли пользователей из устаревшего поставщика удостоверений в External ID. Существует два рекомендуемых подхода для переноса паролей пользователей: самостоятельного сброса пароля (SSPR) и простой миграции. Если пароли пользователей с открытым текстом недоступны, вам потребуется использовать один из этих методов. Например, если:

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

Самостоятельный сброс пароля (SSPR)

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

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

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

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

Процесс простой миграции состоит из следующих шагов:

1. Добавьте атрибут расширения в учетные записи пользователей, чтобы указать их статус миграции.
2. При входе клиента считывается пользовательская учетная запись с внешним идентификатором, соответствующая введенному адресу электронной почты.
3. Если учетная запись клиента уже помечена как перенесенная, перейдите к процессу входа.
4. Если учетная запись пользователя не помечена как уже перенесенная, проверьте пароль, введенный для устаревшего поставщика удостоверений.
   1. Если устаревший идентификатор поставщика удостоверений определяет неверный пароль, верните пользователю понятное сообщение об ошибке.
   2. Если наследственный IdP подтверждает правильность пароля, используйте REST API для записи пароля в учетную запись внешнего ID и измените атрибут-расширение, чтобы пометить учетную запись как перенесенную.

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

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

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

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

Связанный контент

При миграции из Azure AD B2C на GitHub в репозитории с примером бесшовной миграции пользователей содержится пример пользовательской политики для миграции и пример кода REST API.