AAD B2C несколько типов потоков регистрации
Я создаю приложение, в котором использую AD B2C с настраиваемыми политиками для реализации возможностей управления пользователями. Однако в моем приложении мне нужно поддерживать несколько типов учетных записей, в то время как для каждого типа учетной записи должен быть свой процесс регистрации (разные пользовательские данные для сбора). Мой вопрос: как лучше всего это реализовать?
2 ответа
Я бы посоветовал вам предоставить пользователям 2 разные кнопки, например UserType1 и UserType2 на странице приложения, и эти кнопки должны вызывать разные пользовательские потоки. Для этого доступны 2 варианта:
- Создайте 2 отдельные цепочки файлов политик
- Создайте несколько пользовательских поездок в файле Base или Extensions и используйте несколько файлов RP (signup_signin), ссылающихся на разные пути пользователя.
Чтобы создать два набора файлов политик, вы можете создать две отдельные цепочки, как указано ниже:
B2C_1A_TRUSTFRAMEWORKBASE> B2C_1A_TRUSTFRAMEWORKEXTENSIONS> B2C_1A_SIGNUP_SIGNIN
B2C_1A_TRUSTFRAMEWORKBASE1> B2C_1A_TRUSTFRAMEWORKEXTENSIONS1> B2C_1A_SIGNUP_SIGNIN1
Однако нет необходимости использовать 2 набора файлов политик, если вы хотите использовать 2 файла RP (B2C_1A_SIGNUP_SIGNIN). Вы также можете рассмотреть возможность создания двух отдельных пользовательских циклов в файле B2C_1A_TRUSTFRAMEWORKBASE или B2C_1A_TRUSTFRAMEWORKEXTENSIONS, например,
<UserJourney Id="SignUpOrSignIn"> и
<UserJourney Id="SignUpOrSignIn1">.
После настройки двух пользовательских маршрутов в файле B2C_1A_SIGNUP_SIGNIN вы можете ссылаться на
<DefaultUserJourney ReferenceId="SignUpOrSignIn" /> а в файле B2C_1A_SIGNUP_SIGNIN1 ссылка
<DefaultUserJourney ReferenceId="SignUpOrSignIn1" />
Если вы используете эту конфигурацию, цепочки файлов политики будут выглядеть так:
B2C_1A_TRUSTFRAMEWORKBASE> B2C_1A_TRUSTFRAMEWORKEXTENSIONS> B2C_1A_SIGNUP_SIGNIN
B2C_1A_TRUSTFRAMEWORKBASE> B2C_1A_TRUSTFRAMEWORKEXTENSIONS> B2C_1A_SIGNUP_SIGNIN1
Кроме того, имя файла RP (SIGNUP_SIGNIN) будет отличаться в обоих случаях. В варианте 1 все три файла имеют разные имена, а в варианте 2 файлы Base и Extensions будут одинаковыми, только файлы RP будут разными. Независимо от того, какой вариант вы выберете, вы можете указать имя файла RP (SIGNUP_SIGNIN) в URL-адресе, который вы указали выше. B2C поддерживает загрузку 200 файлов политик, поэтому вы можете выбрать вариант 1, не беспокоясь об исчерпании разрешенного лимита файлов политик.
В зависимости от других требований, которые могут у вас возникнуть, вы можете создать множество отдельных политик регистрации или одну, в которую вы можете передать параметр (тип учетной записи), значение которого будет определять, какой шаг с конкретным самоутвержденным профилем выполнять.
Если ваше приложение ожидает получить токен доступа в процессе регистрации, а ваш бэкэнд проверяет имя tfp, вы, вероятно, захотите иметь единую политику. Если это не так, и пользователю необходимо войти в систему после регистрации, тогда вы вполне можете пойти со многими политиками.
Другое отличие состоит в том, как построен UserJourney. В случае наличия большого количества политик вы можете (в зависимости от того, сколько самостоятельных шагов вы хотите иметь для определенных типов учетных записей) иметь простую политику UserJourney в EXT и только некоторые переопределения в RP (выбирая другой самозакрывающийся технический профиль). Когда вы решите использовать единую политику, вам потребуются шаги, предназначенные для определенных типов учетных записей с определенными предварительными условиями.
Это также зависит от того, насколько велика ваша общая настройка идентификации. У меня много политик (выходящих за рамки стандартной квоты 100 на одного арендатора), поэтому мне лично больше нравятся многоцелевые политики, чем разделять функции между многими и в итоге получать их еще больше.
Я считаю, что на ваш вопрос нет однозначного ответа. Есть много факторов, которые определяют, какой подход лучше всего подойдет вам. На это может повлиять даже такая простая вещь, как стили (шаблоны страниц).