Определение самоподтвержденного технического профиля в настраиваемой политике Azure Active Directory B2C

  • Статья

Примечание.

В Azure Active Directory B2C пользовательские политики преимущественно предназначены для выполнения сложных сценариев. В большинстве случаев рекомендуется использовать встроенные потоки пользователей. Ознакомьтесь со статьей Начало работы с настраиваемыми политиками в Azure Active Directory B2C, чтобы узнать о базовом пакете настраиваемых политик, если еще не сделали этого.

Все взаимодействия в Azure Active Directory (Azure AD) B2C, в которых пользователь должен предоставить входные данные, выполняются с использованием самоподтвержденных технических профилей. Например, страница регистрации, страница входа, страница сброса пароля.

Протокол

Атрибуту Name элемента Protocol необходимо присвоить значение Proprietary. Атрибут handler должен содержать полное имя сборки обработчика протокола, которое используется Azure AD B2C, для самоподтверждения: Web.TPEngine.Providers.SelfAssertedAttributeProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null.

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

<TechnicalProfile Id="LocalAccountSignUpWithLogonEmail">
  <DisplayName>Email signup</DisplayName>
  <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.SelfAssertedAttributeProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />

Входящие утверждения

В самоподтвержденном техническом профиле можно использовать элементы InputClaims и InputClaimsTransformations для предварительного заполнения значений утверждений, которые появляются на самоподтвержденной странице (отображаемые утверждения). Например, в политике изменения профиля путь взаимодействия пользователя сначала считывает профиль пользователя из службы каталогов Azure AD B2C, а затем самоподтвержденный технический профиль задает входящие утверждения с помощью пользовательских данных, хранящихся в профиле пользователя. Эти утверждения собираются из профиля пользователя, а затем представляются пользователю, который после этого может изменить существующие данные.

<TechnicalProfile Id="SelfAsserted-ProfileUpdate">
...
  <InputClaims>
    <InputClaim ClaimTypeReferenceId="alternativeSecurityId" />
    <InputClaim ClaimTypeReferenceId="userPrincipalName" />
    <InputClaim ClaimTypeReferenceId="givenName" />
    <InputClaim ClaimTypeReferenceId="surname" />
  </InputClaims>

Отображаемые утверждения

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

Порядок утверждений в DisplayClaims задает порядок, в котором Azure AD B2C будет отображать утверждения на экране. Чтобы потребовать от пользователя обязательно указать значение для определенного исходящего утверждения, задайте атрибуту Required элемента OutputClaims значение true.

Элемент ClaimType в коллекции OutputClaims должен задать для элемента UserInputType любой тип ввода пользователя, который поддерживается Azure AD B2C. Например, TextBox или DropdownSingleSelect.

Добавление ссылки на элемент DisplayControl

В коллекцию отображаемых утверждений можно включить ссылку на созданный элемент типа DisplayControl. Элемент управления отображением — это элемент пользовательского интерфейса, который реализует особую функциональность и взаимодействует с серверной службой Azure AD B2C. Она позволяет пользователю выполнять на странице действия, которые вызывают технический профиль проверки из внутренней службы. Например, она может проверять адрес электронной почты, номер телефона или номер карты лояльности клиента.

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

  • Первое отображаемое утверждение создает ссылку на элемент управления отображением emailVerificationControl, который собирает и проверяет адрес электронной почты.
  • Второе утверждение отображения делает ссылку на captchaChallengeControl элемент управления дисплеем, который создает и проверяет код CAPTCHA.
  • Шестое утверждение отображения делает ссылку на phoneVerificationControl элемент управления дисплеем, который собирает и проверяет номер телефона.
  • Другие отображаемые утверждения имеют тип ClaimTypes и собирают данные от пользователя.
