AD B2C - Как настроить индивидуальную проверку электронной почты в потоке сброса пароля

У меня есть требование настроить электронную почту, отправляемую пользователю из AD B2C, когда он / она сбрасывает пароль.

Я следовал этой документации, чтобы настроить процесс самостоятельного сброса пароля, и он отлично работает: https://docs.microsoft.com/en-us/azure/active-directory-b2c/add-password-reset-policy?pivots=b2c-custom-policy

Чтобы предоставить фирменное письмо для сброса пароля, я следую этому коду, поскольку похоже, что единственный другой вариант - использовать элементы управления отображением, которые в настоящее время находятся в общедоступной предварительной версии (поэтому я не могу использовать их в производстве): https://github.com/azure-ad-b2c/samples/tree/master/policies/custom-email-verifcation

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

Я попытался добавить verificationCode OutputClaim в различные TechnicalProfiles, но я не могу визуализировать настраиваемое текстовое поле verificationCode, необходимое для предоставленного кода javascript.

Я думаю, что, возможно, мне следует использовать конкретное ContentDefinition, но я действительно изо всех сил пытаюсь найти правильный способ обновить XML-код пользовательской политики.

Обновите, чтобы уточнить: в примере регистрации код подтверждения добавлен в LocalAccountSignUpWithLogonEmail TechnicalProfile:

<ClaimsProvider>
        <DisplayName>Local Account</DisplayName>
        <TechnicalProfiles>
          <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>
                <!-- Demo: Disable the email verification-->
                <Item Key="EnforceEmailVerification">False</Item>
              </Metadata>
              <OutputClaims>
                <OutputClaim ClaimTypeReferenceId="objectId"/>
                <OutputClaim ClaimTypeReferenceId="email" PartnerClaimType="Verified.Email" Required="true"/>
                
                <!--Demo: Add the verification code claim type-->
                <OutputClaim ClaimTypeReferenceId="verificationCode" Required="true"/>

Поскольку я работаю над сбросом пароля (управляемым следующим SubJourney), мы видим, что он ссылается на LocalAccountDiscoveryUsingEmailAddress TechnicalProfile на первом этапе:

    <SubJourney Id="PasswordReset" Type="Call">
          <OrchestrationSteps>
            <!--Sample: Validate user's email address. Run this step only when user resets the password-->
            <OrchestrationStep Order="1" Type="ClaimsExchange">
              <ClaimsExchanges>
                <ClaimsExchange Id="PasswordResetUsingEmailAddressExchange" TechnicalProfileReferenceId="LocalAccountDiscoveryUsingEmailAddress" />
              </ClaimsExchanges>
            </OrchestrationStep>
    
            <!--Sample: Collect and persist a new password. Run this step only when user resets the password-->
            <OrchestrationStep Order="2" Type="ClaimsExchange">
              <ClaimsExchanges>
                <ClaimsExchange Id="NewCredentials" TechnicalProfileReferenceId="LocalAccountWritePasswordUsingObjectId" />
              </ClaimsExchanges>
            </OrchestrationStep>
          </OrchestrationSteps>
        </SubJourney>

Поэтому я добавил verificationCode в LocalAccountDiscoveryUsingEmailAddress TechnicalProfile:

    <!-- This technical profile forces the user to verify the email address that they provide on the UI. Only after email is verified, the user account is
    read from the directory. -->
    <TechnicalProfile Id="LocalAccountDiscoveryUsingEmailAddress">
      <DisplayName>Reset password using email address</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.localaccountpasswordreset</Item>
        <Item Key="UserMessageIfClaimsTransformationBooleanValueIsNotEqual">Your account has been locked. Contact your support person to unlock it, then try again.</Item>
      </Metadata>
      <CryptographicKeys>
        <Key Id="issuer_secret" StorageReferenceId="B2C_1A_TokenSigningKeyContainer" />
      </CryptographicKeys>
      <IncludeInSso>false</IncludeInSso>
      <OutputClaims>
        <OutputClaim ClaimTypeReferenceId="verificationCode" Required="true"/>
        <OutputClaim ClaimTypeReferenceId="email" PartnerClaimType="Verified.Email" Required="true" />
        <OutputClaim ClaimTypeReferenceId="objectId" />
        <OutputClaim ClaimTypeReferenceId="userPrincipalName" />
        <OutputClaim ClaimTypeReferenceId="authenticationSource" />
      </OutputClaims>
      <ValidationTechnicalProfiles>
        <ValidationTechnicalProfile ReferenceId="REST-EmailVerification"/>
        <ValidationTechnicalProfile ReferenceId="AAD-UserReadUsingEmailAddress" />
      </ValidationTechnicalProfiles>
    </TechnicalProfile>

Но связанный TextBox не отображается на странице.

Обновление 2: я выяснил, почему текстовое поле не отображается. Это связано с использованным ContentDefinition. При использовании определения содержимого api.selfasserted.profileupdate, несмотря на api.localaccountpasswordreset, поле отображается. Сейчас все еще работаю над этим.

Обновление 3: мне удалось заставить его работать, используя определение api.selfasserted.profileupdatecontent. Я опубликую полное решение, как только завершу интеграцию с API проверки.