Могу ли я использовать единый клиент Azure AD B2C для сред разработки, STAGE и PROD приложения Django?

#azure #azure-active-directory #azure-ad-b2c

#azure #azure-active-directory #azure-ad-b2c

Вопрос:

У меня есть три основных среды для моего приложения Django. Я хочу использовать Azure AD B2C в качестве поставщика удостоверений для моего приложения. Но я немного смущен следующими моментами

Нужно ли нам создавать отдельный клиент Azure AD B2C для каждой среды? Как и сейчас, у меня есть три среды для моего приложения Django, поэтому я буду создавать 3 клиента.

Или, если я использую один клиент Azure AD B2C, как я буду различать пользователей DEV, STAGE и PROD?

Заранее спасибо.

Ответ №1:

Вам не нужно, но рекомендуется. У вас могут быть просто разные версии вашего пользовательского потока / пользовательской политики в одном и том же клиенте.

Лучшие практики здесьhttps://learn.microsoft.com/en-us/azure/active-directory-b2c/best-practices#operations

Комментарии:

1. @JasSure спасибо за ответ. Все еще есть путаница в том, как мы будем различать пользователей DEV, STAGE и PROD. Например, prod_user1 регистрируется из среды PROD. Но поскольку мы используем единый клиент Azure AD B2C, и все пользователи (DEV, STAGE, PROD) находятся в одном месте, так что prod_user1 также может входить в систему в средах разработки и STAGE. Какое поведение сейчас не требуется.

2. Вы не можете различать этих пользователей в приложении, если они находятся в одном клиенте, сохраняя при этом согласованность поездок пользователей b2c. Для этого вам нужны отдельные клиенты.

3. Допустим, у меня есть клиент Prod и непроизводственный арендатор… непроизводственный клиент на самом деле прямо сейчас обрабатывает 3 отдельных непроизводственных окружения, так что притворяйтесь dev-app1.com , dev-app2.com , dev-app3.com . Если у вас есть логин FB в AzureB2C, то вам необходимо указать APP_ID и APP_SECRET в Azure Identify Providers. Это означает, что поток SUSI (signupsignin) связан с идентификатором / секретом моего приложения 1 FB. FB требует, чтобы вы добавили «URL-адрес сайта» в настройках приложения, что, я не уверен, соблюдается. Я надеюсь, что нет, потому что я поставлю devapp1.com . В противном случае мне придется создать 3 клиента для 3 разных приложений FB (для 3 разных URL-адресов).

4. URL-адрес сайта в FB фактически будет указывать на конечную точку B2C / authresp. Я думаю, вы могли бы добавить разные URL-адреса в FB, но в противном случае, да, потребуется регистрация 3 приложений в FB.

Ответ №2:

Просто публикую способ, которым я ответил на эту проблему с моими требованиями, которые были:

  • Среда ничего не меняет для пользователя, она будет подключаться к той же учетной записи, несмотря ни на что
  • Значения утверждений различаются в зависимости от среды
  • По возможности избегайте нескольких клиентов

По сути, я создал дубликат атрибута пользователя с форматом ATTRIBUTENAME_ENVIRONMENT для каждой возможной среды, затем продублировал свои пользовательские потоки для каждой среды с тем же форматом USERFLOWNAME_ENVIRONMENT и выбрал только правильные утверждения для возврата в токене. Таким образом, пользователь, который подключается к потоку пользователей signupsignin_Production, получит токен, содержащий только атрибуты, заканчивающиеся на _Production.

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