<TechnicalProfile Id="Id">
  <DisplayClaims>
    <DisplayClaim DisplayControlReferenceId="emailVerificationControl" />
    <DisplayClaim DisplayControlReferenceId="captchaChallengeControl" />
    <DisplayClaim ClaimTypeReferenceId="displayName" Required="true" />
    <DisplayClaim ClaimTypeReferenceId="givenName" Required="true" />
    <DisplayClaim ClaimTypeReferenceId="surName" Required="true" />
    <DisplayClaim DisplayControlReferenceId="phoneVerificationControl" />
    <DisplayClaim ClaimTypeReferenceId="newPassword" Required="true" />
    <DisplayClaim ClaimTypeReferenceId="reenterPassword" Required="true" />
  </DisplayClaims>
</TechnicalProfile>

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

Сочетайте использование отображаемых утверждений и исходящих утверждений с осторожностью

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

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

<TechnicalProfile Id="id">
  <OutputClaims>
    <OutputClaim ClaimTypeReferenceId="age" />
  </OutputClaims>
</TechnicalProfile>

Если конечная политика, которая наследует этот базовый объект, в дальнейшем укажет officeNumber как отображаемое утверждение

<TechnicalProfile Id="id">
  <DisplayClaims>
    <DisplayClaim ClaimTypeReferenceId="officeNumber" />
  </DisplayClaims>
  <OutputClaims>
    <OutputClaim ClaimTypeReferenceId="officeNumber" />
  </OutputClaims>
</TechnicalProfile>

Утверждение age в базовой политике уже не отображается на экране для пользователя — оно фактически "скрыто". Чтобы отобразить утверждение age и получить значение возраста (age) от пользователя, необходимо добавить ageDisplayClaim.

Исходящие утверждения

Элемент OutputClaims содержит список утверждений, возвращаемых в следующий этап оркестрации. Атрибут DefaultValue вступает в силу только в том случае, если утверждение до этого никогда не задавалось. Однако если значение по умолчанию было задано на предыдущем шаге оркестрации, оно не вступает в силу, даже если пользователь оставит значение пустым. Чтобы принудительно использовать значение по умолчанию, задайте атрибуту AlwaysUseDefaultValue значение true.

Из соображений безопасности значение утверждения пароля (UserInputType установлен равным Password) доступно только для технических профилей проверки самоподтвержденного технического профиля. Утверждение пароля нельзя использовать на последующих этапах оркестрации.

Примечание.

В предыдущих версиях инфраструктуры процедур идентификации (Identity Experience Framework, IEF) исходящие утверждения использовались для получения данных от пользователя. Чтобы получить данные от пользователя, вместо этого используйте коллекцию DisplayClaims.

Элемент OutputClaimsTransformations может содержать коллекцию элементов OutputClaimsTransformation, которые используются для изменения исходящих утверждений или создания новых.

Когда следует использовать исходящие утверждения

В самоподтвержденном техническом профиле коллекция исходящих утверждений возвращает утверждения на следующий этап оркестрации.

Используйте исходящие утверждения в следующих случаях.

  • Утверждения выводятся преобразованием исходящих утверждений.
  • Задание значения по умолчанию в исходящем утверждении без сбора данных от пользователя или возвращения данных из технического профиля проверки. Самоподтвержденный технический профиль LocalAccountSignUpWithLogonEmail задает утверждению executed-SelfAsserted-Input значение true.
  • Технический профиль проверки возвращает исходящие утверждения. Технический профиль может вызывать технический профиль проверки, который возвращает некоторые утверждения. Вы можете перенаправить утверждения и вернуть их на дальнейшие шаги оркестрации на пути взаимодействия пользователя. Например, при входе в систему с помощью локальной учетной записи самоподтвержденный технический профиль с именем SelfAsserted-LocalAccountSignin-Email вызывает технический профиль проверки с именем login-NonInteractive. Этот технический профиль проверяет учетные данные пользователя и возвращает профиль пользователя. Например, userPrincipalName, displayName, givenName и surName.
  • Элемент управления отображением возвращает исходящие утверждения. Ваш технический профиль может содержать ссылку на элемент управления отображением. Элемент управления отображением возвращает какие-либо утверждения, например проверенный адрес электронной почты. Вы можете перенаправить утверждения и вернуть их на дальнейшие шаги оркестрации на пути взаимодействия пользователя.

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

