Azure Active Directory B2C - ведение пользователей в базе данных

Question

Я преобразую устаревшую систему, которая хранит своих пользователей в базе данных (включая учетные данные), чтобы использовать Azure AD B2C для аутентификации.

Мой первый шаг - переписать фронтальный API (API, который обслуживаетнепосредственно веб-клиент)

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

Этопроблема в том, что идентификатор пользователя в базе данных - это первичный ключ, автоматически увеличиваемый номер.

Идентификатор, который я извлекаю из утверждений маркера доступа, - это идентификатор рекламного объекта, GUID.

Чтобы связать сущность пользователя ad b2c с сущностью пользователя базы данных, мне нужно будет создать новый столбец в таблице пользователей, AzureObjectId.

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

Каков будет правильный способ решения этой проблемы?
Я могу подумать, что

1. Преобразование AzureObjectId в идентификатор пользователя базы данных во время каждоговзаимодействие с базой данных или другим внутренним API.
2. Как только мой API создаст пользователя базы данных, используйте API-график Azure AD B2C Graph, чтобы добавить новое утверждение, идентификатор пользователя базы данных, для пользователя.

И то, и другое я хочу избежать.Есть ли способ дополнить токен доступа идентификатором пользователя базы данных?

Answer 1

Да - используйте пользовательские атрибуты

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

Ссылка Graph API выше показывает, как создавать их программно.

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

Answer 2

Я бы выбрал второй вариант, так как это одноразовая операция, и система не должна выполнять преобразование каждый раз.

Обновление с подробностями

Это также похоже на сценарий миграции .Проверьте примеры здесь

Вам также понадобится использовать функцию Restful api пользовательских политик.

Во время процесса регистрации выполните restfulтехнический профиль, который будет вызывать API в сервисе contoso (ваш) для создания пользователя.Служба contoso возвращает идентификатор пользователя базы данных вновь созданного пользователя.Этот новый userId может использоваться как последующее утверждение для пользователя, и AzureADB2C создаст пользователя с этим свойством расширения.

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