Azure Active Directory B2C — сохранение пользователей в базе данных
Я преобразовываю устаревшую систему, которая хранит своих пользователей в базе данных (включая учетные данные), чтобы использовать Azure AD B2C для аутентификации.
Мой первый шаг — переписать фронтальный API (API, который напрямую обслуживает веб-клиент).
Поскольку многие другие системы и таблицы базы данных зависят от таблицы пользователей и ее столбцов, я решил создать пользователя базы данных для каждой новой регистрации объявления Azure.
В этом проблема, идентификатор пользователя в базе данных является первичным ключом, автоматически увеличивающимся числом.
Идентификатор, который я извлекаю из утверждений токена доступа, является идентификатором рекламного объекта, GUID.
Чтобы иметь возможность связать сущность пользователя ad b2c с сущностью пользователя базы данных, мне придется создать новый столбец в таблице пользователей, AzureObjectId.
Проблема в том, что теперь мне придется постоянно выполнять преобразование между AzureObjectId, который я извлекаю из токена доступа, в идентификатор пользователя базы данных, потому что другие таблицы базы данных и другие внутренние API, к которым я обращаюсь, ожидают идентификатор пользователя базы данных.
Как правильно решить эту проблему?
Я могу думать о
- Преобразование AzureObjectId в идентификатор пользователя базы данных при каждом взаимодействии с базой данных или другим внутренним API.
- После того как мой API создаст пользователя базы данных, используйте API Azure AD B2C Graph, чтобы добавить к пользователю новое утверждение, идентификатор пользователя базы данных.
И того, и другого я хочу избежать. Есть ли способ обогатить токен доступа идентификатором пользователя базы данных?
Ответы 2
Я бы выбрал второй вариант, так как это одноразовая операция, и системе не нужно каждый раз выполнять преобразование.
Обновление с подробностями
Похоже, это тоже сценарий миграции. Проверить образцы здесь
Вам также потребуется использовать функцию Спокойный API пользовательских политик.
В процессе регистрации выполните спокойный технический профиль, который вызовет API в службе contoso (ваш) для создания пользователя. Служба contoso вернет идентификатор пользователя базы данных только что созданного пользователя. Этот новый идентификатор пользователя можно использовать в качестве последующего утверждения для пользователя, и AzureADB2C создаст пользователя с этим свойством расширения.
Другой подход — это то, что мы обсуждали ранее. После регистрации пользователь может быть создан службой, и для первого вызова служба может вставить заявку для себя с новым идентификатором пользователя базы данных.
Согласно документации на docs.microsoft.com/en-us/azure/active-directory-b2c/…, в этом нет необходимости. «Основной пример — управление пользователями. Возможно, вам потребуется перенести существующее хранилище пользователей в клиент B2C. Вы можете разместить регистрацию пользователей на своей собственной странице и создать учетные записи пользователей в каталоге Azure AD B2C за кулисами. Эти типы задач требуют возможности создавать, читать, обновлять и удалять учетные записи пользователей. Вы можете выполнять эти задачи с помощью API Azure AD Graph».
Использование Graph API рекомендуется во многих случаях, когда обычные потоки не могут справиться с этой задачей.
Хорошо, так как это будет работать? Пользователь отправляет запрос к моему API с токеном доступа, я создаю эквивалентного пользователя базы данных, добавляю заявку на идентификатор пользователя базы данных через API графика. Но что мне делать с существующим токеном? Мне пришлось бы запросить повторную аутентификацию, чтобы создать новый токен, содержащий утверждение идентификатора пользователя базы данных.
Да - используйте пользовательские атрибуты
Вы можете добавить настраиваемые атрибуты через портал и выбрать их, чтобы вернуть их в виде утверждений в токене.
Ссылка API Graph выше показывает, как создавать их программно.
Поэтому, если вы заполните идентификатор пользователя базы данных в пользовательском атрибуте, вы сможете вернуть его в токене.
Вы имеете в виду использование графического API для проблемного обновления утверждений после того, как я создам пользователя в базе данных, верно? Это может быть хорошим решением, но что мне делать с текущим токеном доступа после того, как я обновил утверждения через API графа? Должен ли я запрашивать у пользователя повторную аутентификацию, чтобы получить новый токен?
Да. Мне интересно, приведет ли получение нового токена через поток токенов обновления к обновленному токену?
Я проверю его. Спасибо за ответ.
Да, я понимаю это. Тем не менее, мне кажется, что это обходной путь, а не органическое решение. Насколько я понимаю, API-интерфейс графа больше подходит для административных операций, таких как миграция, поэтому я не совсем уверен, добавляя его в производственный код.