<TechnicalProfile Id="LocalAccountSignUpWithLogonEmail">
  <DisplayName>Email signup</DisplayName>
  <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.SelfAssertedAttributeProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
  <Metadata>
    <Item Key="IpAddressClaimReferenceId">IpAddress</Item>
    <Item Key="ContentDefinitionReferenceId">api.localaccountsignup</Item>
    <Item Key="language.button_continue">Create</Item>
  </Metadata>
  <InputClaims>
    <InputClaim ClaimTypeReferenceId="email" />
  </InputClaims>
  <DisplayClaims>
    <DisplayClaim DisplayControlReferenceId="emailVerificationControl" />
    <DisplayClaim DisplayControlReferenceId="SecondaryEmailVerificationControl" />
    <DisplayClaim ClaimTypeReferenceId="displayName" Required="true" />
    <DisplayClaim ClaimTypeReferenceId="givenName" Required="true" />
    <DisplayClaim ClaimTypeReferenceId="surName" Required="true" />
    <DisplayClaim ClaimTypeReferenceId="newPassword" Required="true" />
    <DisplayClaim ClaimTypeReferenceId="reenterPassword" Required="true" />
  </DisplayClaims>
  <OutputClaims>
    <OutputClaim ClaimTypeReferenceId="email" Required="true" />
    <OutputClaim ClaimTypeReferenceId="objectId" />
    <OutputClaim ClaimTypeReferenceId="executed-SelfAsserted-Input" DefaultValue="true" />
    <OutputClaim ClaimTypeReferenceId="authenticationSource" />
    <OutputClaim ClaimTypeReferenceId="newUser" />
  </OutputClaims>
  <ValidationTechnicalProfiles>
    <ValidationTechnicalProfile ReferenceId="AAD-UserWriteUsingLogonEmail" />
  </ValidationTechnicalProfiles>
  <UseTechnicalProfileForSessionManagement ReferenceId="SM-AAD" />
</TechnicalProfile>

Страница регистрации или входа с исходящими утверждениями

На комбинированной странице регистрации и входа обратите внимание на следующее при использовании элемента определения содержимого DataUri, определяющего тип страницы unifiedssp или unifiedssd.

  • Отображаются только утверждения имени пользователя и пароля.
  • Первыми двумя исходящими утверждениями должны быть имя пользователя и пароль (в таком порядке).
  • Все прочие утверждения не отображаются; для этих утверждений необходимо либо установить defaultValue, либо вызвать технический профиль проверки форм утверждений.

Сохранение утверждений

Элемент Persisted Claims не используется. Cамоподтвержденный технический профиль не сохраняет данные в Azure AD B2C. Вместо этого выполняется вызов к техническому профилю проверки, который отвечает за сохранение данных. Например, политика регистрации использует самоподтвержденный технический профиль LocalAccountSignUpWithLogonEmail для сбора нового пользовательского профиля. Технический профиль LocalAccountSignUpWithLogonEmail вызывает технический профиль проверки для создания учетной записи в Azure AD B2C.

Технические профили проверки

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

Технический профиль проверки может быть любым техническим профилем в политике, например идентификатором Microsoft Entra илитехническими профилями REST API . В предыдущем примере технический профиль LocalAccountSignUpWithLogonEmail проверяет отсутствие имени signinName в каталоге. Если оно отсутствует, технический профиль проверки создает локальную учетную запись и возвращает objectId, authenticationSource и newUser. Технический профиль SelfAsserted-LocalAccountSignin-Email вызывает технический профиль проверки login-NonInteractive для проверки учетных данных пользователя.

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

Примечание.

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

Метаданные

Атрибут Обязательное поле Описание
setting.operatingMode 1 No Для страницы входа в систему это свойство управляет поведением поля имени пользователя, таким как проверка входных данных и вывод сообщений об ошибках. Ожидаемые значения: Username или Email. Ознакомьтесь с этими метаданными в живой демонстрации.
AllowGenerationOfClaimsWithNullValues No Разрешает создание утверждения со значением NULL. Это происходит, например, в случае, если пользователь не установит флажок.
ContentDefinitionReferenceId Да Идентификатор определения содержимого, связанного с этим техническим профилем.
EnforceEmailVerification No При регистрации или изменении профиля применяет проверку по электронной почте. Возможные значения: true (по умолчанию) или false.
setting.retryLimit No Определяет, сколько раз пользователь может попытаться предоставить данные, которые проверяются на соответствие техническому профилю проверки. Например, пользователь пытается зарегистрироваться с учетной записью, которая уже существует, и продолжает пытаться до достижения предела. Ознакомьтесь с этими метаданными в живой демонстрации.
SignUpTarget 1 No Идентификатор обмена целевого объекта регистрации. Когда пользователь нажимает кнопку "Регистрация", Azure AD B2C выполняет указанный идентификатор обмена.
setting.showCancelButton No Отображает кнопку "Отмена". Возможные значения: true (по умолчанию) или false. Ознакомьтесь с этими метаданными в живой демонстрации.
setting.showContinueButton No Отображает кнопку "Продолжить". Возможные значения: true (по умолчанию) или false. Ознакомьтесь с этими метаданными в живой демонстрации.
setting.showSignupLink 2 No Отображает кнопку "Регистрация". Возможные значения: true (по умолчанию) или false. Ознакомьтесь с этими метаданными в живой демонстрации.
setting.forgotPasswordLinkLocation 2 No Отображает ссылку "Забыли пароль". Возможные значения: AfterLabel (по умолчанию) отображает ссылку непосредственно после метки или после поля ввода пароля при отсутствии метки; AfterInput отображает ссылку после поля ввода пароля; AfterButtons отображает ссылку в нижней части формы после кнопок, а None удаляет ссылку "Забыли пароль". Ознакомьтесь с этими метаданными в живой демонстрации.
setting.enableRememberMe 2 No Отображает поле флажка Оставаться в системе. Возможные значения: true или false (по умолчанию). Ознакомьтесь с этими метаданными в живой демонстрации.
setting.inputVerificationDelayTimeInMilliseconds 3 No Улучшает взаимодействие с пользователем: ожидает, когда пользователь прекратит набор, затем проверяет значение. Значение по умолчанию 2000 миллисекунд. Ознакомьтесь с этими метаданными в живой демонстрации.
IncludeClaimResolvingInClaimsHandling No Для входящих и исходящих утверждений указывает, включено ли разрешение утверждений в технический профиль. Возможные значения: true или false (по умолчанию). Если вы хотите использовать сопоставитель утверждений в техническом профиле, задайте для этого параметра значение true.
setting.forgotPasswordLinkOverride 4 No Выполняемый обмен утверждениями сброса пароля. Дополнительные сведения см. в разделе Самостоятельный сброс пароля.
setting.enableCaptchaChallenge No Указывает, должен ли отображаться код вызова CAPTCHA. Возможные значения: true или false (по умолчанию). Для работы этого параметра элемент управления отображения CAPTCHA должен быть указан в утверждениях отображения самозаверяемого технического профиля. Функция CAPTCHA доступна в общедоступной предварительной версии.

Примечания:

  1. Доступен для определения содержимого DataUri типа unifiedssp или unifiedssd.
  2. Доступен для определения содержимого DataUri типа unifiedssp или unifiedssd. Макет страницы версии 1.1.0 и выше.
  3. Доступно для макета страницы версии 1.2.0 и выше.
  4. Доступен для определения содержимого DataUri типа unifiedssp. Макет страницы версии 2.1.2 и выше.

Криптографические ключи

Элемент CryptographicKeys не используется.